we have a LARGE maas environment (3 region controllers, Hot standby DB, 22+ rack controllers), 3500+ machines, trying to setup some zero-touch automation that leverages “machines.list()” via python-libmaas and it fails every time with a timeout error with this number of machines (it works in a lab environment but that has only ~40 machines). I suspect this is also the reason why the Web UI is very very slow at loading a large number of machines (2.6->2.9 made it much better, but it’s still pretty terrible with this number of machines (minutes…)).
What we want to see in the API is either:
machines.list() to accept filtering criterial (i.e. status = [NEW]) so that it is far faster (one can hope)
The ability for maas to fire off one or more webhooks on new machine enlistment. i.e. machine auto-enlists, maas fires off a webhook to some arbritrary HTTP(S) endpoint with the machine’s hostname and systemID. This way users can write custom automation to make things “touch less” in a flexible manner.
Hi, in the current cycle (i.e. 3.2), we are actively working on improving machine listing performance as we know it isn’t fast enough. We haven’t started working on it yet but rest assured we know about it and it’s high on our agenda.
About the webhooks, we are also discussing that internally - won’t be in 3.2 but will be under consideration for 3.3.
+1 on this issue.
I have noticed, even on a small cloud (e.g.: 12 node openstack), maas cli to list nodes is super slow, which makes this important command/function not useable at all.
What’s more, this is the starting point for maas cli. When it’s not working, you can not use most of the other maas cli functions, either. It’s a real blocker.
Basically, MAAS being able to scale to 10,000s of servers or more is very high on the agenda/strategic goals for the product. Work on scaling won’t end with fixing machine listing, we will be continuing to work on it constantly.
