apt proxy configuration, local provider and general cloud-init hacking

[Scott Moser]

On Wed, 31 Jul 2013, Sidnei da Silva wrote:

> I'm taking a look at https://bugs.launchpad.net/juju-core/+bug/1203816 and
> did a minimal attempt at implementing a solution for the local provider,
> which sets apt_mirror in the cloud-init config exactly like the
> ubuntu-cloud lxc template does.
>
> Then I took a look at how pyjuju did this, and it basically hardcoded the
> apt_proxy setting (note: different from apt_mirror) in the cloud-init
> config to the the first zookeeper node, port 3142.
>
> A third alternative would be, in the local provider, to sniff out the
> host's apt proxy config via 'apt-config dump Acquire::http::Proxy'.
>
> A fourth alternative that Adam G. brought up would be to just generally
> expose the cloud-init template as something that could be generally set in
> any environment. For example:
>
> environments:
>   local:
>     type: local
>     cloud-init-template: ~/.juju/cloud-init-local.cfg
>   hp:
>     type: openstack
>     cloud-init-template: ~/.juju/cloud-init-hp.cfg
>
> ...
>
> cat ~/.juju/cloud-init-local.cfg:
> apt_proxy: http://10.0.3.1:3142
>
> ...
>
> cat ~/.juju/cloud-init-hp.cfg:
> apt_mirror_search_dns: True
>
> Juju would take this base template and amend it with it's own cloud-config
> settings. It's unclear which one should take precedence in the case of
> conflicting settings. Maybe Juju's setting should always override the
> template.
>
> Being able to specify the cloud-init config would open the port for other
> pre-juju setup steps to be performed during the machine boot, including
> things like the 'basenode' charm-pre-install hacks that we do for IS.
>
> Is this a generally desirable feature for juju-core? Should we restrict
> configurability to only piecemeal items like the apt_proxy setting instead?

There are 2 reasons to not do it:
a.) juju is then exposing cloud-init as part of its user-config
    and cloud-init may change config and break juju users configs.
b.) if there is a provider (or container) that doesn't boot with
    cloud-init then the user has to know "oh, if i run this in a
    container, then my cloud-config stuff doesn't work".  Thats not
    generally very user friendly.

At this point I believe all providers and units have cloud-init access, so
it would work.

I most certainly understand the interest in it, as it allows you to do so
many just-fix-this or 'local-config' things that the user of juju can
know, but don't make sense to add one-by-one to juju.  (like using
http://apt-go-fast.notlong.com to trim sources.list and make 'apt-get'
always use eatmydata).

If juju were to expose this, then I'd recommend it be done 'parts.d'
style.  Juju can then just load all the parts in a directory, and put them
into a #cloud-config-archive along with its own.

One thing that is less than ideal is that cloud-config format doesn't
merge really well in precise.  Ie, the user can't add a run_cmd (but they
could add a '#!' part) because juju's would trump it.  In raring, there is
more powerful ways to specify merging behavior (ie, you could make juju's
runcmd's append to any existing), and in saucy, you can use the
well-defined standard behavior of 'json-patch' to do it.

The fact that 12.04's is less than ideal should not really impact this
discussion though.