Planning for Juju 2.2 (16.10 timeframe)

[Simon Davy]

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