Re: upgrade-charm and default configuration values

Hi there Marco, On Wed, Mar 9, 2016 at 4:18 AM Marco Ceppi wrote: > Hello everyone! > > tl;dr: upgrade-charm also updates default configuration which can break > running deployments. Should we be updating charms anyways esp since > defaults are now broken for fresh

httpbakery .Client overly restrictive on body - io.ReaderSeeker

Hi folks, I came across this recently while looking at sending tools and charms between two controllers. The local storage interface gives us an io.ReaderCloser. Unfortunately, we can't give that to the http client for the POST method as it needs an io.ReaderSeeker. I'd like to challenge the

Re: admin is dead, long live $USER

I think I did remove some of that code, because it wasn't being used and wasn't clear why it was there. Easy enough to put back in. Cheers, Andrew On Mon, Mar 7, 2016 at 8:40 AM Tim Penhey wrote: > Ah yeah... it is mostly coming back to me now. > > I actually have a

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 16:04, Tom Barber wrote: > Also, for stuff like monitoring, being able to position a charm service on > a different service provider to bolster resiliency. That comes implicitly with cross-model relations, since the different models can be on different clouds. This enables pretty

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 15:59, Tom Barber wrote: > From my perspective relationship joins that can span models would be great. > I know I brought it up before, but being able to create, for example a > central monitoring model, or central Gitlab model that charms in my various > other models could tap into

Re: upgrade-charm and default configuration values

Thanks Marco, if I understand what we're dealing with is there a pattern here where we can get a little mix of both worlds? What I'm wondering is that, if the charm author needs to make these default changes for a good reason, that we can bring it to user's attention using the blocked status? Can

Re: Planning for Juju 2.2 (16.10 timeframe)

Also, for stuff like monitoring, being able to position a charm service on a different service provider to bolster resiliency. Tom On 8 Mar 2016 23:59, "Tom Barber" wrote: > Hi Mark > > From my perspective relationship joins that can span models would be > great. I

Re: Planning for Juju 2.2 (16.10 timeframe)

Hi Mark >From my perspective relationship joins that can span models would be great. I know I brought it up before, but being able to create, for example a central monitoring model, or central Gitlab model that charms in my various other models could tap into without them being merged into a

Re: Juju 2.0 and local charm deployment

So to clarify what we'll do. We'll support the same syntax in bundle files as we do for deploy. Deploys charm store charms: $ juju deploy cs:wordpress $ juju deploy wordpress Deploys a local charm from a directory: $ juju deploy ./charms/wordpress $ juju deploy ./wordpress So below deploys a

Planning for Juju 2.2 (16.10 timeframe)

Hi folks We're starting to think about the next development cycle, and gathering priorities and requests from users of Juju. I'm writing to outline some current topics and also to invite requests or thoughts on relative priorities - feel free to reply on-list or to me privately. An early cut of

Re: Juju stable 1.25.4 is proposed for release

WOOT! Thank you to the teams for pushing hard to get this out! On Tue, Mar 8, 2016 at 2:17 PM, Curtis Hovey-Canonical wrote: > # juju-core 1.25.4 > > A new proposed stable release of Juju, juju-core 1.25.4, is now available. > This release may replace version 1.25.3 on

Re: Juju stable 1.25.4 is proposed for release

WOOT! Thank you to the teams for pushing hard to get this out! On Tue, Mar 8, 2016 at 2:17 PM, Curtis Hovey-Canonical wrote: > # juju-core 1.25.4 > > A new proposed stable release of Juju, juju-core 1.25.4, is now available. > This release may replace version 1.25.3 on

Juju stable 1.25.4 is proposed for release

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

Juju stable 1.25.4 is proposed for release

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

Re: Reactive roadmap

Simon, You raise some very interesting questions and good points. I've also been developing charms with layers, run into some of these same issues, and developed a pragmatic approach that has helped me manage it pretty well so far. In a more mature layer/interface ecosystem, it might not be the

Re: Juju 2.0 and local charm deployment

Long term we want to have a pattern when the bundle is a directory with local charms in a directory next to the bundles.yaml file. We could not do this cleanly before the multi-series charms that are just getting out the door. I think that bundles with local charms will be suboptimal until we can

upgrade-charm and default configuration values

Hello everyone! tl;dr: upgrade-charm also updates default configuration which can break running deployments. Should we be updating charms anyways esp since defaults are now broken for fresh deploys? Discuss. We've had a problem pop up a few times and I wanted to start a discussion about it with

Reactive roadmap

Hi all My team (Online Services at Canonical) maintains >20 private charms for our services, plus a few charmstore charms. Most of these charms are written with charmhelpers ansible support, or with the Services framework. We would like to move towards consolidating these approaches (as both

Re: Automatic periodic upgrades as part of the base layer

On 8 March 2016 at 05:24, Marco Ceppi wrote: > This is definitely more an operator decision than a charm decision. There > are two existing charms to address this. An unattended-upgrades charm and > landscape-client. Check those out first to see if the fit your needs. >