Juju stable 1.25.3 is proposed for release

# juju-core 1.25.3 A new proposed stable release of Juju, juju-core 1.25.3, is now available. This release may replace version 1.25.0 on Thursday January 21. ## Getting Juju juju-core 1.25.3 is available for Xenial and backported to earlier series in the following PPA:

Master is unblocked

Hi Everyone, Yesterday we had a blessed CI run on master which we will be releasing as our 2.0-alpha1. The final touches will be put on the release notes and we will turn the crank to get an official release shortly. In the meantime, I've unblocked master. So, let the thundering herd of merges

Re: Automatic retries of hooks

On Mi, 2016-01-20 at 10:39 -0500, Aaron Bentley wrote: > On 2016-01-20 10:30 AM, Gabriel Samfira wrote: > > The auto-retry thing was created to overcome situations in which > > the machine is rebooted, or chashes during a hook run > > (independently of juju). In this case, the charm would not be

Re: Automatic retries of hooks

On Wed, Jan 20, 2016 at 2:42 PM, Dean Henrichsmeyer wrote: > 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

Re: Automatic retries of hooks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-01-20 10:30 AM, Gabriel Samfira wrote: > The auto-retry thing was created to overcome situations in which > the machine is rebooted, or chashes during a hook run > (independently of juju). In this case, the charm would not be able > to

Re: Automatic retries of hooks

The auto-retry thing was created to overcome situations in which the machine is rebooted, or chashes during a hook run (independently of juju). In this case, the charm would not be able to recover automatically from a transient situation. This scenario is more evident in Windows workloads,

Re: Automatic retries of hooks

On 20 January 2016 at 17:46, William Reade wrote: > On Wed, Jan 20, 2016 at 8:46 AM, Stuart Bishop > wrote: >> It happens naturally if you structure your charm to have a single hook >> that does everything that needs to be done, rather

Re: Automatic retries of hooks

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

Re: Automatic retries of hooks

On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer wrote: > > 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. > Sorry, I didn't

Re: Automatic retries of hooks

On Mi, 2016-01-20 at 21:31 +0100, William Reade wrote: > On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer < > d...@canonical.com> wrote: > > You realize James was complaining and not celebrating the "success" > > ? The fact that we can have a discussion trying to determine > > whether something

LXD and trusty-backports

For juju-2.0 we know that we want to be using LXD for containers. However, I don't believe LXD itself is going to land in trusty-updates. It *is* already in trusty-backports. My concern is that if we end up enabling trusty-backports, that may cause conflicts with charms, as they may get versions

Re: "environment" vs "model" in the code

On Mon, Jan 18, 2016 at 8:24 PM, Rick Harding wrote: > No, there's not been a public note yet. It's work going into the 2.0 > updates currently. > > The gist of the reason is that as support for things such as networking, > storage, and workloads expand out the idea

Re: LXD and trusty-backports

So according to https://help.ubuntu.com/community/UbuntuBackports backports is enabled by default, as long as you explicitly request the packages from backports. I did test bootstrapping an lxd trusty machine and then running: apt-get install lxd/trusty-backports lxc/trusty-backports

Re: LXD and trusty-backports

On 20/01/2016, John Meinel wrote: > So according to https://help.ubuntu.com/community/UbuntuBackports backports > is enabled by default, as long as you explicitly request the packages from > backports. Yeah, that's the case for fresh machines, backports just has a lower

Re: Automatic retries of hooks

Another common error we see in CI is apt mirrors being unhappy leading to hook failures. Just retry later does tend to be the right option there, though it will often be an our or two until the archive is in a usable state again. On 20/01/2016, William Reade wrote: >

Re: Automatic retries of hooks

On 20 January 2016 at 12:20, Martin Packman wrote: > Another common error we see in CI is apt mirrors being unhappy leading > to hook failures. Just retry later does tend to be the right option > there, though it will often be an our or two until the archive is in a

Re: Automatic retries of hooks

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

Re: Automatic retries of hooks

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