Juju 2.4-rc3 has been released

A new development release of Juju is here, 2.4-rc3. This release candidate addresses an issue upgrading from earlier Juju versions as described below. ## Fixes An upgrade step has been added to initialise the Raft configuration. This would normally be done at bootstrap time but needs to be done

Re: redhat, centos, oracle linux images for vmware deployment

Hey Dan The Ubuntu images used to bring up a vSphere VM are downloaded from cloud-images.ubuntu.com. We use images in an ova archive format. Here's where the xenial ones are sourced from for example: http://cloud-images.ubuntu.com/xenial/current/ Juju uses simplestreams metadata to select the

Re: juju deploys with a vsphere controller using hardware vm version 10

Hi Daniel The Juju vSphere provider currently only supports hardware version 10, but 14 is now the most recent according to the VMWare website. If we were simply to track and support the most recent hardware version, would that work for you? On 05/02/18 12:38, Daniel Bidwell wrote: > Is there

Re: Juju 2.3 beta2 is here!

> * Parallelization of the Machine Provisioner >> >> Provisioning of machines is now faster! Groups of machines will now be >> provisioned in parallel reducing deployment time, especially on large >> bundles. Please give it a try and let us know what you think. >> >> Benchmarks for time to

Re: Juju 2.3 beta2 is here!

>> >> * Parallelization of the Machine Provisioner >> >> >> Provisioning of machines is now faster!  Groups of machines will now >> be provisioned in parallel reducing deployment time, especially on >> large bundles.  Please give it a try and let us know what you think. >> > > This is great.

Re: Juju Storage/MAAS

> Here machines 1 and 2 are deployed without the `--constraints`, > http://paste.ubuntu.com/25862219/ > > > Am I missing something? Possibly like one more input to the `--storage` arg? > > > Thanks > > [0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27 >

Re: Juju Storage/MAAS

Thanks for raising the issue - we'll get the docs updated! On 01/11/17 07:44, James Beedy wrote: > I knew it would be something simple and sensible :) > > Thank you! > > On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com> wrote: > >> Of the

Re: Juju Storage/MAAS

Of the top of my head, you want to do something like: $ juju create-storage-pool ssd-disks maas tags=ssd $ juju deploy postgresql --storage pgdata=ssd-disks,32G The above assumes you have tagged in MAAS any SSD disks with the "ssd" tag. You can select whatever criteria you want and whatever tags

Juju development summary

Hi folks Here's a quick wrap up of what the Juju team has been doing lately. A chunk of time has been spent planning what we want to work on next cycle leading up to the 18.04 LTS. Issues/features required by the field take a high priority, including (but not limited to): - audit logging -

Re: default network space

On 19/10/17 16:33, Ian Booth wrote: > > > On 19/10/17 15:22, John Meinel wrote: >> So at the moment, I don't think Juju supports what you're looking for, >> which is cross model relations without public addresses. We've certainly >> discussed supporting all privat

Re: default network space

On 19/10/17 15:22, John Meinel wrote: > So at the moment, I don't think Juju supports what you're looking for, > which is cross model relations without public addresses. We've certainly > discussed supporting all private for cross model. The main issue is that we > often drive parts of the

Re: default network space

Copying in the Juju list also On 12/10/17 22:18, Ian Booth wrote: > I'd like to understand the use case you have in mind a little better. The > premise of the network-get output is that charms should not think about public > vs private addresses in terms of what to put into rela

Re: default network space

I'd like to understand the use case you have in mind a little better. The premise of the network-get output is that charms should not think about public vs private addresses in terms of what to put into relation data - the other remote unit should not be exposed to things in those terms. There's

Juju 2.3 beta1 is here!

After many months of effort, we're pleased to announce the release of the first beta for the upcoming Juju 2.3 release. This release has many long requested new features, some of which are highlighted below. Please note that because this is a beta release (the first one at that), there may likely

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

Weekly Development Summary

Hi folks Here's a quick wrap up of what the Juju team has been doing this week. We're almost ready for a new 2.2.3 release. Issues addressed are found on the milestone: https://launchpad.net/juju/+milestone/2.2.3 Some highlights include bundles supporting local resources, migration and upgrade

Re: PROPOSAL: stop recording 'executing update-status hook'

On 23/05/17 06:39, Stuart Bishop wrote: > On 22 May 2017 at 20:02, roger peppe wrote: > >> not to show in the status history. Given that the motivation behind >> the proposal is to reduce load on the database and on controllers, I > > One of the motivations was to

Re: PROPOSAL: stop recording 'executing update-status hook'

On 22/05/17 18:23, roger peppe wrote: > I think it's slightly unfortunate that update-status exists at all - > it doesn't really need to, > AFAICS, as a charm can always do the polling itself if needed; for example: > > while :; do > sleep 30 > juju-run $UNIT 'status-set

Weekly Development Summary

Hi folks That time of the week again - almost beer o'clock for those of us in Aus/NZ timezones - and also time to recap on the happenings in the land of Juju development over the past 7 days. We're working hard to get a Juju 2.2 out the door. The week saw a release of 2.2 beta4 which included

Re: juju/retry take 2 - looping

I really like where the enhancements are headed. I feel they offer the syntax that some folks wanted, with the safety and validation of the initial implementation. Best of both worlds. On 20/10/16 13:09, Tim Penhey wrote: > Hi folks, > > https://github.com/juju/retry/pull/5/files > > As often

Re: Github Reviews vs Reviewboard

-1000 :-) On 14/10/16 08:44, Menno Smits wrote: > We've been trialling Github Reviews for some time now and it's time to > decide whether we stick with it or go back to Reviewboard. > > We're going to have a vote. If you have an opinion on the issue please

upcoming change in Juju 2.0 to bootstrap arguments

See https://bugs.launchpad.net/juju/+bug/1632919 The order of the cloud/region and controller name arguments will be swapped. Old: $ juju bootstrap mycontroller aws/us-east-1 New: $ juju bootstrap aws/us-east-1 mycontroller or now $ juju bootstrap aws/us-east-1 Notice how controller name is

Re: Reviews on Github

On 16/09/16 03:50, Nate Finch wrote: > Reviewboard goes down a couple times a month, usually from lack of disk > space or some other BS. According to a source knowledgeable with these > matters, the charm was rushed out, and the agent for that machine is down > anyway, so we're kinda just

Re: Reviews on Github

On 16/09/16 08:54, Anastasia Macmood wrote: > On 16/09/16 08:02, Ian Booth wrote: >> Another data point - in the past, when we have had PRs which touch a lot of >> files (eg change the import path for a dependency), review board paginates >> the >> diff so it's muc

Re: Reviews on Github

gt;> As for the inline comments in the code - there's a checkbox to hide them >> all. It's not quite as convenient as the gutter indicators per-comment, >> but it's sufficient, I think. >> >> On Wed, Sep 14, 2016 at 6:43 PM Ian Booth <ian.bo...@canonical.com> w

Re: Reviews on Github

One thing review board does better is use gutter indicators so as not to interrupt the flow of reading the code with huge comment blocks. It also seems much better at allowing previous commits with comments to be viewed in their entirety. And it allows the reviewer to differentiate between issues

A couple of API changes coming in Juju beta18 this week

Just a heads up, 3 APIs are moving to a different facade. There's no other semantic changes other than the move. The only externally end user visible difference is that the juju model-defaults command operates only on a controller and no longer supports specifying a model using -m. The APIs are

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

On 16/08/16 12:58, Tim Penhey wrote: > > > On 16/08/16 10:50, Ian Booth wrote: >> >> On 16/08/16 03:09, Nate Finch wrote: >>> Ian, can you describe how Juju decides if it's running for a developer or >>> an end user? I'm worried this could trip people u

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

On 16/08/16 03:09, Nate Finch wrote: > Ian, can you describe how Juju decides if it's running for a developer or > an end user? I'm worried this could trip people up who are both end users > and happen to have a juju development environment. > It's not so much Juju deciding - the use cases

Latest new about Juju master branch - upload-tools obsoleted

So if you pull master you'll no longer need to use upload-tools. Juju will Do the Right Thing*, when you type: $ juju bootstrap mycontroller aws|lxd|whatever or $ juju upgrade-juju *so long as your $GOPATH/bin is in your path (as a developer). 1. As a user, you bootstrap a controller using a

Re: Some Juju CLI usability thoughts before we close 2.0

On 11/08/16 17:46, Ian Booth wrote: > > On 11/08/16 17:03, John Meinel wrote: >> On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth <ian.bo...@canonical.com> wrote: >> >>> A few things have been irking me with some aspects of Juju's CLI. Here's a >>> few >

Re: Some Juju CLI usability thoughts before we close 2.0

On 11/08/16 17:03, John Meinel wrote: > On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth <ian.bo...@canonical.com> wrote: > > > A few things have been irking me with some aspects of Juju's CLI. Here's a > > few > > thoughts from a user perspective (well, me as user, YMM

Some Juju CLI usability thoughts before we close 2.0

A few things have been irking me with some aspects of Juju's CLI. Here's a few thoughts from a user perspective (well, me as user, YMMV). The following pain points mainly revolve around commands that operate on a controller rather than a model. eg $ juju login [-c controllername] fred $ juju

Re: Juju and snappy implementation spike - feedback please

I personally like the idea that the snap could use a juju-home interface to allow access to the standard ~/.local/share/juju directory; thus allowing a snap and regular Juju to be used interchangeably (at least initially). This will allow thw use case "hey, try my juju snap and you can use your

Juju and snappy implementation spike - feedback please

Hi folks The below refers to work in a branch, not committed to master. TL:DR; I've made some changes to Juju so that a custom build can be easily snapped and shared. The snap is still required to be run in devmode until new interfaces are done. TL;DR2; The way upload-tools works has been

Re: Windows and --race tests are now gating

Turning on gating for Windows tests before all tests were passing is premature and is now blocking us from landing critical fixes for beta12 that we need to release this week for inclusion into xenial. With the race tests, we got all of those passing before turning on gating. We need to do the

Re: Beta9

As well as the user visible things like the great new status output and rename of service to application etc, beta 9 contains a lot of below the waterline changes geared towards our future feature work. We should start to see the benefit of that work in the next beta and upcoming release

Re: Automatic commit squashing

On 16/06/16 19:04, David Cheney wrote: > Counter suggestion: the bot refuses to accept PR's that contain more > than one commit, then it's up to the submitter to prepare it in any > way that they feel appropriate. > Please no. I do not want to be forced to alter my local history. I was hopeful

Re: Juju 2.0-beta9 ETA

On 13/06/16 22:58, Rick Harding wrote: > On Sat, Jun 11, 2016 at 6:32 PM Ian Booth <ian.bo...@canonical.com> wrote: > >> We are also storing any config specified in clouds.yaml separately. These >> items, >> such as apt-mirror, are shared between

Re: Juju 2.0-beta9 ETA

On 12/06/16 02:30, Dean Henrichsmeyer wrote: > On Fri, Jun 10, 2016 at 1:20 PM, Cheryl Jennings < > cheryl.jenni...@canonical.com> wrote: > > >> Some of the great things coming in beta9 include: >> - Separation of controller config vs. model config >> > > Will this one have user-facing

Advance notice - removal of local repo URLs committed to master

Hi folks We communicated back in early March that Juju 2.0 would no longer support local charms deployed using a local charm repository and local charm URLs like local:trusty/mysql. The final piece has landed in master, which is support for local bundles to declare their contained charms to as

Re: Unable to kill-controller

On 05/04/16 11:12, Andrew Wilkins wrote: > On Mon, Apr 4, 2016 at 8:32 PM Rick Harding > wrote: > >> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < >> andrew.wilk...@canonical.com> wrote: >> >>> In a non-beta release we would make sure that the config changes

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

Mar 28, 2016 at 9:45 PM Antonio Rosales < > antonio.rosa...@canonical.com> wrote: > >> >> >> On Monday, March 28, 2016, Ian Booth <ian.bo...@canonical.com> wrote: >> >>> Hey Antonio >>> >>> I must apologise - the changes didn'

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

Rosales wrote: > + Juju list for others awareness > > > On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth <ian.bo...@canonical.com> wrote: >> Thanks Rick. Trivial change to make. This work should be in beta3 due next >> week. >> The work includes dropping support for

Re: Go 1.6 is now in trusty-proposed

On 24/03/16 22:01, Nate Finch wrote: > Does this mean we can assume 1.6 for everything from now on, or is there > some other step we're waiting on? I have some code that only needs to > exist while we support 1.2, and I'd be happy to just delete it. > Not yet. The builders and test

Re: Go 1.6 is now in trusty-proposed

OMFG that is the best news. We can finally get the Juju LXD provider working properly on trusty :-D And first class support for all architectures etc :-D And no more chasing gccgo issues :-D Thanks Michael and whoever else helped make this possible. On 24/03/16 16:03, Michael Hudson-Doyle wrote:

Re: Usability issues with status-history

On 20/03/16 22:44, John Meinel wrote: >> >> ... >> >> For the second bug, where a downloading % spams the history, it seems like >> the easy answer is "don't do that". For resources, we specifically avoided >> putting download progress in status history for that very reason. In the >> future,

Usability issues with status-history

Machines, services and units all now support recording status history. Two issues have come up: 1. https://bugs.launchpad.net/juju-core/+bug/1530840 For units, especially in steady state, status history is spammed with update-status hook invocations which can obscure the hooks we really care

Re: Usability issues with status-history

ed 3 times, last occurence: 26 Dec 2015 14:01:57Z agent executing running update-status hook 26 Dec 2015 14:01:59Z agent idle > On Thu, Mar 17, 2016 at 6:30 AM, John Meinel <j...@arbash-meinel.com> wrote: > >> >> >> On Thu, Mar 17, 2016 at 8:41 AM, Ian Booth

Re: Do we still need juju upgrade-charm --switch ... ?

> > We use switch a lot, and customers use this as well. The primary use case > is "I have a bug in production charm that is not available upstream yet". I > expect future 2.0 uses to look like this: > > charm pull > > juju upgrade-charm --switch ./ > > Another example, esp because of how

Do we still need juju upgrade-charm --switch ... ?

So we have a feature of upgrade-charm which allows you to crossgrade to a different charm than the one originally deployed. >From the upgrade-charm help docs: The new charm's URL and revision are inferred as they would be when running a deploy command. Please note that --switch is dangerous,

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

series specified, > e.g. jujucharms.com/mysql then the cli command should not either. Right now > I know we add the series/revision info and such. Over time we want to try > to get to as simple a command as possible. > > On Thu, Mar 10, 2016 at 7:23 AM Ian Booth <ian.bo...@canonical.c

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

I've implemented option 1: error if Series attribute is used at all with a store charm URL Trivial to change if needed. On 10/03/16 12:58, Ian Booth wrote: > Yeah, agreed having 2 ways to specify store series can be suboptimal. > So we have 2 choices: > > 1. error if Series attri

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

have to have >> this. For remote charms though this is providing the user two ways to do >> the same thing >> >> On Wed, Mar 9, 2016, 9:46 PM Ian Booth <ian.bo...@canonical.com> wrote: >> >>> If the charm store charm defines a series in the URL,

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

al. I think we should toss an error to a bundle that has series: > specified for a charmstore based charm value (or non-local value whichever > way you want to think about it) > > On Wed, Mar 9, 2016 at 6:29 PM Ian Booth <ian.bo...@canonical.com> wrote: > >> One additio

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

09:53, Ian Booth wrote: > 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: &

Re: Juju 2.0 and local charm deployment

> On Tue, Mar 8, 2016 at 12:26 PM Martin Packman <martin.pack...@canonical.com> > wrote: > >> On 05/03/2016, Ian Booth <ian.bo...@canonical.com> wrote: >>>> >>>> How will bundles work which reference local charms? Will this work as >&g

Re: Juju 2.0 and local charm deployment

> > Does this mean it won't be possible to deploy old single-series > charms with Juju without modifying metadata.yaml to add the supported > series? > You can use the --series argument $ juju deploy ./trusty/mysql --series trusty We could look at pulling the series out of the path if it's an

Re: Juju 2.0 and local charm deployment

Hey Marco > > I'm a +1 > > How will bundles work which reference local charms? Will this work as > expected where nova-compute is a directory at the same level as a bundle > file? > > ``` > series: trusty > services: > nova-compute: > charm: ./nova-compute > num_units: 2 > ``` >

Re: admin is dead, long live $USER

Hey Tim The new bootstrap UX has not removed any --admin-user flag. I can see that the server jujud bootstrap command has an --admin-user argument but it appears this is never set anywhere in the cloud init scripts. Or not that I can see. I've checked older version of the relevant files and can't

Juju 2.0 and local charm deployment

Hi folks TL;DR we want to remove support for old style local charm repositories in Juju 2.0 Hopefully everyone is aware that Juju 2.0 and the charm store will support multi-series charms. To recap, a multi-series charm is one which can declare that it supports more than just the one series; you

Re: LXD support (maybe)

> >> I personally encourage us to use heterogeneous versions of go as much as >> we can. Because we should be compatible as much as possible. But it does >> look like our dependencies are going to force our hand. >> > > Agreed. I think it's healthy for Juju's devs to be using a range of Go >

Re: LXD support (maybe)

FWIW, go 1.6 works just fine with Juju on my system On 26/02/16 08:34, Menno Smits wrote: > On 26 February 2016 at 04:59, Horacio Duran > wrote: > >> be aware though, iirc that ppa replaces your go version with 1.6 (or used >> to) which can mess your env if you are

Please merge master into your feature branches

FYI for folks developing feature branches for juju-core. juju-core master has been updated to include the first round of functionality to improve the bootstrap experience. The consequence of this is that CI scripts needed to be updated to match. This means that any feature branch which has not

Re: Breaking news - New Juju 2.0 home^H^H^H^H data location

Yes >> Very, very soon, the need for an environments.yaml file will be no more, Hopefully in time for the 2.0 beta due sometime next week. On 09/02/16 01:33, Adam Stokes wrote: > Does this mean the environments.yaml file is going away at some point? > > On Mon, Feb 8, 2016

Breaking news - New Juju 2.0 home^H^H^H^H data location

As advance notice, the next alpha release of Juju 2.0 (due this week) will use a new default home location. Juju will now adhere to the the XDG desktop standard and use this directory (by default): ~/.local/share/juju to store its working files (%APPDATA%/Juju on Windows). This is partly to

Juju terminology change: controllers and models

Hey all As has been mentioned previously in this list, for the Juju 2.0 release we have been working on fundamental terminology changes. In particular, we now talk about controllers and models instead of state servers and environments. To this end, a rather large change has landed in master and

Re: Juju terminology change: controllers and models

ced ServiceDeployWithNetworks still exists as a client and > facade method, but it's only called by tests. Maybe it should be removed? > > On Tue, Feb 2, 2016, 8:34 PM Ian Booth <ian.bo...@canonical.com> wrote: > >> Hey all >> >> As has been mentioned previously in this list, for

Re: "environment" vs "model" in the code

Thoughts? > > > > On 15 January 2016 at 21:05, roger peppe <roger.pe...@canonical.com> wrote: > >> On 15 January 2016 at 06:03, Ian Booth <ian.bo...@canonical.com> wrote: >>> >>> >>> On 15/01/16 10:16, Menno Smits wrote: >&g

Re: "environment" vs "model" in the code

On 15/01/16 10:16, Menno Smits wrote: > Hi all, > > We've committed to renaming "environment" to "model" in Juju's CLI and API > but what do we want to do in Juju's internals? I'm currently adding > significant new model/environment related functionality to the state > package which includes

Re: Running upgrade steps for units

On 16/09/15 12:06, Menno Smits wrote: > On 16 September 2015 at 08:41, Tim Penhey wrote: > >> On 15/09/15 19:38, William Reade wrote: >>> Having the machine agent run unit agent upgrade steps would be a Bad >>> Thing -- the unit agents are still actively running the

Re: workers using *state.State

Those workers below aren't the only ones. There's also minunits and peergrouper workers. No-one does these things on purpose. Just last week I caught and rejected a pull request to introduce a new worker depending on state directly. People make mistakes. Perhaps we should introduce a test which

Re: Dreamhost progress

On 17/07/15 09:42, Ian Booth wrote: Next step is generate image metadata for the trusty image given by `nova image-list` which is the same as before: $ juju metadata generate-image -i c55094e9-699c-4da9-95b4-2e2e75f4c66e -s trusty Then bootstrap with --upload-tools and --metadata-source

Re: Recurring fails on windows tests and the recent CentOS failure

+100 And if the only reason for embedding a suite is to use a helper type function that does not require that suite's setup/teardown, then it really should be factored out as a standalone function to be shared. On 16/07/15 10:46, Tim Penhey wrote: I'm in agreement with Bogdan, Roger and William

Re: Blocking bugs process

On 14/07/15 23:26, Aaron Bentley wrote: On 2015-07-13 07:43 PM, Ian Booth wrote: By the definition given If a bug must be fixed for the next minor release, it is considered a ‘blocker’ and will prevent all landing on that branch. that bug and any other that we say we must include

Re: Fwd: juju 1.24.alpha1

Copying to juju-dev as this info is generally useful. Hey Thanks for the feedback. The status YAML output will *always* be available, but when Juju 2.0 ships, will no longer be the default. That will be tabular which is much more human readable. So as of Juju 2.0, whenever that ships, instead

Re: bugs, fixes and targeting Juju versions

Yes, cheery pick is something I use all the time, as it fills out the PR in the latter branches with a nice commit message based on the original and also includes the original PR from which the commit was first done. On 05/05/15 11:45, Jesse Meek wrote: Ah, even better. Now I can update my

Re: Do not land code on blocked branches

, but we can bump the Version of the API and change the behavior. We definitely should have done that here rather than just remove the behavior. John =:- On Sun, May 3, 2015 at 3:59 PM, Richard Harding rick.hard...@canonical.com wrote: On Sun, 03 May 2015, Ian Booth wrote: Curtis has

Re: Do not land code on blocked branches

Curtis has filed three new bugs for these so far, and there appears to be one or two more to come: https://bugs.launchpad.net/juju-core/+bug/1450912 The issue here is that quickstart is relying on Juju 1.16 behaviour. There was a block of code with a comment: // Remove this whole if block

Re: Do not land code on blocked branches

Curtis has filed three new bugs for these so far, and there appears to be one or two more to come: https://bugs.launchpad.net/juju-core/+bug/1450912 https://bugs.launchpad.net/juju-core/+bug/1450917 The quickstart bugs have two root causes. A fix has already landed for one issue. A fix

Re: previously valid amazon environment now invalid?

Right now, the default tabular output is behind a feature flag because it's experimental. We still need to decide how to allow users to have that output by default without the feature flag, but also without breaking 1.18 script compatibility. The best option IMO for this case is an env variable on

Re: previously valid amazon environment now invalid?

On 30/04/15 21:04, roger peppe wrote: On 30 April 2015 at 11:55, Ian Booth ian.bo...@canonical.com wrote: Right now, the default tabular output is behind a feature flag because it's experimental. We still need to decide how to allow users to have that output by default without the feature

Re: previously valid amazon environment now invalid?

On 29/04/15 04:41, Nate Finch wrote: No one seems to be answering my actual question. That error message seems new. Is it? Either way, the error message is incorrect - control bucket is not required - and whatever is emitting that message needs to be fixed. On Apr 28, 2015 2:32 PM, Aaron

Re: Juju storage - early access

We have implemented support for creating volumes in the ec2 provider, via the ebs storage provider. By default, the ebs provider will create cheap and nasty magnetic volumes. There is also an ebs-ssd storage pool provided OOTB that will create SSD (gp2) volumes. Finally, you can create your

Re: Bleeding edge testers - do you want to try some new Juju Health/Status functionality?

basis. On 02/04/15 19:18, Ian Booth wrote: Hi rocket scientists, If you don't mind living on the bleeding edge, and are comfortable pulling Juju source from Github and compiling, we'd love to get some feedback on a very early version of the new Juju Unit and Service Status work. What's

Re: Is simplestreams spam worth having in the Log

TL;DR: A lot of the spam is necessary to diagnose when simplestreams look up fails, or you get the wrong tools. In such cases, it's extremely useful to see where the search path has looked. This was especially the case in the early days when published tools and associated metadata sometimes were

Re: Please, no more types called State

On 12/03/15 16:53, Tim Penhey wrote: On 12/03/15 18:13, Ian Booth wrote: I see the point. But it could be considered analogous to having lots of methods called New() etc. So long as the types are relevant for the package in which they're declared then isn't that ok? If we have lots

Re: Please, no more types called State

I see the point. But it could be considered analogous to having lots of methods called New() etc. So long as the types are relevant for the package in which they're declared then isn't that ok? If we have lots of packages where state needs to be persisted, how is that different to having lots of

Re: juju status --format=tabular

+1 from me too - we should be able to do this next week before the freeze on the 27th On 19/02/15 15:09, Tim Penhey wrote: On 19/02/15 17:07, John Meinel wrote: I was wondering if we could change the sorting to be numeric aware instead of just alphabetical. Specifically if you have more than

Re: New Package for Feature Tests

Thank you Katherine, it's great to see this important work come to fruition. One area of the code in particular which will benefit from this is the CLI, implemented in cmd/juju. Historically, cmd/juju unit tests were written on top of a full stack (as an aside, any test suite which embeds

Re: Dear reviewers,

On 03/12/14 13:34, Tim Penhey wrote: Hello there reviewers, I have a number of concerns around reviews that I need to say. Firstly, as an on call reviewer, you only need to look at the reviews that have not yet been looked at. If you ask for changes on a branch as a reviewer, you have a

Re: Proposal: feature flag implementation for Juju

I like feature flags so am +1 to the overall proposal. I also agree with the approach to keep them immutable, given the stated goals and complexity associated with making them not so. I think the env variable implementation is ok too - this keeps everything very loosely coupled and avoids

Re: Feature Request: show running relations in 'juju status'

On 17/11/14 15:47, Stuart Bishop wrote: On 17 November 2014 07:13, Ian Booth ian.bo...@canonical.com wrote: The new Juju Status work planned for this cycle will hopefully address the main concern about knowing when a deployed charm is fully ready to do the work for which it was installed

Re: Feature Request: show running relations in 'juju status'

On 15/11/14 15:44, Stuart Bishop wrote: On 14 November 2014 22:31, Mario Splivalo mario.spliv...@canonical.com wrote: Hello, good people! How hard would it be to implement 'showing running relations in juju status'? Currently there is no easy (if any) way of knowing the state of the

Re: Can we removed all devel agents from released streams.

On 14/11/14 06:28, Curtis Hovey-Canonical wrote: We have another cases where an env using --upload-tools tried to upgrade from 1.18.4 to 1.20.x and got 1.19.x. I want to remove all the devel agents from the released streams. We have already created separate streams for devel and proposed

Re: Can we removed all devel agents from released streams.

On 14/11/14 13:38, John Meinel wrote: I don't think we care about older development releases, but if we care at all, they won't be able to look anywhere but the released stream. (Only 1.21 knows how to handle agent-stream/tools-stream, right?) Correct. But I don't think we should support

Re: reviewboard-github integration

, Dimiter On 20.10.2014 16:53, Eric Snow wrote: On Mon, Oct 20, 2014 at 6:06 AM, Ian Booth ian.bo...@canonical.com wrote: Hey Eric This is awesome, thank you. I did run into a gotcha - I created a PR and then looked at the Incoming review queue and there was nothing new there. I then clicked

Re: reviewboard-github integration

Hey Eric This is awesome, thank you. I did run into a gotcha - I created a PR and then looked at the Incoming review queue and there was nothing new there. I then clicked on All in the Outgoing review queue and saw that the review was unpublished. I then went to publish it and it complained at

Re: State should not depend on the API server

On 16/09/14 19:19, roger peppe wrote: On 16 September 2014 02:12, Tim Penhey tim.pen...@canonical.com wrote: On 12/09/14 01:35, Nate Finch wrote: Separation of logic is absolutely a good thing. Separation of data is not nearly so useful. What I see as the real benefit of this work is

Juju landing tests - good news

Hi folks It's been a fantastic effort so far improving the quality of our tests; so much so that this time yesterday I switched off the retry flag. This means that our landing tests run at full speed, and fail first time if there's an error. Since the change, I've seen a few failures due to

  1   2   >