Planning for Juju 2.2 (16.10 timeframe)

[Narinder Gupta]

+1 for DNS as this was request in other community project as well which
uses JUJU.

Thanks and Regards,
Narinder Gupta (PMP)                   narinder.gupta at canonical.com
Canonical, Ltd.                    narindergupta [irc.freenode.net]
+1.281.736.5150                            narindergupta2007[skype]

Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com


On Tue, Apr 5, 2016 at 2:50 PM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> +1 for the DNS; We could really use that!
>
> 2016-04-05 3:31 GMT-07:00 Simon Davy <simon.davy at canonical.com>:
>
>> 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 at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160405/23a56c3c/attachment.html>