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

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

Re: Aggregate all bundle.yaml | API endpoint

On 14/07/18 17:23, Ilias Tsoumas wrote: > Hello Mark, > > For the sake of clarification, let's try to explain my thoughts. I want > to understand if I can use juju's bundles as directed (acyclic) graphs. > Is there the information about direction? If no, do you propose to use > the bundles as

Re: LXD on Manual incorrect resolv.conf

Am I right in assuming that you are bringing up bionic containers? On 27/06/18 10:09, Tom Barber wrote: > Ah right, apologies, the IP address is provided by the LXD default bridge. > > > On 26 June 2018 at 22:31:12, Tim Penhey (tim.pen...@canonical.com > <mailto:tim.pen...@can

Re: LXD on Manual incorrect resolv.conf

tion to the WWW, why doesn’t Juju, it > seems both reasonable and logical? I guess thats my expectation, > considering the containers need to apt-get etc. > > Juju is 2.3.7 > > Tom > > > On 26 June 2018 at 21:57:21, Tim Penhey (tim.pen...@canonical.com > <mailt

Re: LXD on Manual incorrect resolv.conf

Hi Tom, What is your expectation on how the containers are getting their IP addresses? Also, which version of Juju? Tim On 27/06/18 08:29, Tom Barber wrote: > Hi folks, > > I’m trying to do a manual cloud with LXD containers within it. > > When I manually launch and LXD container I get  > >

Re: EC2 availability zones and bundles

I don't believe this is possible with bundles at the moment. The only placement directives that is currently supported in bundles are: new lxd:new lxd: kvm:new kvm: I *think* that is it. Tim On 16/06/18 05:57, George Kraft wrote: > Hey folks, > > Is there a way to assign units or

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

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

Intro to Juju webinar in about 13 hours

Hi folks, I'm going to be presenting an Introduction to Juju on the BrightTALK platform tomorrow morning (my time). https://www.brighttalk.com/webcast/6793/298241 It is a high level introduction, nothing too technical, and ideal for someone that has no understanding of Juju wondering whether or

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

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

Re: juju 2.3.3 failing to bootstrap localhost

How did you login to the container? It sounds like you may be missing SSH logins? Tim On 22/02/18 14:32, fengxia wrote: > Verified by login to the container. I could `apt update`, `apt install > htop`. > > At juju bootstrap terminal, I picked up this error message: > > 01:27:52 DEBUG

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

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-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: Debug logs

What is the logging level for the model? The output from the hooks are logged at debug level. Tim On 26/11/17 13:25, Tom Barber wrote: > Maybe its just me, I dunno. > > Has the amount of detail in debug-logs decreased? > > I'm  not seeing failure causes for example: > > 2017-11-26 00:11:18

Re: How to open port with juju when no application is instlaled?

I think you might be able to use: juju run postgresql/0 'open-port 80' Tim On 24/11/17 06:54, Akshat Jiwan Sharma wrote: > Hi, > > I've used juju to deploy postgres on aws. On the same machine I've > installed an nginx server manually (i.e without juju) that listens on > ports 80 and 443. I

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

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: 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: LXD bootstrap inside KVM failed

Yep, that is pretty strange. Why was bind running? Tim On 03/08/17 07:45, fengxia wrote: > For anyone, the solution is rather strange: > > $ sudo service stop bind9 > > $ sudo lxd start > > Reference: https://github.com/lxc/lxd/issues/2046 > > > On 08/02/2017 03:33 PM, fengxia wrote: >> Hi

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: Upgrading juju2

On 13/06/17 04:25, Mario Splivalo wrote: > Hi, ladies and lads! > > I am verifying the juju upgrade procedure and I ran into some > ‘misunderstandings’ which I’m hoping could be clarified out here. > > I am running juju 2.0.0 and the plan is to upgrade it to the latest 2.1 > version, which is

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

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 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

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

Re: django charm broken or am I just doing it wrong?

04:15, John Meinel wrote: I believe Tim Penhey makes active use of the python-django charm, but it's possible he uses it in a different fashion. John =:-> On May 21, 2017 14:25, "Erik Lönroth" <erik.lonr...@gmail.com <mailto:erik.lonr...@gmail.com>> wrote: H

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

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: 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: 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: 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?

On Thu, Sep 29, 2016, 6:07 PM Tim Penhey <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>> wrote: 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 l

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: Increasing the size of VERSION in tabular status output

Yesterday we changed the limit to 15 from 7. Tim On 20/09/16 04:41, Rick Harding wrote: The primary trouble is that we really want to enforce a limit so that there's room for the arbitrary text at the end of the same line. I think we could try 10. I do think we need that hard cutoff. If you

Re: Feedback wanted: Changes to the Ubuntu Charm

Marco, This is awesome. I use the ubuntu charm all the time for testing, and seeing the workload version and workload status being set is pretty cool. I had hoped that seeing the "unknown" status would apply gentle pressure to get people to set a workload status. Winning!!! Tim On

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

Re: Deploying local code

Hi Alexander, Great to hear fellow kiwis interested. The dealing with artifacts is exactly the problem that resources were designed to fix. A charm defines the resources it needs and as the charm is deployed, it also has the resources fetched. Personally I've not used any charms yet that

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: 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

Re: Juju Secrets

On 25/07/16 06:32, James Beedy wrote: Proposed Solution: Juju Secrets To give Juju a combative edge on the privacy pinwheel of secrets distribution in the realm of bleeding edge devops tooling, behold my hypothetical proposed solution: |juju secrets|. Juju secrets could be used like so: |juju

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

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

  1   2   3   >