+1 for DNS as this was request in other community project as well which uses JUJU.
Thanks and Regards, Narinder Gupta (PMP) [email protected] 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 < [email protected]> wrote: > +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 > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
