LXD polish for xenial
Dean Henrichsmeyer
dean at canonical.com
Tue Apr 19 15:37:37 UTC 2016
On Tue, Apr 19, 2016 at 6:43 AM, John Meinel <john at arbash-meinel.com> wrote:
> ...
>
>> 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.
>>>
>>
>
> 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.
>
My understanding was different. My understanding was that Juju 2.0 was to
understand both lxc and lxd so old bundles work just fine with Juju 2.0. If
you have a bundle with lxd in it, it was clearly written for 2.0 so it's
fine that it doesn't deploy with Juju 1.x.
Having Juju 2.0 not understand lxc seems silly given that in fact a lxd
container is just an lxc. We seem to be splitting hairs at the cost of
users.
-Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160419/f82692f8/attachment.html>
More information about the Juju-dev
mailing list