Re: LXD polish for xenial

[John Meinel]

...


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

So I'd like to clarify a few points here. The first *very* key point is
that the old "lxc" containers are *not* the same as "lxd" containers. It is
a bit unfortunate, but I'll go through some reasons:

   1. Both of them do use cgroups, etc to create isolation between
   containers, but so does docker, and I don't think people feel docker
   containers are interchangable with lxc or lxd containers.
   2. There is a package called "lxc" that you can install, which provides
   the old "lxc-foo" commands (lxc-start, lxc-stop, lxc-launch, etc)
   3. There is also a package called "lxdclient" which installs a local
   binary named "/usr/bin/lxc". That, however, does *not* interact with the
   former package.
   4. Very concretely, if you do "lxc-launch -t ubuntu-cloud" then that
   container will *not* show up in "lxc list". "lxc" is the lxdclient and
   talks to the lxd daemon to get work done. "lxc-*" commands do all of the
   container creation, etc, themselves.
   5. Going forward I'll call the old thing 'lxc1' because that is the new
   package for it (AIUI). And I'll enumerate some more of the differences
  1. lxc1 containers are priviledged by default and require you to be
  root to create them. lxd containers are unpriviledged by default
and can be
  requested by any user. The daemon itself runs as root to provide the
  functionality, but the container you get will not have a root-elevation
  escape mechanism.
  2. lxc1 containers download from cloud-images to /var/cache/lxc and
  populate /var/lxc/* with the rootfs and where the container files
  themselves are. lxd caches images differently (/var/lib/lxd/images, IIRC)
  and supports the use of things like ZFS filesystem mounts to provide fast
  cloning to launch a new image.


Juju itself *could* continue to support its existing logic to create and
manage 'lxc' containers as a separate bunch of containers from 'lxd'
containers. They would end up on different bridges, have different code
paths for creating them (lxd we talk directly to the HTTP REST api of the
daemon, 'lxc' we have to exec a command and parse the string output.)
We have been directed that we really don't want to be supporting 2 very
similar-but-not-the-same container mechanism for the next 5 years, and
going to 2.0 is the one time we're going to get to break support for the
old mechanism.

John
=:->
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Nate Finch]

Thanks for explaining, John, that makes sense and really helps me
understand the reasoning behind these changes.

On Tue, Apr 19, 2016 at 11:30 PM John Meinel  wrote:

> On Tue, Apr 19, 2016 at 6:56 PM, Nate Finch 
> wrote:
>
>> Then I guess I don't understand why it worked fine up until last week.
>>
>
> So up until last week LXD depended on the 'lxc1' package which was the old
> tools for creating containers. That did always set up an 'lxcbr0' bridge,
> which LXD then always used for its own containers.
>
> That was "ok" because "lxc1" was never installed by default so it didn't
> break people who just "install ubuntu". With LXD being
> always-available-always-installed-by-default with Ubuntu, they had to be
> more conservative in their defaults. Otherwise when you just "ec2
> start-instance ubuntu" it might not work as you expect because it has
> additional bridges installed-by-default on your cloud instance that didn't
> exist in Trusty.
>
> John
> =:->
>
>
>
>> > LXD is our code.  Juju is our code.  Surely we can code/configure the
>>> two
>>> > to work together such that it just works for the 95% case?
>>>
>>> I assure you we're aware of this. Unfortunately there's not a good
>>> answer.
>>>
>>> Tycho
>>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[John Meinel]

On Tue, Apr 19, 2016 at 6:56 PM, Nate Finch 
wrote:

> Then I guess I don't understand why it worked fine up until last week.
>

So up until last week LXD depended on the 'lxc1' package which was the old
tools for creating containers. That did always set up an 'lxcbr0' bridge,
which LXD then always used for its own containers.

That was "ok" because "lxc1" was never installed by default so it didn't
break people who just "install ubuntu". With LXD being
always-available-always-installed-by-default with Ubuntu, they had to be
more conservative in their defaults. Otherwise when you just "ec2
start-instance ubuntu" it might not work as you expect because it has
additional bridges installed-by-default on your cloud instance that didn't
exist in Trusty.

John
=:->



> > LXD is our code.  Juju is our code.  Surely we can code/configure the two
>> > to work together such that it just works for the 95% case?
>>
>> I assure you we're aware of this. Unfortunately there's not a good
>> answer.
>>
>> Tycho
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: hacking upload tools for development

[roger peppe]

I wonder what the best way for this to work might be. Presumably it would
have to establish something (a local server? A temporary directory?) and
then juju would need to run in that context. Are you imagining some kind of
wrapper command that would set up the tools and then run the juju command?
Or a more persistent local state that could be updated?
On 19 Apr 2016 16:13, "Aaron Bentley"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2016-04-19 05:19 AM, Michael Foord wrote:
> >
> >
> > On 14/04/16 19:38, Aaron Bentley wrote: Hi there.
> >
> > I've done a lot of work with simplestreams lately, and we've got
> > some decent tools for generating them quickly and easily.  I'd be
> > happy to work with someone from core to develop a tool to generate
> > streams that you can use in place of --upload-tools.
> >
> >> That sounds ideal.
>
> Great.  I do need to partner with someone on core for this, to make
> sure the resulting tool is something that devs will want to use.  Are
> you up for that?
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXFkr6AAoJEK84cMOcf+9hYFgH/0DVVDmDkYLDFcwOyAR9Rykg
> PGC+RvRVbitn9vx7vCDGYKl1syqsnRr50xEe43RWN5Ix6NrmgekKciB7VZocEzg4
> IxzLkv0X8MU2HVkYVwR1O/f12vCExHTxriP/UdeuubHaEWNr2k0K3Lxpl5zT1oqB
> 8ZZo+nhGUqGYRYHACvIbatlbI2MJ7rvmMeKycNTk9AzeFxZFC4keW6Pweee+Ptas
> Yg131FnNbKf5ReI8lDrvPyWGxTVHPRH+HXLgb9Op7abQX1yBb4M4fOc9n/O3vY49
> EJxTFMRE+dXZ/5MHxbaczaTo+MjDY6JrROxylfsRXxDXc6z8xvC9aZ6Bmk0gRi4=
> =qZlB
> -END PGP SIGNATURE-
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Martin Packman]

On 18/04/2016, Tycho Andersen  wrote:
>>
>> Unlike other providers, lxd exposes no way to use the daily images
>> instead of release images, so at present any machine using lxd
>> containers with juju for the first time will get the xenial beta2
>> image then upgrade basically every package. This issue goes away next
>> week, but gets in the way of testing before then.
>
> Yes, it does, jam added it. You can use the image-stream=daily option:
>
> juju set-model-config image-stream="daily"
> juju bootstrap --config image-stream=daily ...
>
> The daily streams haven't been regenerated since April 12 (another
> known issue that CPC is working on) so you'll still see some churn.

Sorry, poor wording on my part, read 'containers' instead of 'providers'.

The setup I was testing, using lxd containers as part of a bundle, not
using the lxd provider, does not work with image-stream=daily. The
release images are still selected for the lxd containers, though the
provider machines are brought up with daily images.

Martin

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Martin Packman]

On 18/04/2016, Martin Packman  wrote:
>
> "autopkgtest lxd provider tests fail for 2.0"
> 
>
> So, at present we don't have confidence that the LXD provider will
> work, even with the manual configuration step, for users installing
> Xenial for the first time.

Great progress on the lxd provider side:



Thanks to help from everyone in the bug, we have a working autopkgtest
and juju 2.0 has migrated out of proposed into the main archive.

Along with that, Tycho has proposed a couple of branches aimed at
making the first use experience less painful.

Martin

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Dean Henrichsmeyer]

On Tue, Apr 19, 2016 at 6:43 AM, John Meinel  wrote:

> ...
>
>> On Mon, Apr 18, 2016, 2:17 PM Martin Packman <
>>> martin.pack...@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
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: hacking upload tools for development

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-19 05:19 AM, Michael Foord wrote:
> 
> 
> On 14/04/16 19:38, Aaron Bentley wrote: Hi there.
> 
> I've done a lot of work with simplestreams lately, and we've got
> some decent tools for generating them quickly and easily.  I'd be
> happy to work with someone from core to develop a tool to generate
> streams that you can use in place of --upload-tools.
> 
>> That sounds ideal.

Great.  I do need to partner with someone on core for this, to make
sure the resulting tool is something that devs will want to use.  Are
you up for that?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXFkr6AAoJEK84cMOcf+9hYFgH/0DVVDmDkYLDFcwOyAR9Rykg
PGC+RvRVbitn9vx7vCDGYKl1syqsnRr50xEe43RWN5Ix6NrmgekKciB7VZocEzg4
IxzLkv0X8MU2HVkYVwR1O/f12vCExHTxriP/UdeuubHaEWNr2k0K3Lxpl5zT1oqB
8ZZo+nhGUqGYRYHACvIbatlbI2MJ7rvmMeKycNTk9AzeFxZFC4keW6Pweee+Ptas
Yg131FnNbKf5ReI8lDrvPyWGxTVHPRH+HXLgb9Op7abQX1yBb4M4fOc9n/O3vY49
EJxTFMRE+dXZ/5MHxbaczaTo+MjDY6JrROxylfsRXxDXc6z8xvC9aZ6Bmk0gRi4=
=qZlB
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Nate Finch]

Then I guess I don't understand why it worked fine up until last week.

On Tue, Apr 19, 2016, 10:39 AM Tycho Andersen 
wrote:

> On Tue, Apr 19, 2016 at 01:42:08PM +, Nate Finch wrote:
> > On Tue, Apr 19, 2016 at 7:49 AM John Meinel 
> wrote:
> >
> > > ...
> > >>>
> > >>
> > >
> > >>
> > >>> That's probably the cause of the other confusion in the updated docs
> -
> > >>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
> > >>> already has lxc setup in some fashion there's a different error from
> > >>> juju telling them to run the dpkg-reconfigure command. That should
> > >>> presumably always appear whenever there's no usable bridge.
> > >>>
> > >> The flip flopping back and forth on the bridge name is going to cause
> > >> havoc even after release. Do we have clear direction now from LXD on
> how
> > >> they plan to handle the competing network bridge names? I understand
> we're
> > >> now saying a dpkg-reconfigure is required, but I'm not clear if /
> when we
> > >> plan to make this easier.
> > >>
> > >
> > > So, LXD is going to be installed-by-default on Xenial. Which means that
> > > everyone will always have it installed. However, that leads to a
> problem
> > > with having a "standard" subnet dedicated to LXD. While it works for
> lots
> > > of people, there are plenty of cases where that subnet would already
> be in
> > > use elsewhere (in say a company's internal LAN). Which means LXD chose
> to
> > > go with link-local addresses by default. AIUI that means that the
> > > containers can talk to the host (and probably the host can route them
> to
> > > the public internet?) but they aren't able to talk to other containers
> or
> > > have inbound traffic.
> > > My personal hope is that the dpkg-reconfigure steps can provide a
> 70%-case
> > > safe default set of addresses (possibly using autodetection), and give
> a
> > > nice wizard to help people, while still allowing them to override it
> in case
> > >
> >
> > I really fear for what this will do to adoption.  I feel like we're
> > throwing the common "it just works" case out the window to enable a very
> > small edge case to work slightly better.  I'd much rather have defaults
> > where juju/lxd just works with most common setups.  For the one little
> > exception - if the network on your corporate LAN conflicts - we give a
> nice
> > error message and give the user tools to reconfigure.
>
> The problem here is that there's no way to detect this case (e.g. what
> if the network in question is routed behind your default gateway
> somehow?). Things just break, and it can be difficult for people to
> figure out why.
>
> LXD's bridge setup defaults to ipv6 link local with an HTTP proxy that
> allows apt-get to work. The current dpkg-reconfigure prompts will
> suggest reasonable values if you decide you want to enable ipv4.
>
> > Making everyone
> > configure their network (not the easiest or friendliest task even for
> > people on our own team), is surely going to cause us to lose a *lot* of
> > users with a bad first impression.
> >
> > LXD is our code.  Juju is our code.  Surely we can code/configure the two
> > to work together such that it just works for the 95% case?
>
> I assure you we're aware of this. Unfortunately there's not a good
> answer.
>
> Tycho
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Tycho Andersen]

On Tue, Apr 19, 2016 at 01:42:08PM +, Nate Finch wrote:
> On Tue, Apr 19, 2016 at 7:49 AM John Meinel  wrote:
> 
> > ...
> >>>
> >>
> >
> >>
> >>> That's probably the cause of the other confusion in the updated docs -
> >>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
> >>> already has lxc setup in some fashion there's a different error from
> >>> juju telling them to run the dpkg-reconfigure command. That should
> >>> presumably always appear whenever there's no usable bridge.
> >>>
> >> The flip flopping back and forth on the bridge name is going to cause
> >> havoc even after release. Do we have clear direction now from LXD on how
> >> they plan to handle the competing network bridge names? I understand we're
> >> now saying a dpkg-reconfigure is required, but I'm not clear if / when we
> >> plan to make this easier.
> >>
> >
> > So, LXD is going to be installed-by-default on Xenial. Which means that
> > everyone will always have it installed. However, that leads to a problem
> > with having a "standard" subnet dedicated to LXD. While it works for lots
> > of people, there are plenty of cases where that subnet would already be in
> > use elsewhere (in say a company's internal LAN). Which means LXD chose to
> > go with link-local addresses by default. AIUI that means that the
> > containers can talk to the host (and probably the host can route them to
> > the public internet?) but they aren't able to talk to other containers or
> > have inbound traffic.
> > My personal hope is that the dpkg-reconfigure steps can provide a 70%-case
> > safe default set of addresses (possibly using autodetection), and give a
> > nice wizard to help people, while still allowing them to override it in case
> >
> 
> I really fear for what this will do to adoption.  I feel like we're
> throwing the common "it just works" case out the window to enable a very
> small edge case to work slightly better.  I'd much rather have defaults
> where juju/lxd just works with most common setups.  For the one little
> exception - if the network on your corporate LAN conflicts - we give a nice
> error message and give the user tools to reconfigure.

The problem here is that there's no way to detect this case (e.g. what
if the network in question is routed behind your default gateway
somehow?). Things just break, and it can be difficult for people to
figure out why.

LXD's bridge setup defaults to ipv6 link local with an HTTP proxy that
allows apt-get to work. The current dpkg-reconfigure prompts will
suggest reasonable values if you decide you want to enable ipv4.

> Making everyone
> configure their network (not the easiest or friendliest task even for
> people on our own team), is surely going to cause us to lose a *lot* of
> users with a bad first impression.
> 
> LXD is our code.  Juju is our code.  Surely we can code/configure the two
> to work together such that it just works for the 95% case?

I assure you we're aware of this. Unfortunately there's not a good
answer.

Tycho

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Nate Finch]

On Tue, Apr 19, 2016 at 7:49 AM John Meinel  wrote:

> ...
>>>
>>
>
>>
>>> That's probably the cause of the other confusion in the updated docs -
>>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
>>> already has lxc setup in some fashion there's a different error from
>>> juju telling them to run the dpkg-reconfigure command. That should
>>> presumably always appear whenever there's no usable bridge.
>>>
>> The flip flopping back and forth on the bridge name is going to cause
>> havoc even after release. Do we have clear direction now from LXD on how
>> they plan to handle the competing network bridge names? I understand we're
>> now saying a dpkg-reconfigure is required, but I'm not clear if / when we
>> plan to make this easier.
>>
>
> So, LXD is going to be installed-by-default on Xenial. Which means that
> everyone will always have it installed. However, that leads to a problem
> with having a "standard" subnet dedicated to LXD. While it works for lots
> of people, there are plenty of cases where that subnet would already be in
> use elsewhere (in say a company's internal LAN). Which means LXD chose to
> go with link-local addresses by default. AIUI that means that the
> containers can talk to the host (and probably the host can route them to
> the public internet?) but they aren't able to talk to other containers or
> have inbound traffic.
> My personal hope is that the dpkg-reconfigure steps can provide a 70%-case
> safe default set of addresses (possibly using autodetection), and give a
> nice wizard to help people, while still allowing them to override it in case
>

I really fear for what this will do to adoption.  I feel like we're
throwing the common "it just works" case out the window to enable a very
small edge case to work slightly better.  I'd much rather have defaults
where juju/lxd just works with most common setups.  For the one little
exception - if the network on your corporate LAN conflicts - we give a nice
error message and give the user tools to reconfigure.  Making everyone
configure their network (not the easiest or friendliest task even for
people on our own team), is surely going to cause us to lose a *lot* of
users with a bad first impression.

LXD is our code.  Juju is our code.  Surely we can code/configure the two
to work together such that it just works for the 95% case?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Marco Ceppi]

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

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

Re: LXD polish for xenial

[John Meinel]

>
> ...
>>
>

>
>> That's probably the cause of the other confusion in the updated docs -
>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
>> already has lxc setup in some fashion there's a different error from
>> juju telling them to run the dpkg-reconfigure command. That should
>> presumably always appear whenever there's no usable bridge.
>>
> The flip flopping back and forth on the bridge name is going to cause
> havoc even after release. Do we have clear direction now from LXD on how
> they plan to handle the competing network bridge names? I understand we're
> now saying a dpkg-reconfigure is required, but I'm not clear if / when we
> plan to make this easier.
>

So, LXD is going to be installed-by-default on Xenial. Which means that
everyone will always have it installed. However, that leads to a problem
with having a "standard" subnet dedicated to LXD. While it works for lots
of people, there are plenty of cases where that subnet would already be in
use elsewhere (in say a company's internal LAN). Which means LXD chose to
go with link-local addresses by default. AIUI that means that the
containers can talk to the host (and probably the host can route them to
the public internet?) but they aren't able to talk to other containers or
have inbound traffic.
My personal hope is that the dpkg-reconfigure steps can provide a 70%-case
safe default set of addresses (possibly using autodetection), and give a
nice wizard to help people, while still allowing them to override it in
cases where their environment needs custom settings.



> Unlike other providers, lxd exposes no way to use the daily images
>> instead of release images, so at present any machine using lxd
>> containers with juju for the first time will get the xenial beta2
>> image then upgrade basically every package. This issue goes away next
>> week, but gets in the way of testing before then.
>>
> I think some workarounds for this were discussed -- did we have any
> success here? Do we have an issue filed upstream on this?
>

"juju bootstrap ... lxd --config image-stream=daily" should work here. I
have some pieces in place (but not all of them) to allow that sort of thing
to also work for "juju bootstrap ... aws && juju deploy --to lxd:" but its
trickier there, because we haven't been needing to pass this particular bit
of configuration down to containers. We have a way to do it, it just needs
time to get it done.



>
>
>>
>> In a related note, the lxc container handling in juju manages images
>> on the state server, but from what I see of the lxd code, each
>> deployed machine will fetch images from cloud-images.ubuntu.com and
>> keep a separate set of images. That makes the above problem much worse
>> for any bundle with multiple machines that use containers.
>>
> Same as above. I just want to make sure we don't loose sight of this and
> do our part in reporting it so upstream can seek to resolve at some point.
>

This is one of the known issues today, and is on the list to get done. Its
lower priority today because while it is important, the deploy does still
succeed, it just isn't as efficient, and we're currently focused on
correctness issues.

John
=:->


>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[John Meinel]

...

> On Mon, Apr 18, 2016, 2:17 PM Martin Packman 
>> 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.


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

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.

John
=:->
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: hacking upload tools for development

[Michael Foord]

On 14/04/16 19:38, Aaron Bentley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi there.

I've done a lot of work with simplestreams lately, and we've got some
decent tools for generating them quickly and easily.  I'd be happy to
work with someone from core to develop a tool to generate streams that
you can use in place of --upload-tools.


That sounds ideal.

Michael


Aaron

On 2016-04-14 09:52 AM, Nate Finch wrote:

I wrote a wiki page about how to hack bootstrap --upload-tools so
that it doesn't stop the controller from going through the normal
processes of requesting tools from streams etc.  This can be handy
when that's the part of the code you want to debug, but you need to
upload a custom binary with extra debugging information and/or
changes to that code.  It turns out that the changes are very
minimal, they're just hard to find and spread out in a few
different files.

Feel free to make corrections if there's anything I've missed or
could do better:
https://github.com/juju/juju/wiki/Hacking-upload-tools



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXD+ONAAoJEK84cMOcf+9hT/4IALfSUh8Z5r8FqzAROYq5FnMq
8UG3Do6FkN/zFDZBelM1NJpePOWqkyvcJbZSLHGsnbcDRMpADXju0LDALKKcx87p
AVzsiMea/7RcZi9ln2Pdb+Ct508eBK4IN7f8L20iA1x3i83gvZ9s1JzJ/Gxb9+KP
5ovkQ7MNnekjQz5ejCBFjRgOq31dIhTCV26QzaUqQxJnEmA5N2SpOfEgfsqcTGxX
PWQYLcm255er/QBp4Pr76bOAeVdqR0yGNx6N3fiezH39noNPQMl7L5bbWABk8DHc
by3FjrDdFYSQmEUPwJVmfK3lBD6JjdJH7y7fu4qE5A+Zp2mV2cN/mr3Fuw0m57I=
=PKZ7
-END PGP SIGNATURE-




--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev