MAAS Responsibilities beyond deployment


I keep fighting with MAAS for simple things such as setting usernames or hostname, things that are supposed to be straight forward, become complex.

I think the bottom line is the following: where does MAAS responsibility end?

If we are talking about Metal as a service, when one orders a server there is a delivery (Deployment) and from then on, one owns the Server: i.e. responsibility for configuring it further lies with the customer. Until perhaps Rescue and obviously Release.

Cloud init can be the tool that allows us for customize the metal delivery, but it seems as if it was used for MAAS internals: i.e. It is not clear where the settings are coming from, touching it may break the system, etc.

Today, in particular, I am fighting MAAS over control of my /etc/hosts… and hostname.

@rvallel, did you try changing the hostname by (1) clicking on the machine, and then, (2) clicking on the hostname and entering a new one?

1 Like

that goes to the very core of my point.

I identify MAAS as Metal as a Service, the hosts are deployed and delivered to a project that knows nothing about MAAS, or has access to its console.

In particular they use ansible for managing their services with playbooks already developed known to run well on ubuntu. They provide a public ssh key and expect an IP address to connect to, just like if this was Hetzner, OVH or any other metal provider.

furthermore, as you know servers have multiple interfaces.

would you make your public interface the MAAS interface too? We chose to use the “management” interface for MAAS.

some software packages expect you to pick a particular hostname and fqdn, that would be on the public interface.

Regardless of this, I think it is good that MAAS uses cloud-init to further customize the deployment of metal, but it would be nice if it was optional and transparent, easier to modify, etc.

I can see MAAS is used in many other different ways too.

curting+cloud-init must provide a full range of customization.

I guess my use case could be described as delivering bare-metal (minimum ubuntu server on it).

I guess I need to produce an example that delivers the bare minimum server setup.

Where can I see the full cloud-init source for a given machine, is it all embedded in…?

maas $PROFILE machine get-curtin-config $SYSTEM_ID

There are some customizations that I cannot recognize in this scripts, for example: vmware-tools come installed in my deployed machine, there must be a package installation somewhere, but I cannot see it.

Just my personal experience and opinion:

This is actually really simplified. Machines are easily named or renamed and associating dns suffixes is just as easy under the DNS tab.

Seeing as though you already use ansible, user management becomes trivial because you can distribute public keys at deployment time which ansible can leverage to run playbooks to manage users, keys and passwords from code.

Regarding multiple interfaces I think MaaS implementation of spaces is quite neat. You can attach and configure bonds, bridges or vlans and even configure IP adresses before deploying the machine resulting in robust network segmentation on multihomed machines.

That said MaaS is geared more toward managing fleets of servers (cattle) and focuses less of intimate configuration of purpose built machines (pets)

I personally find that simply booting a brand new machine from the network and MaaS automatically inventories, names and profiles a machine in just a few minutes is borderline magical and has literally saved me hundreds of hours of typical “sysadmin slog work”

I agree. MAAS is a neat system.

I have only been using it for a month or so, and I only get lost when I don’t understand what is happening behind the scenes.

Would be great to be able to see the plain preseed and cloud-init of a given machine to fully understand what is happening and why.

UI and CLI are fine tools that ultimately compose those files.

Do you know if it is possible to see the final pressed and cloud-init for a machine?

1 Like

@rvallel, ever figure this one out?


Yes. Including cloud-init UI when deploying helps.

Also, in my use case, which is installing Cloudstack on clusters, I have no interest in beyong cloud-init first install of server.

My current workaround is to disable cloud-init as of first installation step of Cloustack.

Also, many of the problems described here come form the fact that I wanted a “deployment” vlan, and separate “production” vlans. MAAS owns the deployment VLAN, and all production traffic is separate.

Setting things like the hostname (if the production one is different) and the default gateway become a problem if you want to have this separation. I have workarrounds for both, but I might just go with the default setup of one VLAN for deployment and production.

So, yes, I figured out this.

1 Like

cool. glad it got resolved. you wouldn’t be interested in sharing more about your solution in the development section, would you?

anyway, marking this one as solved.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.