conjure-up dev summary: aws native integration, vsphere <3, and ADDONS

New dev summary is out! http://blog.astokes.org/conjure-up-dev-summary-aws-cloud-native-integration-and-vsphere-3/ -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Weekly Development Summary

Hi folks A summary of what we've been doing this week in Juju. Two new Azure regions have been added - koreasouth and koreacentral. To use these on an existing Juju 2.x install, simply run $ juju update-clouds We continue to prepare for the 2.2.3 release. We were hoping to pull the trigger this

Re: Elasticsearch Charm Promulgation

Kevin, "Or is that source waiting on this PR to bring it in line with your es-7 charm" - This is the case If we merge the xenial support PR, it will be even with the cs:~jamesbeedy/elasticsearch-7. ~James On Fri, Aug 18, 2017 at 11:35 AM, Kevin Monroe wrote: >

Re: Elasticsearch Charm Promulgation

Hey James! First up, thanks so much for bringing the ES charm up to v5.x! Can you tell me if the source for cs:~jamesbeedy/elasticsearch-7 is the same as what we've got here: https://github.com/charms/charm-elasticsearch Or is that source waiting on this PR to bring it in line with your es-7

Re: How to quickly re-deploy the same charm

With juju 2, you can also use --force-units to upgrade the charm even in an error state: juju upgrade-charm --path /path/to/mycharm --force-units mycharm The unit agent will then usually retry the hook that's failing automatically, but you can use `juju resolved` on the unit(s) without the

Re: How to quickly re-deploy the same charm

Did `juju upgrade-charm`. Saw "Added charm...". It works, sometimes, not consistently. The new code changes are not reflected on juju machine. Why is that? Any way to force a reload? On 08/18/2017 09:40 AM, Tom Barber wrote: Yeah you need to do juju resolved charmunit/0 --no-retry to get it

Re: designate-charm/designate-sink patch backport request

Alex, All here it is: https://bugs.launchpad.net/designate/+bug/1711647 Regards Patrizio 2017-08-17 15:47 GMT+02:00 Alex Kavanagh : > Hi Patrizio > > From the looks of the bug report, it seems to have been backported to > stable/ocata, but judging from your links,

Re: How to quickly re-deploy the same charm

Yeah you need to do juju resolved charmunit/0 --no-retry to get it out of the error state so that the upgrade happens. On Fri, Aug 18, 2017 at 2:32 PM, fengxia wrote: > Hi Juju, > > So here is what I got: > > 1. juju status shows `mycharm` is in an error state. > > 2. Fixed

Re: How to quickly re-deploy the same charm

Hi Juju, So here is what I got: 1. juju status shows `mycharm` is in an error state. 2. Fixed the bug and built a new version of the same application charm. 3. `juju upgrade-charm --path /path/to/mycharm mycharm It says `Added charm local:trusty/mycharm to the model". But nothing happens

Re: How to quickly re-deploy the same charm

juju upgrade-charm is I suspect what you're looking for . Tom On Fri, Aug 18, 2017 at 1:58 PM, fengxia wrote: > Hi Juju, > > I'm testing a locally built charm using `localhost` (LXD) setup. Everytime > `juju deploy` will take a good 5-10 minutes just to download and install

How to quickly re-deploy the same charm

Hi Juju, I'm testing a locally built charm using `localhost` (LXD) setup. Everytime `juju deploy` will take a good 5-10 minutes just to download and install python packages before the charm code runs. I'm wondering what's a good practice to cut down this in dev iteration? So if I build a