On Mon, Apr 18, 2016 at 7:57 PM, Marco Ceppi <[email protected]> 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 <[email protected]> > 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?
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
