Re: Juju 2.2-rc2 has been released

On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Quick instructions on how the new azure credentials flow works in Juju > 2.2-RC2: > > # install az client using a snap > $ sudo snap install azure-cli --classic --edge > I've pushed the snap to stable, so

Re: Opaque automatic hook retries from API

^^ s/immutability/idempotency On Thu, Jan 5, 2017 at 12:39 PM, Casey Marshall < casey.marsh...@canonical.com> wrote: > On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard <adam.coll...@canonical.com> > wrote: > >> Hi, >> >> The automatic hook retries[0] tha

Re: Opaque automatic hook retries from API

On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard wrote: > Hi, > > The automatic hook retries[0] that landed as part of 2.0 (are documented > as) run indefinitely[1] - this causes problems as an API user: > > Imagine you are driving Juju using the API, and when you perform

Re: A (Very) Minimal Charm

On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi wrote: > On Thu, Dec 1, 2016 at 5:00 AM Adam Collard > wrote: > >> On Thu, 1 Dec 2016 at 04:02 Nate Finch wrote: >> >> On IRC, someone was lamenting the fact that the

Re: Github Reviews vs Reviewboard

+1, as I work on many other Github projects besides Juju and it's familiar. It's not perfect by any means but I can work with it. I thought the ReviewBoard we had was pretty ugly and buggy, but it was reasonably easy to use. Gerrit is cleaner and clearer to me -- though I feel like Gerrit is also

Re: Reviews on Github

I'm halfway through my first Github review (different project though) on the new system, and so far I'm loving it. Also consider the issues we've had with rbt being unable to handle diffs with files added/removed/relocated. +1 from me! -Casey On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien

Re: Latest new about Juju master branch - upload-tools obsoleted

I discovered another trick that works: set the streams and urls to invalid values in your bootstrap config. This will force Juju to use an already compiled jujud in your $PATH. For example, bootstrap --config with: image-metadata-url: http://localhost image-stream: nope agent-metadata-url:

Re: kill-controller, unregister, destroy-controller

My main use case for killing controllers is development & testing. For this, I have a script that force deletes all the juju-* LXC containers, and then unregisters all controllers with cloud: lxd. It's *much* faster than waiting for each juju controller to tear itself down. It's also nothing I'd

Re: Faster LXD bootstraps and provisioning

I decided it'd be easier & safer to host squid-deb-proxy in a LXD container rather than the host. My host doesn't route inbound to LXD from other networks, and all the Juju machines can see it. On Tue, Aug 16, 2016 at 12:30 AM, John Meinel wrote: > ... >> > > >> +###

Re: Faster LXD bootstraps and provisioning

Menno, This is great and thanks for sharing! In case anyone else runs into this.. charms that install from PPAs will fail with this squid-deb-proxy setup. You'll need to allow archive mirrors for this to work. See https://1337.tips/ubuntu-cache-packages-using-squid-deb-proxy/ for an example. On

Re: So I wanted to update a dependency . .

On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > This is a simple story of a man and a simple mission. Eliminate the final > 2 dependencies that are in bazaar and launchpad. It makes juju and it's > dependencies live completely in git. A notable goal, and

Automatic hook retries in Juju 2.0

What is the intended behavior for automatic hook retries in Juju 2.0? Specifically, I'd like to know, as a Juju user: Are errors in hooks all retried with the same policy, or are some retried with a different policy / strategy than others (install, for example)? Is there a limit to the number

Re: Awful dependency problem caused by romulus

Matty, this sounds like a great idea. Dave, I understand and thanks for clarifying. Please give us some time to coordinate the package relocation in our next iteration (begins next week). Thanks, Casey On Thu, May 19, 2016 at 2:57 AM, David Cheney wrote: > Thanks

Re: Awful dependency problem caused by romulus

On Wed, May 18, 2016 at 11:02 PM, David Cheney wrote: > Hello, > > github.com/juju/juju/cmd/juju/commands: > github.com/juju/romulus/cmd/commands: > github.com/juju/romulus/cmd/setplan: < > github.com/juju/juju/api/service: >

Re: Connecting to the controller database w/mongodb 3.2

send you links > > Well, for use case #1, yes, use the shell. For use case #2, I'd be using github.com/dcu/mongodb_exporter, which uses mgo.v2 and just needs a mongodb URI <https://github.com/dcu/mongodb_exporter/blob/master/mongodb_exporter.go#L26> . > On Friday, 13 May 201

Connecting to the controller database w/mongodb 3.2

I seem to be unable to connect to the Juju 2.0 controller database lately. I'm thinking this might be related to the move to mongodb 3.2. Can someone in the know please share how to do this? While most users should never, ever connect directly to the controller's database, I have two good use

Re: Reminder: write tests fail first

An excellent demonstration of writing tests that fail first that I've seen recently: https://www.youtube.com/watch?v=PEbnzuMZceA On Wed, May 4, 2016 at 9:24 PM, Andrew Wilkins wrote: > See: https://bugs.launchpad.net/juju-core/+bug/1578456 > > Cheers, > Andrew > >

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer < alexis.bruem...@canonical.com> wrote: > > Hi All, > > As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the > latest LXD will not work with Juju 2.0-beta3. This is a result of LXD > moving to use a default bridge of lxdbr0

Re: utils/fslock needs to DIAF

How about github.com/camlistore/lock ? On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey wrote: > Hi folks, > > The fslock was a mistake that I added to the codebase some time back. It > provided an overly simplistic solution to a more complex problem. > > Really the

Graduated Juju core reviewer: Aleš Stimec

All, I'm pleased to announce Aleš Stimec is now a graduated Juju core reviewer. His recent contributions and improvements to the Juju unit agent, command-line infrastructure and API login clearly demonstrate a depth and breadth of Juju core knowledge befitting this role. Welcome Aleš, and well

Fix for LP: #1174610 landing (unit ids should be unique)

Just a friendly heads-up.. a fix for this longstanding bug will be landing into master shortly: LP: #1174610, unit ids should be unique What this fix essentially does is assign each deployed workload a distinct unit ID (incrementing sequentially) within the scope of an environment. Example: 1.

Graduated reviewer: Domas Monkus

Juju developers, I would like to announce Domas Monkus is a fully graduated Juju core reviewer. This announcement is really long overdue.. Domas is careful and thoughtful in his reviews, his feedback is useful, actionable and relevant, and he's landed several significant improvements that

Re: Proposal: feature flag implementation for Juju

+1 for feature flags in general and +1 for using environment variables in upstart to get them to the servers agents. I think it'd be nice to have an environment variable per flag, with a common prefix JUJU_FEATURE_. That way, if you need to check one in a package init(), you don't have to parse

Re: Reminder: juju-core github migration

On 06/02/2014 11:57 AM, Martin Packman wrote: On 02/06/2014, roger peppe rogpe...@gmail.com wrote: What is the policy around rebasing before commenting with $$merge$$ ? Does this need to be done? If not, how does the merge procedure decide what commit message gets attached to the final merge?