Re: New releases of Juju 2.2.0 and conjure-up 2.2.0 are here!

[Dean Henrichsmeyer]

On Thu, Jun 15, 2017 at 1:05 AM, Burton Swan 
wrote:

> We are excited to announce the release of Juju 2.2.0 and conjure-up 2.2.0!
> This release greatly enhances memory and CPU utilisation at scale, improves
> the modelling of networks, and adds support for KVM containers on arm64.
> Additionally, there is now outline support for Oracle Compute, and vSphere
> clouds are now easier to deploy.
>

Rather than enhances, this release *reduces* memory and CPU utilization at
scale. One can certainly argue that reducing memory/CPU is an enhancement,
I just wanted to make sure that was clear. :)

-Dean
-- 
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 10:39 PM, John Meinel 
wrote:

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

OK, there's confusion. When I say supporting 'lxc' in bundles, I mean
literally supporting the word 'lxc' - not actually supporting traditional
LXC containers. If Juju 2.0 sees 'lxc' in a bundle, it will use LXD
containers for those targets. In the case of bundles and Juju 2.0, the word
'lxc' and 'lxd' will be interchangeable in order to allow for backwards
compatibility. Juju 2.0 won't support both LXC and LXD containers. Does
that make more sense?

That simply allows for having bundles that work with both Juju 1 and Juju 2
and does NOT require Juju 2.0 to support traditional LXC containers.

-Dean
-- 
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: Automatic retries of hooks

[Dean Henrichsmeyer]

On Wed, Jan 20, 2016 at 11:41 AM, William Reade  wrote:

> On Wed, Jan 20, 2016 at 3:22 PM, Rick Harding 
> wrote:
>
>> +1 retries are great, with backoff, when you know you're doing it because
>> you have experience that certain api requests to clouds, or to other known
>> failure points.
>>
>
> If you're thinking about it in terms of "known failure points" you already
> understand that you need a wide net to catch all the retryable errors that
> could come out of a given operation. What makes hook execution different
> from any other code that we want to be reliable?
>
> Blindly just saying "if at first you don't succeed, go go go" isn't a
>> better UX. It adds another layer of complexity in debugging, and doesn't
>> really improve the product. Only the charm author knows enough about what
>> it's trying to achieve to do intelligent retry.
>>
>
> Empirically, it seems that the retries caused jamespage's charm succeed
> where it would have failed; and we have happy results from Gabriel's
> windows charms as well. That STM to be evidence that the product is
> improved...
>

You realize James was complaining and not celebrating the "success" ? The
fact that we can have a discussion trying to determine whether something is
a bug or a feature indicates a problem.

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

Re: Automatic retries of hooks

[Dean Henrichsmeyer]

Hi,

It seems the original point James was making is getting missed. No one is
arguing over the value of being able to retry and/or idempotent hooks. Yes,
you should be able to retry them and yes nothing should break if you run
them over and over.

The point made is that Juju shouldn't be automatically retrying them. The
argument of "no one knows what went wrong so Juju automatically retrying
them is a better experience" doesn't work. The intelligence of the stack in
question, regardless of what it is, goes in the charms. If you start
conflating and mixing up where the intelligence goes then creating,
running, and debugging those distributed systems will be a nightmare.

The magic should only be in Juju's ability to effectively drive the models
and intelligence encoded in the charms. It shouldn't make assumptions about
what that intelligence is or what those models require.

Thanks.

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