LXD polish for xenial

[Marco Ceppi]

On Mon, Apr 18, 2016 at 11:31 PM Nicholas Skaggs <
nicholas.skaggs at canonical.com> wrote:

> 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?)
>

No. I was expecting 1.25 juju deploy bundle to produce a lxc machine - for
a very brief moment in the passenger seat of a car as I wrote that I lived
in a world where juju deploy bundle existed in 1.25. Updating deployer to
translate lxd -> lxc makes sense and is easy enough to do.

My point was more, why can't juju go the extra mile to figure out that lxc
means lxd for any juju deployed bundle? While it's trivial to update the
bundles in the store, that is only a small subset of bundles that exist. It
seems just producing a message, WARN or otherwise, that juju deploy bundle
with lxc placement is being assumed as lxd and to prompt the user to update
their bundle.


>
>> 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?
>

I don't want lxc code in juju 2.0 - lxd is clearly the way forward. I would
have simply expected things like charms and bundles are forward compatible.
This breaks forwards compatibility in the bundle format where deploying a
bundle with lxc placement will not work.

My expectation is that Juju would, on ingestion of the placement for the
bundle, map lxc placement to mean lxd.

Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160419/396e5cd1/attachment.html>