<div dir="ltr">Hey all!<div><br></div><div>Ian and I were discussing <a href="https://bugs.launchpad.net/juju-core/+bug/1350493">lp:1350493</a> (1.20.x local provider not running apt-get update) and thought it might be good to raise a few ideas here.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I am doing some work for another issue <a href="https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1322302">lp:1322302</a> 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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>We feel this empowers both developers and end-users, but wanted to raise this for discussion. Feedback welcome!</div><div><br></div><div>-</div><div>Katherine</div></div>