new machine appears, it PXEboots (the same kernel as selected for Commissioning), and is available to accept (maas $PROFILE machines accept-all) and then we Commission. I appreciate in some contexts administrators may select some to commission one way or another … but it seems to me that we often use the same kernel 3 times, Enlistment, Commission and then Deploy. Seems like one ought to be able to elect to have nodes go straight to Commission (and then only 1 boot’s required). I suspect that going straight to Deploy would be less popular (except for context where 80++% of the nodes all get the same payload, but that might be a nice feature as well.
No doubt I simply don’t understand the rationale … so if there’s a documented reason for why we do it this way, I’d appreciate a pointer. If not, either an explanation or an RFE would be great ;>
When an unknown machine boots from MAAS it goes into enlistment. After enlistment finishes the machine goes to a NEW state so an administrator can choose whether or not to accept the machine into their MAAS. This prevents machines which are in use but unknown to MAAS from being overwritten.
If you add a machine first to MAAS over the API or UI the machine will go directly into commissioning, then testing, and finally a ready state.
A Machine could be commissioned right after being enlisted! Over that same operating system.
The Commission thing doesn’t change the Machine… Right?
Actually, MaaS already “skips” the enlist phase while composing Virtual Machines! It goes straight to the commissioning stage. And, as ltrager just said, you can add the Machine first (by using the PXE MacAddr?)
It would be nice to also, have support to deploy in one shot, power it up, deployed.
Thank you for the rationale; that be nice to have in the documentation ;>
But in order for it to have been discovered, it had to PXEboot … so just what kind of use would it have been in? I suppose it could have been in use, had a boot disk failure, been power cycled … and thus discovered. But is that a very common case?
The documentation does cover enlistment at https://docs.maas.io/2.5/en/nodes-add . If you feel that’s not enough to explain, please do file a bug report, we’ll be happy to continue to improve our documentation.
There’s been several situations in which having the “enlistment” process has saved environments. E.g. users transitioning live infrastructure to MAAS, or when mistakenly connecting a rack to MAAS by network admins. While its probably not common, this is a safety mechanism from MAAS to ensure it doesn’t blindly control resources that the administrator has not told MAAS about himself.
That said, if you add machines via the API, MAAS will automatically commission them and set them to Ready.
Lastly, please keep in mind that in commissioning you can run destructive scripts and if running testing as part of the process, test can also be destructive. When a machine is commissioning as part of the enlistment process, MAAS will ensure no destructive tests/scripts are run, and that’s a big difference of the two processes.
Thank you for the detailed rationale. I do believe that the current document describes what happens reasonably well, but it doesn’t include the reason(s) why. I’ll file an RFE with your text.
