Moving conversations to discourse and closing this list.

Hi all, Juju is moving with the times and moving to have a central place for conversations, questions, and soon, documentation. We are using Discourse [1] and it can be found here: https://discourse.jujucharms.com/ Discourse offers a very nice interface for conversations, and has a bot walk

We are pulling he 2.3.6 agents

Hey people, We have field reports where a 2.3.6 upgrade interacted badly with some charm settings causing Juju to get itself into a stuck, somewhat corrupt state. We are still evaluating how to fix this for stuck systems. The symptom is the 2.3.6 upgrade fails and gets stuck. The agents are

Re: Juju's dependencies, juju/utils and a road forward

Which then begs the question... Why do we have stable gopkg.in branches depending on unstable branches? i.e. gopkg.in/juju/charmstore.v5 depending on gopkg.in/macaroon-bakery.v2-unstable? This seems to smell bad. Tim On 04/04/18 14:17, Tim Penhey wrote: > As a follow on... > >

Re: Juju's dependencies, juju/utils and a road forward

As a follow on... I'd like to move juju to only use "stable" dependency branches. No more '-unstable'. Tim On 04/04/18 12:52, Tim Penhey wrote: > Hi folks, > > Juju has a problem with its dependencies. We have been trying to upgrade > a number of our dependencies r

Juju's dependencies, juju/utils and a road forward

Hi folks, Juju has a problem with its dependencies. We have been trying to upgrade a number of our dependencies recently have have been hitting road blocks. Mostly because of changes to common libraries that are incompatible with other libraries that we use. I'm pretty sure that the root of all

Re: More juju upgrade-juju failings

erospace-grade upgrades through live migration to newer controllers? > > Mark > > On 02/27/2018 11:26 PM, Tim Penhey wrote: > > Hi Daniel, > > > > The issue here is that you are upgrading the default model, not the > > controller model it

Re: More juju upgrade-juju failings

Hi Daniel, The issue here is that you are upgrading the default model, not the controller model itself. I think we could make the error messaging more clear, and also have the command also check the controller version before showing a lot of baffling output. What you need to do is upgrade the

2.3.3 delayed slightly

Hi folks, Just to let you know that the 2.3.3 release that was planned for today is going to be delayed a day or two while we fix some upgrade issues that were caught late. At least they were caught before the release, so that is a good thing. Cheers, Tim -- Juju-dev mailing list

Beware 2.2.7 release

Hi folks, Last night we were alerted to a fundamental issue with the 2.2.7 agent only release. There was a weird race condition that was only observable on larger models which would cause a model to be non-responsive to controller generated events, like config updates, actions, juju run etc. We

Re: Juju 2.3-rc2 is here!

Hi Merlijn, You should be able to go: juju upgrade-juju -m controller That should do the trick. If the client version is different you may want to specify the agent version: juju upgrade-juju -m controller --agent-version 2.3-rc2 Tim On 07/12/17 06:26, Merlijn Sebrechts wrote: > Is there

Re: Juju 2.3 beta2 is here!

On 10/11/17 12:12, Dmitrii Shcherbakov wrote: > It's situations like the following that I am trying to avoid: > >   rabbitmq-server: >     charm: cs:xenial/rabbitmq-server >     bindings: >       "": *oam-space >       amqp: *internal-space >       cluster: *internal-space >     options: >      

Re: Juju 2.3 beta2 is here!

m's suggestion for "existing" but I'm not > entirely sure about that word - it's quite long and it doesn't quite > express the identity relationship that I see there. How about "same"? > > For example: > >      juju deploy --to 1=2,2=3,same some

Re: Juju 2.3 beta2 is here!

On 09/11/17 13:06, Mark Shuttleworth wrote: > On 11/07/2017 03:11 PM, John Meinel wrote: >> ... >>   >> >> > Perhaps just: >> > >> >   juju deploy --map-machines A=B,C=D >> > >> > ... or some variant of that? >> > >> > Let's use the betas to refine and condense and

Juju 2.3 release train starting

Hi folks, We are gearing up to release Juju 2.3. Juju 2.3 brings two headline features: * Cross model relations - the ability to relate applications in different models * Persistent storage - storage can outlive the unit or model it was created for. The team will be releasing 2.3-beta1

Re: We are excited to announce the release of Juju 2.2.3!

We are still getting the docs updated. https://jujucharms.com/docs/2.2/charms-bundles#setting-charm-configurations-options-in-a-bundle has a note about the include-file:// and include-base64:// items. We still seem to be missing details about --bundle-config. Tim On 08/09/17 22:41, Sandor

Re: developer commands

dev focused, and both only usable by admins. Tim On 29/08/17 13:11, Andrew Wilkins wrote: > On Mon, Aug 28, 2017 at 5:17 PM Tim Penhey <tim.pen...@canonical.com > <mailto:tim.pen...@canonical.com>> wrote: > > FYI, the developer commands were originally desi

Re: developer commands

FYI, the developer commands were originally designed like the controller commands. You don't say "juju destroy-model -m foo". Tim On 28/08/17 19:48, Anastasia Macmood wrote: > Hi > > Just a quick note for developers that use developer commands. > > 'juju dump-model' and 'juju dump-db' are

Re: developer commands

binMOC2fYDKR9.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Organising apiserver facades

I agree with John. Having the agent facades separate from the client facades would also be good. Tim On 06/07/17 23:09, John Meinel wrote: > I'd really like to see us split apart the facades-by-purpose. So we'd > collect the facades for Agents separately from facades for Users (and > possibly

Re: We are excited to announce the release of Juju 2.2.1!

Yes indeed. Congratulations to the whole team. Tim On 23/06/17 23:35, Ante Karamatić wrote: > Congrats! > > Excellent release and some of our high profile users are already on > 2.2.1 as of now. The fact that one can just upgrade big > environments like that, while drinking coffee, speaks

Release schedule

Hi folks, 2.2.1 should be released hopefully by this time tomorrow. It includes a number of key fixes that didn't quite make the 2.2.0 release but were sufficiently important that we wanted to get another release out quick smart. >From now we will enter what we hope to be a four week cadence for

develop has been branched in preparation of 2.2-rc1 release

Hi all, develop is now the future 2.3 branch. A patch will be landing soon to bump the version. There is now a 2.2 branch. This branch will be used for the 2.2 release candidate. Landings onto this branch are currently restricted. The restriction will be lifted when 2.2.0 is released. Thanks,

Re: Weekly Development Summary - and Juju 2.2-rc1 date

On 02/06/17 18:07, Anastasia Macmood wrote: > On 02/06/17 15:11, Tim Penhey wrote: ... >> Once we have confirmation from Solutions QA and JAAS that they are happy >> with the release candidate, we will release is as 2.0.0 > 2.2.0 maybe? Yes. That is what I meant. Thanks,

Weekly Development Summary - and Juju 2.2-rc1 date

bintUcW_UQOrQ.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: /etc/juju/certs.d status?

Pretty sure it can be removed and cleaned up now. Thanks Roger On 25/05/17 02:22, roger peppe wrote: I recently came across the code introduced by https://github.com/juju/juju/pull/2294 which provides support for reading extra certificates from /etc/juju/certs.d when connecting to an API

2.2-rc1 progress

Hi folks, The development team is fully focused on fixing the remaining issues for the upcoming release candidate. The key things that still need to be done before the release candidate are: * fixing migration of models using local charms and local resources * adding robustness around

Scale testing analysis

Hi folks, We had another scale test today to analyse why the controller CPU usage didn't fall away as expected when the models were removed. I'll be filing a bunch of bugs from the analysis process, but there is one bug that is, I believe, the culprit for the high CPU usage. Interestingly

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

On 20/05/17 19:48, Merlijn Sebrechts wrote: On May 20, 2017 09:05, "John Meinel" > wrote: I would actually prefer if it shows up in 'juju status' but that we suppress it from 'juju status-log' by default. This is still very

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

On 19/05/17 19:21, roger peppe wrote: On 19 May 2017 at 03:13, Tim Penhey <tim.pen...@canonical.com> wrote: Hi folks, Currently juju will update the status of any hook execution for any unit to show that it is busy doing things. This was all well and good until we do things based o

PROPOSAL: stop recording 'executing update-status hook'

Hi folks, Currently juju will update the status of any hook execution for any unit to show that it is busy doing things. This was all well and good until we do things based on time. Every five minutes (or so) each unit will have the update-status hook executed to allow the unit to set or

Weekly Development Summary

Hi folks, We are trying a new initiative to provide a simple way for casual observers of the mailing list to be able to get a quick view into the work being done in Juju. There are several key areas of development that are ongoing within the Juju team. Polish for the upcoming 2.2 release.

Re: Constraints for Additional Units

On 17/03/17 14:23, James Beedy wrote: Currently, if I scale the units of my application, the new units do not have the same constraints as the previously deployed units. Well, I certainly think they should be carrying over the constraints as the constraints are set on the application, not the

Re: regression: restore-backup broken by recent commit

On 24/02/17 16:17, Tim Penhey wrote: Also, a CI run of a develop revision just before the gorilla/websocket reversion hit this: http://reports.vapour.ws/releases/4922/job/functional-ha-backup-restore/attempt/5045#highlight cannot create collection "txns": unauthorized mo

Re: regression: restore-backup broken by recent commit

Hi Curtis (also expanding to juju-dev), I have been looking into this issue. And the good news is that it doesn't appear to be a real problem with gorilla/websocket at all, but instead a change in timing showed an existing issue that hadn't surfaced before. I'll be looking into that issue -

Re: removing colours from loggo package

Tech board says "yes let's do it", I'll respond to PR. On 22/02/17 14:15, Andrew Wilkins wrote: On Tue, Feb 21, 2017 at 10:02 PM roger peppe > wrote: In August, the loggo package was changed to make it log ANSI-terminal

Change in underlying websocket library

Hi folks, Just merged into the "devel" branch (will be 2.2 branch) is a change in the library Juju is using for websockets. Hopefully you won't notice a thing, but if you do see strange interactions I'd love to know. I did test with new CLI / old controller, and it works, and tested with

Next 2.1 release to be beta5 not rc1

Hi all, Based on a number of key issues with beta4, and the nature of some of the networking changes that will be landing at the start of next week, it is clear that the next release isn't a release candidate, as we need to make sure we have dealt with the issues. I'm not a fan of calling

Re: A (Very) Minimal Charm

Make sure you also run on LXD with a decent delay to the APT archive. That is what makes my local testing slow. Tim On 15/12/16 13:34, Marco Ceppi wrote: So, I wanted to circle back around to this thread. I think a lot of good feedback has come from this, and we're looking into making the

Re: juju/retry take 2 - looping

On 26/10/16 10:30, Katherine Cox-Buday wrote: I think this is a hint that this is the wrong approach. The edge-cases begin showing the cracks in the abstraction and end up making the code more complex. Consider your example instead of: var finalResult Foo for loop := retry.Loop(spec);

Re: juju/retry take 2 - looping

Some comments first, then addressing issues: I thought it might help if I walked you through my thought process of making this change. * the purpose of the retry package is to provide a way to retry actions that may fail until they succeed, or some predetermined limit is hit * the way that

juju/retry take 2 - looping

Hi folks, https://github.com/juju/retry/pull/5/files As often is the case, the pure solution is not always the best. What seemed initially like the best approach didn't end up that way. Both Katherine and Roger had other retry proposals that got me thinking about changes to the juju/retry

Re: Juju 2.0 is here!

I concur. You only have to use 1.25 for a short while again to see how far Juju has come. Be proud of your work, celebrate the release. Go team! Tim On 14/10/16 17:50, Mark Shuttleworth wrote: Congrats everyone, this is a release to be proud of. Multi-user multi-model, great CLI, it's a

Re: Github Reviews vs Reviewboard

-1, like Menno I was initially quite hopeful for the github reviews. My main concerns are around easily having a list to pull from, and being able to see status, comments on a single dashboard. Tim On 14/10/16 11:44, Menno Smits wrote: We've been trialling Github Reviews for some time now

Re: Big memory usage improvements

I have a strong feeling that we are still "leaking". Was talking with Christian this morning and he has some plans for introspection to isolate the issues. Tim On 13/10/16 10:36, Katherine Cox-Buday wrote: Menno Smits writes: Christian (babbageclunk) has been

Re: Big memory usage improvements

This is awesome. Tim On 13/10/16 09:39, Menno Smits wrote: Christian (babbageclunk) has been busy fixing various memory leaks in the Juju controllers and has made some significant improvements. Chris (veebers) has been tracking resource usage for a long running test which adds and removes a

Re: List plugins installed?

If we do that, then we can make the plug-in also install a metadata file that explains help and usage, so you don't call the script to do that. It makes it easy to list plug-ins, because you are searching a known location, and not the entire path. Only show plug-ins that have the appropriate

Timeout added to kill-controller

Hi all, NOTE: we do very much consider it a bug if the models don't die properly. I have just landed a fix for a kill-controller issue where it would just sit there for a long time with nothing apparent happening. Now kill-controller has a default timeout of 5 minutes. If there is no change

Re: Reviews on Github

I'm +1 if we can remove the extra tools and we don't get email per comment. On 15/09/16 08:03, Nate Finch wrote: In case you missed it, Github rolled out a new review process. It basically works just like reviewboard does, where you start a review, batch up comments, then post the review as a

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

OK, I think I've got it now. On 16/08/16 15:19, Ian Booth wrote: 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

RFC: time to remove the "smart" output formatter?

Hi folks, While perusing the codebase, I was reminded of our "smart" output formatter. It is the yaml but not quite yaml one. I propose we remove it, and default commands that were defaulting to that to use yaml instead. Thoughts? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com

RFC: proposed changes to debug-log API call

Hi folks, This is regarding the streaming /api/:model-uuid/log api server endpoint. Currently this method sends an initial possible error, then just turns on a tap of bytes of preformatted log messages. What I propose is to change the streaming protocol from just text to a stream of

Re: BDX <-> Juju

This sounds AMAZING!!! Great to hear Juju making a real difference. Thanks for sharing. Tim On 02/08/16 16:38, James Beedy wrote: Team, As some of you may know, I have taken on a new position as DevOps Engineer for a creative company -> CreativeDrive . CreativeDrive

Re: Schema for Juju RPC messages

While at the London sprint I was toying with the idea of adding the ability of the rpc package to do some rudimentary initial validation. We could get a good part of the way with relatively little effort IMO. Using the reflect package, we can interrogate the public attributes of the structure

Reminder: Leaving code better than you find it.

Hi all, I'd like to reiterate a key tenet [1] for the core team, and that is "leave the code better than you found it" Often we get too focused on the one thing we are trying to land, and disregard other small fixes or changes that could be made to make the code better. I'm not saying

Proposed addition to code review guidelines

Hi folks, With model migration entering the world as a first class citizen, we need to ensure that all fields and documents added to state have appropriate migrations done for them. In particular when adding a field it is likely that the state/migrations_internal_test.go will have a failing

model-migration feature branch has been merged into master

Hi folks, The model-migration branch has now been fully merged back into master. I have deleted the model-migration branch in the github.com/juju/juju repo. All future model migration merges are to land in master. That is all. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify

Re: RFC: remove juju publish?

y charm push. On 15 July 2016 at 04:32, Tim Penhey <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>> wrote: > Does 'juju publish' still serve a purpose in Juju 2.0? > > Should we just remove it? > > Tim > > --

RFC: remove juju publish?

Does 'juju publish' still serve a purpose in Juju 2.0? Should we just remove it? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju API breaks landed in master, soon to be released as beta 11

Hi folks, Continuing the rationalization of the API wire protocol there are more breaks to the API. With beta 10, we thought we fixed all the structures that were sent over the API to be consistently lowercase with dash separated words. However it was brought to our attention that there

fslock is dead, long live mutex

Hi folks, We have finally managed to exorcise the fslock from the codebase. Both 1.25 and master no longer refer to it at all. We need to remove it from the juju/utils package to make sure that people don't accidentally try and use it again. There is a new replacement, the juju/mutex

Breaking API change landing for 2.0-beta10

Hi folks, This impacts all people calling the Juju API directly. If you use the juju client, you *should* be fine. Taking advantage of our time in "beta", we are adding consistency to the wire-protocol used by the juju client to talk to the juju apiserver. In general this means that all

Re: Juju 2.0-beta9 ETA

Hi folks, Due to a change I landed without fully thinking through the implications, the reverting of said change has pushed us out a day. I was trying to add consistency to the wire-protocol that Juju uses by changing the serialisation names. Thinking that we were still in the "we don't

Re: Juju 2.0-beta9 ETA

On 12/06/16 21:00, Mark Shuttleworth wrote: From an upgrade point of view, I would focus on the migration capability, because that provides the cleanest semantics. If we have everything we need there and upgrades happen to work from b9 onwards, then that's great, but please communicate that I

Re: Fixing "juju help commands"

On 25/05/16 00:12, Marco Ceppi wrote: Even if you don't expect people to run them, hidding them seems awkward. Better to simply educate with good help output about what the command does and when/why use the command. Was thinking, perhaps it would be better to have a feature flag to use the

Re: Fixing "juju help commands"

Anastasia On 24/05/16 14:19, Tim Penhey wrote: Hi folks, More from the "let's fix the output" school of thought. One thing that has bugged me about 'juju help commands' was the repeated mentions of "alias for ". I propose that we don't show aliases by default, and allow

Fixing "juju help commands"

Hi folks, More from the "let's fix the output" school of thought. One thing that has bugged me about 'juju help commands' was the repeated mentions of "alias for ". I propose that we don't show aliases by default, and allow the user to task for them. Also, the supercommand describe

Quick win - juju check

Hi folks, We talked quite a bit in Vancouver about quick wins. Things we could get into Juju that are simple to write that add quick value. There was also talk about "juju check". The idea of this command is to surface things that should really be looked at. I was thinking that we could

Re: adding unit tests that take a long time

My 2c just so people know where I stand. I'm not in favour of skipping any tests by default. If people want to add flags so they can run subsets of tests, all credit to them, but I feel that it is just test noise. Making it too easy to skip long "unit" tests makes the problem too easy to ignore

Re: auto-upgrading models

On 26/04/16 17:44, John Meinel wrote: > How do we get the tools on the new controller? Since we did a fresh > bootstrap it won't have the old tools cached. Is part of the pre-flight > migration checks ensuring that the new controller can get the right > version of tools? How does it work if

Re: auto-upgrading models

On 26/04/16 14:06, Rick Harding wrote: > The key thing is that soon our path on upgrading models is via model > migration. We should keep that in mind as we think of how best to lead > the user to 'just do the right thing' Yes and No. A hosted model will never be allowed to upgrade beyond the

Short lived fork of master

Hi folks, Since master is blocked while we get the release organised, and we don't want to have a bunch of branches backed up, we created a branch on github.com/juju/juju called "next". Please target reviewed work to this and land. When master is unblocked I expect that we'll just merge this

Re: New juju in ubuntu

We could probably set an environment variable for the plugin called JUJU_BIN that is the juju that invoked it. Wouldn't be too hard. Tim On 07/04/16 17:25, Stuart Bishop wrote: > On 7 April 2016 at 03:55, Marco Ceppi wrote: >> >> On Wed, Apr 6, 2016 at 10:07 AM

Re: Unable to kill-controller

On 06/04/16 23:13, Nick Veitch wrote: > Sure, I am just concerned about a proliferation of commands to do the > same (ultimately) task > > destroy-controller The most correct way to take down a controller. > kill-controller The OMG it is broken, please do as much as you can and I know I'm

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

Re: Go 1.6 is now in trusty-proposed

Awesome news Michael. Thank you for all your work on this. Tim On 24/03/16 19:03, 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,

model migration now behind a feature flag

Hi folks, Since the 'juju migrate' command does not currently finish, we have put it behind a feature flag. Don't bother trying it yet, it doesn't work. We'll let you know when it is functional, and for what models it will work and under what conditions. There will be many caveats initially.

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

we have a capability to bootstrap the controller agent with a > specified > admin-user but have not hooked it up yet? > > On 04/03/16 08:11, Tim Penhey wrote: >> Ah... it used to be there :-) At least it is on my feature branch, but I >> don't think I have merged the most recent

Re: admin is dead, long live $USER

ake it configurable on bootstrap as an > option. > > +1 overall > > > On Thu, Mar 3, 2016, 4:07 PM Tim Penhey <tim.pen...@canonical.com > <mailto:tim.pen...@canonical.com>> wrote: > > Hi folks, > > I was thinking that with the upcoming big changes wi

admin is dead, long live $USER

Hi folks, I was thinking that with the upcoming big changes with 2.0, we should tackle a long held issue where we have the initial user called "admin". There was a request some time back that we should use the current user's name. The reason it wasn't implemented at that time was due to logging

Re: Dependency engine in the machine agent

Thanks Menno. That was very helpful. Apart from state connections, or api connections, what sort of resources are shared between workers? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

model-migration: the what, why, and progress

Hi folks, I'm writing this to communicate what we are doing, why, and how its going. Something I hope will prompt others to do the same. I'm also keeping this on the internal juju list because I will be mentioning JAAS. What and why: Model migration is a key component of JAAS and allows us to

New feature branch MADE-workers

Hi all, Since we are holding back the machine-dep-engine feature branch from master until the first 2.0 alpha, we needed a place to merge in the worker changes without impacting the blessedness of the machine-dep-engine branch. This feature branch should just hold the related manifold worker

Be very careful in assumptions in tests

Hi folks, I came across an interesting bug yesterday and during investigation found that there was a very comprehensive test that covered the situation. The problem is that the asserts were not actually running. The asserts were inside a loop where the expectation was that the loop would run

Re: Reviews for merges _from_ master to feature branches

On 01/12/15 13:56, Ian Booth wrote: > > > On 01/12/15 10:17, David Cheney wrote: >> Hello, >> >> Why are reviewers being created for merges from master to feature >> branches ? What purpose does this serve ? >> > > They appear because you create a github PR which triggers a reviewboard review >

utils/fslock needs to DIAF

Hi folks, The fslock was a mistake that I added to the codebase some time back. It provided an overly simplistic solution to a more complex problem. Really the filesystem shouldn't be used as a locking mechanism. Most of the code that exists for the fslock now is working around its

Re: Upgrading minimum Go version?

On 27/11/15 08:43, Michael Hudson-Doyle wrote: > On 27 November 2015 at 02:24, Martin Packman > wrote: >> On 26/11/2015, Andrew Wilkins wrote: >>> Hi (mostly Curtis), >>> >>> Is there a plan to bump the minimum Go version? Some of our

Re: lxd provider in master

On 24/11/15 04:53, Eric Snow wrote: > On Sun, Nov 22, 2015 at 8:50 PM, Tim Penhey <tim.pen...@canonical.com> wrote: >> Hi all, >> >> I noticed that the lxd provider was now in master and attempted to use >> it to help debug an HA problem. >> >> In

Re: lxd provider in master

On 24/11/15 12:47, Tim Penhey wrote: > On 24/11/15 04:53, Eric Snow wrote: >> On Sun, Nov 22, 2015 at 8:50 PM, Tim Penhey <tim.pen...@canonical.com> wrote: >>> Hi all, >>> >>> I noticed that the lxd provider was now in master and attempted

Re: lxd provider in master

It is valid YAML, last one wins. On 24/11/15 15:51, Nate Finch wrote: > I guess we don't error out when we see duplicate environment names? > Shouldn't we? > > On Mon, Nov 23, 2015 at 6:47 PM Tim Penhey <tim.pen...@canonical.com > <mailto:tim.pen...@

lxd provider in master

Hi all, I noticed that the lxd provider was now in master and attempted to use it to help debug an HA problem. In environments.yaml file I added a very simple clause: lxd: type: lxd But when I try to bootstrap, I get the following: $ juju bootstrap --debug 2015-11-23 03:26:14 INFO

Re: lxd provider in master

On 23/11/15 16:59, Andrew Wilkins wrote: > On Mon, Nov 23, 2015 at 11:50 AM Tim Penhey <tim.pen...@canonical.com [snip] > There appears to be no feature flag for the lxd provider, so what am I > missing? > > > Have you added yourself to the lxd group? ("newgr

Musings around environments, cloud credentials, and the new Juju Controllers

Hi William and list, I have been alternating between thinking this should be a document or an initial email. In the end I have gone for email even though this is likely to be longish. Before I get started on multiple environments in Juju controllers, I'd like to double check on Juju's

Re: More on logging changes in Juju 1.26.0

On 10/11/15 17:30, Stuart Bishop wrote: > On 9 November 2015 at 11:34, Menno Smits wrote: > >> In a recent thread I highlighted the upcoming change in Juju's logging where >> logs from machine and unit agents will be streamed over Juju's API instead >> of via rsyslogd.

Re: echo $JUJU_ENV_VARS

On 05/11/15 07:23, Nick Veitch wrote: > Greetings. > > For a long time now, the docs have had a list of the environment > variables used by Juju. It is a single page that is rather useful to > everyone: > > https://jujucharms.com/docs/stable/reference-environment-variables > > It would be a lot

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

I can't help but draw parallels to the plugin system. There was considerable resistance to adding the ideas of plugins to Juju. It was added complexity that no one needed and could be done simply using existing executable scripts, like juju-foo. Tim On 28/10/15 07:33, Cory Johns wrote: > You

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

On 24/10/15 04:05, Aaron Bentley wrote: > bzr has a similar feature, but the problem with such a feature is that > it can break scripts that expect the normal behaviour. That's why bzr > provides a --no-aliases option, which all scripts calling bzr should use. > > The same applies to Juju. If

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

On 24/10/15 00:40, Rick Harding wrote: > > > On Fri, Oct 23, 2015 at 12:12 AM Tim Penhey <tim.pen...@canonical.com > <mailto:tim.pen...@canonical.com>> wrote: > > Hi folks, > > Firstly, the ability to specify default flags for commands: >

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

On 23/10/15 21:28, roger peppe wrote: > On 23 October 2015 at 05:12, Tim Penhey <tim.pen...@canonical.com> wrote: >> Hi folks, >> >> I scratched a personal itch yesterday and added the ability for users to >> specify their own aliases for juju commands. >> &g

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

ould you please provide a similar --no-aliases option for juju, so > that we can ensure people don't break our scripts by specifying > surprising defaults? > > Thanks, > > Aaron > > On 2015-10-23 12:12 AM, Tim Penhey wrote: >

  1   2   3   >