+1 for the DNS; We could really use that! 2016-04-05 3:31 GMT-07:00 Simon Davy <[email protected]>:
> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
