LXC OS Updates

[John Meinel]

I think it is an interesting idea and might work reasonably well. I think a
key point is that we didn't finish our local provider support. Creating a
template that never gets updated just isn't a great experience, and we
really need a way to refresh that core snapshot. I can certainly agree that
the current logic of "do we run apt-get update" and "do we run apt-get
upgrade" can get moved into environment level configuration, and then have
specific defaults for Local that is different from other providers.
Note that we also have cases like this if people are using "lxc" on other
clouds, because we've moved to using the same template+cloning for all
clouds. I'm pretty we don't need enough knobs to say "apt-get upgrade on
virtual machines, but not in the LXCs deployed inside of those machines".

John
=:->


On Thu, Jul 31, 2014 at 6:34 PM, Katherine Cox-Buday <
katherine.cox-buday at canonical.com> wrote:

> Hey all!
>
> Ian and I were discussing lp:1350493
> <https://bugs.launchpad.net/juju-core/+bug/1350493> (1.20.x local
> provider not running apt-get update) and thought it might be good to raise
> a few ideas here.
>
> It is my understanding that currently we do LXC cloning in the interest of
> saving time -- the thinking being: if I have an image set up, I want to use
> it as a starting-point when provisioning machines. Pursuant to this
> performance goal, Juju will not run the OS's upgrades if a clone is
> performed. Of course, this is what is causing the aforementioned bug.
>
> I am doing some work for another issue lp:1322302
> <https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1322302> which
> involves attempting to speed up provisioning of local providers. One of the
> things we're introducing are config values (with sane, backwards-compatible
> defaults) that allow the user to specify whether or not they'd like Juju to
> refresh the available updates (in dpkg systems, apt-get update), and
> whether or not they'd like Juju to execute any available updates (in dpkg
> systems, apt-get upgrade).
>
> We'd like to remove the assumption embedded in the code that if we're
> cloning an LXC container, then we never want to perform OS upgrades.
> Instead, the logic based on the config variable will take over, and the
> user can have whatever behavior they desire. Local installations will be
> snappy, and production installations will be up to date.
>
> We feel this empowers both developers and end-users, but wanted to raise
> this for discussion. Feedback welcome!
>
> -
> Katherine
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140804/a1a7b3c5/attachment.html>