Getting properly acquainted with MAAS after several brief meetings in the past, I’m revisiting some old topics that sparked curiosity from me, browsing the milestones on Launchpad, and I wasn’t aware of this discussion forum previously, so here goes:
Plugins: I see some related software (like Foreman) which have a healthy plugin or contribution community. As I understand it MAAS currently doesn’t have this. Is there any (hacky?) way to safely add features to MAAS at the moment? Which brings me to my second ponder:
Power control for non-IPMI capable machines. I’ve seen several sources include a patched WOL power profile, which seems complex and fiddly to implement (not to mention WOL itself is oddly hit and miss as a technology) but I wondered if there was a different approach, perhaps wrapping IPMI endpoints in some basic shell scripts for sending ‘shutdown’ type commands? I’ve gone and built an IPMI-solution using relays and RPis but I yearn for closer integration without having vendor-specific enterprise grade DC gear in my DevOps environment, whilst still making metal a first-class deployment target over virtualized/containerized deploments.
Taking the sting out of some of the manual power inconveniences through process modification? - Is there any reason why I shouldn’t be able to disable powering off a node that’s completed enlisting? And then be able to send a ‘shutdown -r now’ to the machine when I want to start commissioning?
Thanks for your continued work on this wonderful software. It’s cool. Nerdy cool. (the best kind of cool). <3
MAAS doesn’t have a plugable system for power drivers, even though the power drivers are mostly self contained in the driver itself. It requires some minor integration points with the rest of the product. That said, we do take community contributions. For example, look at this power driver implemented by a community user Merge into trunk : recs : Code : MAAS .
On the other hand, I would like to understand more in depth what’s this IPMI solution you have built? What is it about ? What is it meant to do?
The reason I ask is because MAAS would allow you to be flexible when it comes to power management. For example, you can have multiple rack controllers across your datacenter that are only used for PXE booting, while at the same time, you can have 1 single rack controller that will be in charge of power management. In other words, MAAS is flexible enough where you could connect 1 out of N rack controllers to the BMC network (either routed or directly connected) and no other rack controller, and MAAS would still be able to power manage machines via that single rack. This is a common configuration we have seen on the field where admins separate rack controllers for PXE booting, and 1 or 2 rack controllers for power management only. It would seem that doing this without having to go through an IPMI relay sort of solution would solve your problem (but then again, I dont have much context).
Is there any use case you are trying to solve by doing that? Machine enlistment is an interim process in MAAS that’s meant to simply discover a machine. Once discovered, the administrator can decide whether to let MAAS manage it (via ‘Commissioning’ the machine), or black list it (e.g. adding it as a device only for IPAM). Since the ephemeral environment provides no value, its powered off.
That said, as of 2.5, MAAS will also run built-in commissioning scripts to gather more data, and you would be able to transition a machine from “New” state to “Ready” state by using the “Test hardware” action (or you can still use the “Commissioning” action).
