Hi!
My Lab’s MAAS broke… so I decided to fresh install 3.1/snap and test the new feature to enlist machines that are already deployed.
It did not work for me… or I don’t know how to use it.
I did use the command as described. The first thing is that it rejects to set the power type with an error message that power type cannot be set without networking configuration (despite been set to manual).
Anyway, I remove the power type, and then the machine is effectively created with the name provided as deployed, obviously without any gathered data.
The problem is that when I reboot the machine, it pops as a new one, and performs the initial data gathering process where some parameters are detected.
I am pretty sure that the mac address was properly setup, that should have been used for matching the machine. But perhaps the error message about not having
what could have gone wrong?
also, can I change to deployed a machine that has been detected? the initial data-gathering process is non-destructive, right? It would be ideal if I could just force-set-deployed or something.
is that possible?
I think the initial error was because I read “mac_address” instead of mac_addresses"
but still I am not getting the machine to behaving as already deployed… does not seem to launch neither the data-gathering boot up nor to boot as before…
I managed to boot the machine in rescue mode and that was useful to get data-gathered.
however systems wont boot into the deployed system.
I believe this may be related to the network configuration.
So far I am trying to recover 2 systems, one works (with manual power) the other has AMT capability and it is failing.
Error changing power state
is logged. This was working fine in previous MAAS installation. I wonder what could be wrong.
I was starting to question if the AMT interface is failing due to the 3.1 update or due to the enlisting of deployed machines.
So, I did delete the machine, commissioned it again, and re-deployed it. now AMT is working as expected.
Strange. So, I managed to enlist an already deployed machine with power type manual. But with power type AMT I did not get it to work.
It’s possible that we’re a little unclear in our doc, checking now. The original spec for this work says, “…user does not have to specify the power type.” All the examples look like this:
$ maas $profile machines create deployed=true hostname=mymachine \
architecture=amd64 mac_addresses=00:16:3e:df:35:bb power_type=manual
Note the power_type=manual on the end of that command.
I don’t know if manual power type is required, or whether there’s a bug. Going to ask the wider engineering team at the stand-up tomorrow and see what I can find out. Let you know.
@billwear Yes, I wonder the same kind of thing.
But I made several tests. The manual system I tested on worked. I did:
- enlist already deployed as in docs
- boot to rescue, that populated all enlisting data
- boot normally… several reboots, and it boots the Deployed system.
With the AMT machine
- enlisted already deployed as in docs
- would not boot into Deployed system
- managed to boot into rescue (but using the web AMT for issuing resets reboots etc)
- never managed to boot the deployed system
- after discarding the system and re-enlist and deploy from start, AMT works.
It took me some time to realize that the AMT is not working as expected.
in any case I would have created the machine with power-type=manual and then modify power-type on the UI for convenience.
in no case I created the machine specifying AMT power type from the command line.
@billwear I also run into more problems using this feature.
I used the recommended enlisting machine scripts from the machine itself.
the machines are running an maas unrelated virtualization package. and now a lot of fabrics have been auto-provisioned into maas, automatically, machines are listing all the virtual adapters.
now the dns seems to be broken because of interface names that use invalid characters (and seem to be mapped into maas.internal dns entries), this completely breaks maas and cannot deploy any more machines until the offending machines and fabrics are deleted.
I think the client script to enlist already deployed machines is neat, but should strictly deal with physical adapters and not virtual one.
@billwear and then the major problem that I have is that when I enlist a machine from the command line it wont reboot into workload.
The workaround is to first go into rescue mode, that will perform a commission, and after exiting rescue the deployed workload will boot.
I have been testing this for long, and it is the only way I can get it to work.
@rvallel, are you doing this manual step to get your machine information?
$ wget http://$MAAS_IP:5240/MAAS/maas-run-scripts
$ chmod 755 maas-run-scripts
$ ./maas-run-scripts report-results --config mymachine-creds.yaml
MAAS doesn’t collect the data for you. does that help?
When I use this method, all virtual adapters of the machine are imported into MAAS.
All networks and fabrics for those adapters get created into MAAS.
Ultimately NAMED starts failing because internal.maas zones contain invalid characters used in virtual adapters. So, this breaks my MAAS installation until I delete all imported machines this way and created fabrics.
I think this method should leave virtual hardware, or at least have a modifier --physical-only so that information of physical devices is captured only.
In my particular case I usee MAAS to prepare servers for CloudStack. I guess any other virtualization software would render the same result, as they will create many different virtual adapters.
is this a feature request, maybe? i’m not sure, enlighten me?
Yes, I think other people may experience problems with this too. So, I would make it a feature request.
When enlisting an already deploy servers I would only scan physical devices (which is what would happen if the servers was brand new). It should still be possible to --scan-all-devices with a modifier or something similar.
1 Like
that’s a winner. thank you. i will mark this one as closed since it will become a feature request.
1 Like
