Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

So this means the older format should work? Antonio, have you poked through that thread at the original working setup for local charms? On Mon, Mar 28, 2016 at 9:45 PM Antonio Rosales < antonio.rosa...@canonical.com> wrote: > > > On Monday, March 28, 2016, Ian Booth

Re: Reserved actions

+1 to reserving the juju* space just as we do with relations and such. On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi > wrote: > >> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <

Re: Reserved actions

+1 to reserving the juju* space just as we do with relations and such. On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi > wrote: > >> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <

Re: Reserved actions

On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi wrote: > On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> Hi, >> >> There's a code review in progress (http://reviews.vapour.ws/r/4286/) >> that will introduce a predefined action,

Re: Reserved actions

I believe that reserving the juju- prefix would be good. I, personally, haven't seen any charms using them. -- José Antonio Rey On Mon, Mar 28, 2016, 21:04 Marco Ceppi wrote: > On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: >

Re: Reserved actions

On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins wrote: > Hi, > > There's a code review in progress (http://reviews.vapour.ws/r/4286/) that > will introduce a predefined action, "juju-run", which is part of the > replacement for the current SSH-based juju-run. > This

Re: Reserved actions

On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins wrote: > Hi, > > There's a code review in progress (http://reviews.vapour.ws/r/4286/) that > will introduce a predefined action, "juju-run", which is part of the > replacement for the current SSH-based juju-run. > This

Reserved actions

Hi, There's a code review in progress (http://reviews.vapour.ws/r/4286/) that will introduce a predefined action, "juju-run", which is part of the replacement for the current SSH-based juju-run. This means that "juju-run" will no longer be a valid action name for use in a charm. This may come up

Reserved actions

Hi, There's a code review in progress (http://reviews.vapour.ws/r/4286/) that will introduce a predefined action, "juju-run", which is part of the replacement for the current SSH-based juju-run. This means that "juju-run" will no longer be a valid action name for use in a charm. This may come up

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

On Monday, March 28, 2016, Ian Booth wrote: > Hey Antonio > > I must apologise - the changes didn't make beta3 due to all the work > needed to > migrate the CI scripts to test the new hosted model functionality; we ran > out of > time to be able to QA the local bundle

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

On Monday, March 28, 2016, Ian Booth wrote: > Hey Antonio > > I must apologise - the changes didn't make beta3 due to all the work > needed to > migrate the CI scripts to test the new hosted model functionality; we ran > out of > time to be able to QA the local bundle

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

Hey Antonio I must apologise - the changes didn't make beta3 due to all the work needed to migrate the CI scripts to test the new hosted model functionality; we ran out of time to be able to QA the local bundle changes. I expect this work will be done for beta4. On 29/03/16 11:04, Antonio

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

Hey Antonio I must apologise - the changes didn't make beta3 due to all the work needed to migrate the CI scripts to test the new hosted model functionality; we ran out of time to be able to QA the local bundle changes. I expect this work will be done for beta4. On 29/03/16 11:04, Antonio

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

+ Juju list for others awareness On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth wrote: > Thanks Rick. Trivial change to make. This work should be in beta3 due next > week. > The work includes dropping support for local repositories in favour of path > based local charm and

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

+ Juju list for others awareness On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth wrote: > Thanks Rick. Trivial change to make. This work should be in beta3 due next > week. > The work includes dropping support for local repositories in favour of path > based local charm and

Re: Go 1.6 is now in trusty-proposed

My point is not to advocate for a specific solution but rather to suggest that *any* sensible incremental approach will produce real results. --Mark Ramm On Mon, Mar 28, 2016 at 7:51 PM, David Cheney wrote: > On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Christensen

Re: Go 1.6 is now in trusty-proposed

On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Christensen (Canonical.com) wrote: > Never a good time to stop feature work entirely and fix what amounts to a > race prone set of tests. > > > But I would advocate building in some practices to improve the situation

Re: Planning for Juju 2.2 (16.10 timeframe)

A feature that I think would clean up the deployment of multi-charm bundles would be the ability to deploy directly to lxc containers without specifying or pre-adding a machine. For example, in a juju on maas deployment, upon charm deploy, juju would query maas and request a new machine, but let

Re: Go 1.6 is now in trusty-proposed

Never a good time to stop feature work entirely and fix what amounts to a race prone set of tests. But I would advocate building in some practices to improve the situation incrementally: - fixing one major issue per team per week - promoting all issues which fail CI more than x times per

Re: Move provider implementations under their related projects.

I agree with all the responses, I don't think it'd be helpful to move the providers. It's our job to track the API changes. For most of the upstreams, backwards incompatible changes are fairly infrequent. If it's difficult to track API changes, perhaps it's the same for other consumers of the

Should Charms disable SSLv3 and RC4?

Hi all, Right now if you deploy juju-gui or openstack-dashboard (and likely many more) they will follow the 14.04 default and have SSLv3 and RC4 enabled. In both cases this can make the communication insecure. 1) Should we default SSLv3/RC4 to disabled in charms that we know we can? For

Re: Move provider implementations under their related projects.

I'm a very strong -1 on this idea. Providers are Juju specific, and the other libraries should focus on exposing a useful Go API. Tim On 25/03/16 10:12, Eric Snow wrote: > Perhaps we should move the implementation of some providers over to > the repos for the projects with which the providers

Office Hours video: Charm tools and release status

Hello everyone, fresh from last Friday: https://www.youtube.com/watch?v=wSJn-67PuhA I would like to point out that Marco's overview of the new charm tool will be important to any of you who have been waiting for the ability to self-publish in the charm store. -- Jorge Castro Canonical Ltd.

Re: Go 1.6 is now in trusty-proposed

I'll just note that we've had flaky tests for as long as I've been working on Juju, and there's never a "good" time to fix them. :) On Mon, Mar 28, 2016 at 11:48 AM Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2016-03-28 09:03 AM,

Re: Go 1.6 is now in trusty-proposed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-03-28 09:03 AM, Katherine Cox-Buday wrote: > Generally +1 on this, but I'm also intrigued by Martin's > statistic... do we currently weight test failures by how likely > they are to fail (i.e. how likely they are flaky)? That seems like > it

Re: Go 1.6 is now in trusty-proposed

These intermittently failing unit tests are often due to unreliable unit tests, rather than problems in the code. As nice as it would be to not have to retry tests (particularly unit tests), I'd much rather we spend our precious resources on fixing bugs that are causing pain for our users. There

Re: Go 1.6 is now in trusty-proposed

Totally agreed: 2.0 is obviously the priority. I didn't think anyone was talking about a short-term pivot. On 03/28/2016 10:34 AM, Cheryl Jennings wrote: > Addressing flaky tests is definitely a long term goal we should have. > > Given that we are aiming for beta4 next week, I'd rather our

Re: Go 1.6 is now in trusty-proposed

Addressing flaky tests is definitely a long term goal we should have. Given that we are aiming for beta4 next week, I'd rather our energies in the short term are directed at fixing stakeholder bugs than fixing intermittent failures that prevent us from releasing because we are no longer retrying

Re: Go 1.6 is now in trusty-proposed

While agreeing with the spirit of your email, Cheryl, I'd like to opine that in the long-term fixing flaky tests will improve the code and help to fix (and prevent!) bugs. Put another way, flaky tests are indirectly causing pain for our users. On 03/28/2016 10:24 AM, Cheryl Jennings wrote: >

Re: Go 1.6 is now in trusty-proposed

+1, don't retry... devs need to feel the pain in order to get proper motivation to fix this stuff... On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Just wanted to say thank you 100x to all involved! > > On 03/24/2016 01:03 AM, Michael

Re: Go 1.6 is now in trusty-proposed

Just wanted to say thank you 100x to all involved! On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote: > Hi, > > As of a few minutes ago, there is now a golang-1.6 package in > trusty-proposed: > https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the > review and copy, Steve). > >

Re: Go 1.6 is now in trusty-proposed

Generally +1 on this, but I'm also intrigued by Martin's statistic... do we currently weight test failures by how likely they are to fail (i.e. how likely they are flaky)? That seems like it would be a great metric to use to decide which to fix first. On 03/28/2016 01:29 AM, David Cheney wrote: >

Re: Query on IBM-Installtion Manger Charm Layer

Hi Kevin, As you suggested we have made all the changes to IBM Installation Manger layer (https://github.com/kwmonroe/layer-ibm-installation-manager) locally ( in ./reactive/ibm-installation-manager.sh) to make it is a functional layer and we are able to deploy IBM-IM successfully. But when

Re: Go 1.6 is now in trusty-proposed

I know if we didn't retry constantly, the Juju tests'd never pass. But by retrying, there is no impetus to fix them. How about we stop retrying flaky tests? The blocked build get's the grease. On Mon, Mar 28, 2016 at 5:23 PM, Martin Packman wrote: > On 27/03/2016,

Re: Go 1.6 is now in trusty-proposed

On 27/03/2016, David Cheney wrote: > Hi Martin, > > I was told that the Go 1.6 tests were voting, so these bugs should be > blocking bugs. Is this not the case ? The tests are voting, and giving blesses, so no blocking bugs, but a lot of the remaining issues are