Moonshot Chassis Manager 2.0

Hello,

We’re currently deploying a Moonshot Chassis 2.0 infrastructure and would be very keen to utilise MAAS for it. It appears that there have been breaking changes in the new version that prevent MAAS working with it.

I’m currently setting up a development environment to attempt adding support for the new version which I will be happy to contribute to the project, but before I undertake potentially a lot of work is anyone else working on this already?

Cheers.

1 Like

Thanks for taking a look! We currently have limited HP Moonshot available for testing and I believe it is older hardware. Couple of hints to get you going.

As of MAAS 2.9 BMC detection and configuration is done in the commissioning script 30-maas-01-bmc-config. There is a class for HP Moonshot already so you can make changes in there. I originally wanted to get feature parity with generic IPMI but didn’t have enough access to Moonshot hardware to implement it. The IPMI class may have some code you can use, it may even be possible to merge the IPMI and Moonshot class.

One of the changes I made in MAAS 2.9 is you can actually override MAAS’s builtin BMC configuration and detecting script with your own. All you have to do is make sure your script runs before 30-maas-01-bmc-config. You can fork the current script and rename it(don’t forget to change the name in the Start MAAS 1.0 script metadata section). I did a Show & Tell on creating a custom BMC configuration and detection script a few weeks ago.

MAAS runs all power actions from the rack controller. MAAS actually has two Moonshot drivers. One uses IPMI for communication the other uses SSH which includes chassis support. I’m not sure why there are two.

Let us know if you need any other help. Remember to include unit tests with any patches :slight_smile:

3 Likes

Thank you very much! These pointers will be really useful once I get an environment working. :slight_smile:

1 Like

Yes, your point on the two drivers is interesting. The mscm.py appears in MAAS under chassis, so it feels like the right one. The moonshot.py appears under machine, and it feels like a way of configuring individual nodes in the chassis, since it asks for much more detail. I agree, I’m not sure why there are two.

I’m working away at making changes to mscm.py now. Just to provide some commentary on the learning experience I’m having…

There are some pretty breaking changes in Chassis Manager 2.0. Commands like show node list and set node boot are gone, so those commands will need to be changed for equivalents if they still exist.

Cartridges are now called Blades now. So even if you query for the list of nodes (which can be done with show node mgmtaddr4 all, and outputs:

Slot ID    Management Address
---- ----- ------------------
   1  c1n1  192.168.4.125:736
   2  c2n1  192.168.4.125:737

To then get the model you then need to query against the blade (e.g. b1), instead of the node (e.g. c1n1):

MoonshotCM2.0->show blades b1
Blades:
        b1:
                AssetTag:
                iLO HTTPS: https://192.168.4.125:736
                iLO SSH: 192.168.4.125:826
                iLO MAC: [REDACTED]
                Model: ProLiant m750 Server Blade

Notice that the Model is “ProLiant m750 Server Blade” here, whereas in previous versions the models all showed as “ProLiant mXXX Server Cartridge”. If I took an old m710 cartridge and put it in the this chassis with the new firmware I wonder what it would show as. Since I don’t have a wide variety of hardware to test with I might be better assuming either.

I’m not sure whether the changes are significant enough for this to be a new chassis type (e.g. Moonshot Chassis Manager 2.0) or whether the existing chassis type should be modified to detect whether it’s v1.0 or v2.0. For detection, the show firmware command pretty definitely helps identify that it’s a 2.0 chassis.

I’ve made some good progress. I’ve modified MAAS to successfully capture blades from the Chassis 2.0. :+1: It’s all very hacky right now, and I need to resolve the descisions I was thinking about above, but as a proof of concept it works and I’ll be very happy to submit patches (with tests) when I’m done.

Q. What is the process for submitting changes? Do I submit a PR somewhere or raise an ‘issue’ with someone at Canonical?

Q. In terms of me deploying my changes to our server (which I’m currently doing as a fork of 2.9.2), what’s the best way of me deploying for the interim until my changes are (hopefully) absorbed into a future version? Should I build a snap and install that, so that in the future it’s simply a matter of removing the snap and then installing the official channel again?

Thanks very much!

1 Like

If anyone is following this, I’ve been testing some changes in the following repository. Changes were very easy and are working for me, but unfortunately I can’t test to prove that there’s no regression for Moonshot Chassis 1.0, as I don’t have one.

https://github.com/MissingCables/maas