Lots of interesting ideas here. Some other ideas (apologies if these have already been proposed, but I don't *think* they have)
a) A small one - please can we have 'juju get <svc> <config>'? See https://bugs.launchpad.net/juju-core/+bug/1423548 Maybe this is already in the config schema work, but it would *really* help in a lot of situations, and it seems simple? e.g. $ juju get my-service foo bar This would make me very happy :) b) A bigger ask: DNS for units. Provider level dns (when present) only gives machine name dns, which is not useful when working at the model level. As an operator, I've generally no idea which machine unit X is on, and have to go hunting in juju status. It's be great to be able to address individual units, both manually when troubleshooting, and in scripts. One way to do this might be if juju could provide a local dns resolver as part of the controller. e.g. if you have a model called 'bar', with service called 'foo', with 2 units, the following domains[1] could be resolved by the controller dns resolver: foo-0.bar foo-1.bar and/or unit-foo-0.bar unit-foo-1.bar or even 0.foo.bar 1.foo.bar Then tools can be configured to use this dns resolver. For example, we have deployment servers where we manage our models from. We could add the controller's dns here, making it easy for deployment/maintenance scripts to target units easily. Right now, we have to parse json output in bash from juju status to scrape ip addresses, which is horrible[2] Other possibilities (warning: not necessarily a good idea) * add this resolver into the provisioned machine configuration, so config on the units could use these domain names. * the controller dns resolver can forward to a specified upstream resolver (falling back to host's resolv.conf info) - single point of control for dns for all models in that controller - repeatability/reliability - if upsteam dns is down, controller dns still provides local resolution, and also could cache upstream, perhaps. * if you ask for a service level address, rather than unit, it could maybe return a dns round robin record. This would be useful for internal haproxy services, for example, and could give some default load-balancing OOTB * would provide dns on providers that don't have native support (like, erm, ps4.5 :) Now, there are caveats a plenty here. We'd need HA dns cluster, and there's a whole bunch of security issues that would need addressing, to be sure. And I would personally opt for an implementation that uses proven dns technology rather than implementing a new dns resolver/forwarder in go with a mongodb backend. But maybe that's just me ;P Thanks. [1] in hindsight, I do think having a / in the unit name was not the best option, due to it's path/url issues. AIUI, internally juju uses unit-<svc>-N as identifiers? Could this be exposed as alternate unit names? i.e. cli/api commands could accept either? [2] At the very least, it would be great to have a cli to get the ip(s) of a unit, would simplify a lot of scripts. e.g. $ juju get-ip foo/0 --private 10.0.3.24 $ juju get-ip foo/0 --public 1.2.3.4 $ juju get-ip foo --private 10.0.3.24 10.0.3.134 -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju