LXD polish for xenial

[Nicholas Skaggs]

On Mon, Apr 18, 2016 at 7:57 PM, Marco Ceppi <marco.ceppi at canonical.com>
wrote:

> Thanks so much for spending time on this polish! It'll really help our
> user experience shine for cost effective dev.
>
> On Mon, Apr 18, 2016, 2:17 PM Martin Packman <martin.packman at canonical.com>
> wrote:
>
>> When it comes to using lxd in clouds, as I understand it we've settled
>> on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
>> mean bundles have to be manually changed at present to start using
>> lxd. Most of the CI bundle testing is using real bundles out of the
>> store, which all still say 'lxc' and therefore don't exercise the lxd
>> container code at all.
>>
>
> 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.
>
> 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.
>
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?)

>
> What's the reasons behind this? Will there be a min-juju-version like in
> charms? (Hopefully not)
>
> 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.
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160418/38719f08/attachment.html>