Comment 16 for bug 1599886

cloud-init user-data customization seems to be an easy solution for this:

https://github.com/juju/juju/pull/8177 (merged)
https://github.com/juju/juju/pull/8177/files
https://github.com/juju/juju/pull/8188 (pending)
https://github.com/juju/juju/pull/8188/files

It adds several useful mechanisms:

1. cloudinit-userdata model config key

2. a way to execute certain runcmd commands before Juju's own commands and after them

* runcmd key is not allowed in userdata because it would override everything
* preruncmd - before Juju-generated runcmd
* postruncmd - after Juju-generated runcmd

We can simply use cloud-init-provided config options with that:

http://cloudinit.readthedocs.io/en/latest/topics/examples.html#add-apt-repositories
http://cloudinit.readthedocs.io/en/latest/topics/examples.html#additional-apt-configuration

disable_suites: [$RELEASE-security]

or just:

  primary:
...
      uri: http://<local-main>/ubuntu
...
  security:
      uri: http://<local-security>/ubuntu

I think that we can rely on that instead of using apt-mirror now.

The PRs above are mostly about allowing a user to customize userdata. The actual delivery to the provider code path (at least when I look at MAAS) has been there for a while:

https://github.com/juju/juju/blame/juju-2.3.1/provider/maas/environ.go#L851-L887
https://github.com/juju/gomaasapi/blame/master/machine.go#L226-L262
https://github.com/maas/maas/blame/2.3.0/src/maasserver/api/machines.py#L463-L469

Passing non-Juju-generated user-data to containers is also addressed in the above PRs AFAIKs.