2.0 as default on main repos?

Hello everyone, I am deploying some production servers and am seeing a weird behavior: 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories of archive.ubuntu.com 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable Is this intended? Doesn't feel right to me.

Re: juju run-action --application?

Those are all good points - but they also seem like implementation details. For example if an action relied on coordination around the leader then the action should be written to protect against that - since it may still break if the user was to run juju run-action myapp/0 && juju run-action

Re: Juju as a snap

On Tue, Aug 2, 2016 at 5:00 PM, Nicholas Skaggs wrote: > Feedback is welcome and appreciated! If you are running ubuntu 16.04 you > already have snappy installed. Give it a try! I just wanted to also point out that this enables the Juju client to run on

[Review Queue] collectd, and prometheus

I reviewed the collectd and prometheus charms today. The reactive code is very well written and both charms deployed correctly. The charms still had the basic auto-generated tests, and the readme files were VERY minimal. Both charms would fail the lint step on bundletester (our automated testing

Re: [ANN] New juju-deployer-0.9.0, python-jujuclient-0.53.1

With quick turn around this is now available for immediate testing in the charmbox:devel flavor of images docker pull jujusolutions/charmbox:devel You can get started right away with some volume mounts to bring in your charm's and $JUJU_DATA location. We on the ~containers team have a bash alias

Re: juju run-action --application?

Because of the ambiguous nature of actions and application. Some would expect, as you do, to run on all units. Others would expect the leader to coordinate that action. Furthermore, it becomes more complex as to how results are curated. Do you get back X UUIDs one for each unit or a single action

Re: [ANN] New juju-deployer-0.9.0, python-jujuclient-0.53.1

Excellent news! Thanks, Tim. On Wed, Aug 3, 2016 at 12:04 PM Charles Butler wrote: > Thanks for the heads up Tim. > > I'll get a build pressed for charmbox:devel to get these latest test > additions in there right now while I'm context switching. > > Thanks a bunch

[ANN] New juju-deployer-0.9.0, python-jujuclient-0.53.1

These new releases work with the latest juju-2.0 betas while maintaining compatibility with juju-1.25. They are currently available on PyPI and in ppa:tvansteenburgh/ppa, and will likely be copied to ppa:juju/stable in the near future. Find bugs? File here:

Do you docker? How about layer-docker? Learn how in this weeks post

Greetings everyone, I spent some time hacking up a deep dive on how to work with layer-docker, the darling layer from the ~containers team making onboarding users looking to use docker in their juju experience even easier. http://dasroot.net/posts/2016-08-03-layer-docker-deep-dive/ This breaks

Re: Juju as a snap

For now, it's here: https://github.com/nskaggs/snap-juju Indeed as Marco pointed out, it should get upstreamed into the juju repo. The needed interfaces and issues with strict mode are discussed in the README there as well. Nicholas On 08/02/2016 05:11 PM, Tom Barber wrote: I saw you guys

Re: Juju as a snap

On 3 August 2016 at 04:00, Nicholas Skaggs wrote: > The Juju client has been snappified and pushed to the juju store. Note for > now it's just an amd64 build. > > snap install juju --beta --devmode > > The beta channel contains the latest beta, 2.0-beta13. This is