Updates to MAAS machine data propogated to Juju

Re-targeting to "juju" project for tracking for Juju 2.x. Putting it on wishlist.

This has come up with a customer

2 use cases based on the conversation with the customer

1)

At deployment time some of the AZs were not defined correctly in MAAS, and hence juju had the wrong AZs. They were able to change the AZs in MAAS, but this was then not reflected in juju itself. It would be nice to either have the capability to sync down, like suggested in the original comment, or do be able to change the AZ via the juju CLI.

2)

At certain points a customer may need to move pieces of HW from one rack to another. Typically, with customers, racks are defined for AZs, and therefore in this instance the AZ would change. With various workloads on a cloud or system, it would not be trivial to re-deploy the unit and/or application so that juju shows the correct AZs. So again, the customer can change it in MAAS, and therefore will not propagate to juju, and again as point 1, either automatic propagation or via CLI would be very helpful

~~~

AZs are used by customers for support mechanisms to understand (via juju) where the machines may be located and juju is a nice way to show that.

I was wondering if the was discussed at your end, and if this is something that would be considered to be added into juju?

I think this is something that we would be happy to have, but also something that is fairly low priority currently.

There is also a bit to understand the implications and what should happen if one of these fields change. (what hooks should run on a charm if the AZ changes?) Will the charms themselves support/notice the value changing. (IIRC, things like ceph make use of it when setting up ceph for the first time, but don't support that value changing after the fact, eg reconfiguring the mapping.)