Re: Upgrading charms to 16.01 - Ceph

Is upgrading ceph from one source to the other supported as well, or does the source only work for new deployments? I did this: ubuntu@maascontroller:~$ juju upgrade-charm ceph Added charm "cs:trusty/ceph-43" to the environment. and then: ubuntu@maascontroller:~$ juju set ceph source=cloud:trust

Re: Upgrading charms to 16.01

I worked it out as well :-) My final workflow is this (for charms that support the openstack-upgrade action): 1. Set the managed upgrade flag action-managed-upgrade=true 2. upgrade the charm: juju upgrade-charm 3. Set new origin openstack-origin=cloud:trusty-mitaka 4. uprade each unit juju a

Re: Upgrading charms to 16.01

On Fri, Jan 29, 2016 at 9:43 AM Pshem Kowalczyk wrote: > Ok, > > force-downgrade doesn't seem to work: > ubuntu@maascontroller:~$ juju upgrade-charm keystone > > > > ERROR already running latest charm "cs:trusty/keystone-33" > ubuntu@maascontroller:~$ juju upgrade-charm --force keystone > ERROR a

Re: Upgrading charms to 16.01

Pshem, I'm curious if switching would work for you... e.g. juju upgrade-charm --switch cs:trusty/glance-29 Thanks, Billy On Thu, Jan 28, 2016 at 3:43 PM, Pshem Kowalczyk wrote: > Ok, > > force-downgrade doesn't seem to work: > ubuntu@maascontroller:~$ juju upgrade-charm keystone > > > > ERRO

Re: Upgrading charms to 16.01

Ok, force-downgrade doesn't seem to work: ubuntu@maascontroller:~$ juju upgrade-charm keystone ERROR already running latest charm "cs:trusty/keystone-33" ubuntu@maascontroller:~$ juju upgrade-charm --force keystone ERROR already running latest charm "cs:trusty/keystone-33" I ended up removing

Re: Upgrading charms to 16.01

This is what I get: ubuntu@maascontroller:~$ juju upgrade-charm --force keystone 2016/01/29 10:43:02 warning: discarding cookies in invalid format (error: json: cannot unmarshal object into Go value of type []cookiejar.entry) 2016/01/29 10:43:04 warning: discarding cookies in invalid format (error

RE: Upgrading charms to 16.01

Hi Pshem On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: > I've tried to upgrade keystone to the new charm version (from liberty). > I've updated the source: > > juju set keystone openstack-origin=cloud:trusty-mitaka > > and scheduled an upgrade: > > juju upgrade charm keystone > > but the

Upgrading charms to 16.01

Hi, I've tried to upgrade keystone to the new charm version (from liberty). I've updated the source: juju set keystone openstack-origin=cloud:trusty-mitaka and scheduled an upgrade: juju upgrade charm keystone but the charm upgrade fails: 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could

FYI: Rename of "basic" layer repo

The repository for the base layer for reactive charms, "basic", has been renamed from "reactive-base-layer" to "layer-basic" to bring it in line with the convention discussed earlier on this list. The interfaces.juju.solutions API has been updated to reflect this, and GitHub handles the rename tra

Re: Reactive when_file_changed decorator question

Thank you for this. I proposed the idea of events here: https://github.com/juju-solutions/charms.reactive/issues/49 I think it would solve a lot of use-cases and bring some clarity in how these non-state predicates are handled. 2016-01-28 20:15 GMT+01:00 Cory Johns : > Merlijn, > > You are corre

Re: Reactive when_file_changed decorator question

Merlijn, You are correct, the order of handlers is undetermined, so it is entirely possible for the execution order to be: handler1, handler2, handler3, handler2. The predicates, including the @when_changed test, will be checked again after each round of dispatch, so handler2 should definitely be

Re: Apt layer released

This is so cool! I hope we can integrate this in the bigdata Charms. Letting users install additional dependencies is something that would come in handy! 2016-01-28 16:48 GMT+01:00 Stuart Bishop : > The Apt layer is more code broken out from my PostgreSQL charm work > that will be used by future

Re: Leadership layer released

On 28 January 2016 at 22:47, Merlijn Sebrechts wrote: > Hi Marco > > > Just to be clear, I was talking about wrapping the code to set a state that > shows if something changed. I wasn't sure how to implement this. States are > saved across hook invocations but 'x.changed' should be removed at the

Re: Leadership layer released

On 28 January 2016 at 21:42, Cory Johns wrote: > This is awesome. A very clean interface for dealing with leadership in > layered charms. > > I also very much like the pattern of having states that notify of changes to > the leadership settings and think this pattern could apply well to config >

Re: Apt layer released

Cool thanks for the additional info, I'm going to integrate this into my layers now On Thu, Jan 28, 2016 at 11:46 AM, Stuart Bishop wrote: > On 28 January 2016 at 23:01, Adam Stokes > wrote: > > Why would someone want to use this instead of what's provided in > > charmhelpers? > > This wraps wh

Re: Apt layer released

On 28 January 2016 at 23:01, Adam Stokes wrote: > Why would someone want to use this instead of what's provided in > charmhelpers? This wraps what is provided in charmhelpers. To use raw charmhelpers, you need to write the hooks and handlers to call its features at the right time and in the righ

[Review Queue] memcached

https://code.launchpad.net/~freyes/charms/trusty/memcached/lp1525026/+merge/281254 I reviewed a fix to allow the memcached charm’s tests to work (due to firewall issues). I reran tests on LXC and AWS and they f

Re: Apt layer released

Why would someone want to use this instead of what's provided in charmhelpers? On Thu, Jan 28, 2016 at 10:48 AM, Stuart Bishop wrote: > The Apt layer is more code broken out from my PostgreSQL charm work > that will be used by future Cassandra charm work. > > It provides a simple, charms.reactiv

Apt layer released

The Apt layer is more code broken out from my PostgreSQL charm work that will be used by future Cassandra charm work. It provides a simple, charms.reactive friendly interface for dealing with apt sources and deb packages. But I think its main utility is providing consistent configuration for those

Re: Leadership layer released

Hi Marco Just to be clear, I was talking about wrapping the code to set a state that shows if something changed. I wasn't sure how to implement this. States are saved across hook invocations but 'x.changed' should be removed at the end of a hook invocation. Stuart's code solves this problem by up

Re: Leadership layer released

I agree, I was just mulling over how to document all of these layers, something we all should discuss in Belgium at the Summit. As for wrapping, you shouldn't really need to wrap it since it's just a layer! Awesome job with this layer, loving its implementation! On Thu, Jan 28, 2016 at 10:29 AM M

Re: Leadership layer released

These 'changed.x' states are really useful! I wanted something like this in my own layers, but I wasn't sure on how to implement it.. It might be good to include this in the docs? Or maybe write a nice wrapper around this logic so it can be easily used in other layers? I know I will use it... 201

Reactive when_file_changed decorator question

Hi Cory I have a question about the reactive handlers. How exactly do when_file_changed handlers get dispatched? Consider the following: @when('init') def handler1(): change_file('file1') set_state('A') @when_changed('file1') def handler2(): restart_service() @when('A') def handle

Re: Leadership layer released

This is awesome. A very clean interface for dealing with leadership in layered charms. I also very much like the pattern of having states that notify of changes to the leadership settings and think this pattern could apply well to config settings. One addition I would suggest to that pattern wou

Re: Problems with colocated layered and non-layered Charms

Great! Thanks! 2016-01-28 14:18 GMT+01:00 Marco Ceppi : > This makes a little more sense. I'll chat with Cory later today about > getting the virtualenv stuff on the roadmap for charm build. > > Marco > > On Thu, Jan 28, 2016 at 8:01 AM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: >

Re: Problems with colocated layered and non-layered Charms

This makes a little more sense. I'll chat with Cory later today about getting the virtualenv stuff on the roadmap for charm build. Marco On Thu, Jan 28, 2016 at 8:01 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi Marco > > > The virtalenv flag would be really helpful and solve a

Re: Problems with colocated layered and non-layered Charms

Hi Marco The virtalenv flag would be really helpful and solve all my use-cases afaik! Any eta? For more context: I hulk smash a few Charms to enable full lxc support in a manual environment. - *lxc-networking* bridges lxcbr0 to a private network - *dhcp-server* assigns ip addresses to

Re: Problems with colocated layered and non-layered Charms

Is this a result of deploy --to ? If so, I expect there to be errors, "hulk smashing" services onto a single machine really isn't expected to work, it just "works" for a few combination of charms. Is there a reason you can't deploy to LXC or KVM containers? The isolation of a LXC containers on a si

Re: 16.01 OpenStack charm release

Congratulations on the release! I'm looking forward to giving these a spin and kicking the wheels of Mitaka :) On Thu, 28 Jan 2016 at 10:01 Liam Young wrote: > Hi All > > We are pleased to announce the 16.01 release of the OpenStack charms: > > https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/

16.01 OpenStack charm release

Hi All We are pleased to announce the 16.01 release of the OpenStack charms: https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1601 This release cycle has been mainly focused on maintenance and experimental support for Mitaka on Ubuntu 14.04. Cheers Liam -- Juju mailing list Juju@

Problems with colocated layered and non-layered Charms

Hi Layered Charms use Python 3 and install pip3 as default pip. This causes great problems for colocated non-layered Charms who expect that default pip is pip2. An example is the combination of juju-gui with any layered Charm. You get the following error: unit-juju-gui-0[8052]: 2016-01-28 09:35

Re: Mesos / Marathon with Juju

Hi John, We love your use case already. The current status is the following: * We have a legacy charm for Mesos, that scales out with slaves, and that runs Marathon. You can see it here: https://jujucharms.com/u/jonnybgod/mesos-master/trusty/5 * This charm has not yet been ported to the new charm