[2.3, wishlist] Enlistment environment should check if the machine is known to MAAS, and act upon it.

[Jason Hobbs]

In bug 1743249, servers in Deploying state would boot into the ephemeral enlisting environment and then power off, leaving the server in Deploying state to eventually reach Failed Deployment.

MAAS should be able to recognize this situation and have the server do something other than power off. It should be simple to have the server reboot.

The enlistment scripts can ask MAAS if MAAS knows about the server already, and if it's in deploying state - or some other state like commissioning where it should be booting and running stuff, and if so, reboot.

[Jason Hobbs (jason-hobbs)]

Why was this marked "Opinion"?

[Andres Rodriguez (andreserl)]

I'm moving this to opinion. Here's the deal:

The machine will never know if it is known or not to MAAS. Since the machine doesn't know, then the machine can't simply decide to turn itself off if it is known, or boot onto enlistment if it is not known.

What you are suggesting *will* break auto-enlistment.

So, when grub makes a request, it does:

grub.cfg-<mac>
grub.cfg-<mac>
grub.cfg-<mac>
grub.cfg-<mac>
[...]
grub.cfg-default-amd64

So, lets look at the case where there's no known machines in MAAS:

1. The clients request grub.cfg-<mac> multiple times
2. Since the client didn't receive a request, it interprets "The server didn't respond, lets try different config"
3. The machine auto-enlists

So lets look at the case where it is a known machine:

1. The client requets grub.cfg-<mac> multiple times
2. The client didn't receive a request, it interprets that as "server didn't respond, lets try different config - grub.cfg-default-amd64"
3. The machines boots onto ephemeral which eventually fails.

So, the thing is, if MAAS cannot respond to the machine in a timely manner to tell it what to boot, how is the client itself supposed to know that it is a known machine so that it doesn't boot grub.cfg-default-amd64 ?

As such, again, this would actually break auto-enlistment.

[Jason Hobbs (jason-hobbs)]

I didn't make my suggestion clear.

Here is what I'm suggesting:

Here's how it works today when it's a known machine:

1. The client requets grub.cfg-<mac> multiple times
2. The client didn't receive a request, it interprets that as "server didn't respond, lets try different config - grub.cfg-default-amd64"
3. The machines boots onto ephemeral which eventually fails.

Here's what I'm suggesting:

1. The client requets grub.cfg-<mac> multiple times
2. The client didn't receive a request, it interprets that as "server didn't respond, lets try different config - grub.cfg-default-amd64"
3. The machines boots onto ephemeral.
4. Free from the time constraints of grub, the machine asks MAAS if it knows about it already and what state it is in, via the metadata API.
4a. If MAAS does know about it, and it's in Deploying state, then the machine reboots so it can continue its deployment
4b. If MAAS does not know about it, it continues with enlistment.

[Andres Rodriguez (andreserl)]

Thanks for the clarification. That makes sense now.

Currently, the enlistment environment provides no credentials to access to the API nor there's a current way to determine if the machine is known to MAAS or not. I think this would require to re-factor some of the enlistment to make it possible (e.g. like add a function that would allow the enlistment to check if the machine is registered).

I'll consider this a wishlist.

[Andres Rodriguez (andreserl)]

IDK if we can do this for 2.4, but will target it.