<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016, 2:17 PM Martin Packman <<a href="mailto:martin.packman@canonical.com" target="_blank">martin.packman@canonical.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When it comes to using lxd in clouds, as I understand it we've settled<br>
on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does<br>
mean bundles have to be manually changed at present to start using<br>
lxd. Most of the CI bundle testing is using real bundles out of the<br>
store, which all still say 'lxc' and therefore don't exercise the lxd<br>
container code at all.<br></blockquote></div></div><div><br></div></span><div>This bit confused me, and I realize this is late in the cycle, but I'd be remiss if I didn't at least float the though.</div><div><br></div><div>I would have expected juju to do the right thing for bundles. With what you've stated, we now have bundles that won't deploy in 1.25 that will in 2.0 and vice versa despite charms supporting both. This seems like a step backwards from a UX.</div></blockquote></span><div>Are you concerned bundles will have to be written specific to both lxc and lxd to support 1.25 and 2.0?  (one using lxc and the other lxd?)</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>What's the reasons behind this? Will there be a min-juju-version like in charms? (Hopefully not)</div><div><br></div><div>My expectation would have been juju 1.25 for lxc placement produces a lxc-1 container and in 2.0 produces a lxd/lxc-2 container.</div></blockquote></span></div></div></div></blockquote><div><br></div><div><br></div><div>So the plan as I understand it is that we're planning on updating Bundles to use the term "lxd" as the container they are requesting. And then updating the deployer and other tools to understand that they need to translate that back to LXC for Juju-1.X. The rationale is that we don't want to be stuck using old terminology forever, and the change is easy to do for bundles.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><br></div></div></div></blockquote></span><div>Marco, I'm guessing for your expectation to work here, juju2 would have simply kept all of the juju-1 lxc code and supported both lxc and lxd? As Martin demonstrated, just swapping a bundle to use lxd instead of lxc fails, which I think is to be expected. Is there something else you were looking for here?</div></div></div></div></blockquote><div><br></div><div>We specifically are dropping support for the old "lxc:" code path in 2.0. 2.0 is our time to drop things that we don't want to be supporting for the next 5 years, so we're taking the opportunity. It does give some pain points around compatibility, but we don't get the opportunity to break backward compatibility often, so we're taking advantage of it now.</div><div><br></div><div>John</div><div>=:-></div><div><br></div><div><br></div></div></div></div>