Re: naming repos on github

On 06/06/14 01:28, roger peppe wrote: Unfortunately that means that the import identifier isn't intuitive, but perhaps that's ok. On 5 June 2014 14:27, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 14:20, Nate Finch nate.fi...@canonical.com wrote: We're making a lot of standalone

Re: not rebasing after PR?

On 06/06/14 11:52, Andrew Wilkins wrote: On Fri, Jun 6, 2014 at 1:22 AM, Casey Marshall casey.marsh...@canonical.com mailto:casey.marsh...@canonical.com wrote: On 06/05/2014 10:22 AM, Nate Finch wrote: This mashes all your pre-PR commits into one, so hides some commit spam

Re: $ juju switch --format

I think where people are getting confused is the relationship between the various uses of the name environment. We have more a language problem. We currently use environment to mean several things: 1) a running environment that has many users 2) an entry in the environments.yaml file 3) the

python-django charm with subordinate app - help needed

Hi all, I'm looking at using the subordinate charm method for delivering the app payload to the python-django charm. From the pyton-django readme: When you add a relation between your charm and the python-django charm, you will be able to get those relation variables from the hook:

Re: $ juju switch --format

peppe rogpe...@gmail.com wrote: On 5 June 2014 23:16, Tim Penhey tim.pen...@canonical.com wrote: Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into OK, here is my proposal, which I hope addresses all the concerns

Actions document - suggested changes

Today as on call reviewer I was looking through some pull requests specific to actions, and it brought up many questions. On reading the spec[1] and looking at the state documents as they are in trunk now, I was quickly coming to the conclusion that the documents need to change. Right now we

Re: Proposal: making apt-get upgrade optional

With respect to the local provider, I had always intended there to be a command in the local provider plugin (which is currently empty) that updates the template image. Tim On 02/07/14 08:22, Marco Ceppi wrote: I actually don't see a problem with removing apt-get upgrade, but what apt-get

Re: Proposal: making apt-get upgrade optional

I do just want to make the point that we are not just an ubuntu only system any more, nor even linux only. I'd prefer if we kept away from terms like apt-get as it doesn't make sense for windows nor centos. While we could certainly treat those values differently on the other platforms, it

RFC: mongo _id fields in the multi-environment juju server world

Hi folks, Very shortly we are going to start on the work to be able to store multiple environments within a single mongo database. Most of our current entities are stored in the database with their name or id fields serialized to bson as the _id field. As far as I know (and I may be wrong), if

Re: move towards using gopkg.in

On 08/07/14 09:00, Ian Booth wrote: gopkg.in is a decent solution to this problem, I believe, and a good direction to head in general. After discussion with (and approval by) several juju-core members, we have pushed the new API to gopkg.in/juju/charm.v2 (the code now lives in the v2 branch

Re: move towards using gopkg.in

On 08/07/14 13:49, Gustavo Niemeyer wrote: go list -f '{{range .Deps}}{{printf %s\n .}}{{end}}' | grep gopkg.in | sort -u | sed 's/\.v[0-9]\+$/\.vN/' | uniq -c | sed '/ 1 /d' Yay pipes !?!? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Proposal: making apt-get upgrade optional

On 11/07/14 02:47, Nate Finch wrote: Late to the party, but +1 for OS-neutral names. Keep in mind, there's no separate update/upgrade steps on Windows. There's no list of software that exists that needs to get updated on Windows, as that is done automatically. Luckily, it sounds like we

Re: Devel is broken, we cannot release

On 15/07/14 15:48, Ian Booth wrote: * FAIL: managedstorage_test trusty ppc64 from 2014-06-30 which had a secondary bug that broke compilation. https://bugs.launchpad.net/juju-core/+bug/1336089 This bug brings up another issue. The code concerned has now been moved off to a juju sub

Re: Devel is broken, we cannot release

On 16/07/14 01:57, William Reade wrote: On Tue, Jul 15, 2014 at 2:51 PM, Wayne Witzel wayne.wit...@canonical.com mailto:wayne.wit...@canonical.com wrote: If we aren't stopping the line when our CI is in the red, then what is the point of even having CI at all? If we are not prepared

Reviewing - moving to review mentors, and guidelines

Hi all, Last night in the team meeting we discussed the review process. Initially because there have been a number of things sneaking through reviews where ideally we'd like to catch them earlier. In order to help the newer folks on the team learn how we review, it has been suggested that we

Please run the tests

Hi all, If you are hitting the magic merge it button on github because the project isn't yet landed with the bot, please make sure you run the tests before actually merging the code. The juju/testing package didn't actually have passing tests, because some tests were added that were missing a

Sprint Report: Identity Sprint - Dunedin

Hi folks, Last week the Onyx (Dave, Jesse, Menno, Tim) and Emerald (Casey, Matty, Domas) teams met along with William to start work on the full support of users within Juju. This work builds on many other pieces that work together to be the foundation of this work. The work focused around the

Re: Landing changes for juju subprojects

Thanks Martin. I'd really appreciate an email to the juju-dev list as each juju subproject is enabled. Can we get you to do that? Cheers, Tim On 29/07/14 23:39, Martin Packman wrote: I'm switching our various subprojects in the juju namespace on github over to having landings gated by

Re: getting rid of all-machines.log

On 06/08/14 16:11, Nate Finch wrote: all-machines.log seems both redundant and a ticking time bomb of disk space usage. Do we really need it? Can we drop it and maybe later schedule some time to use something like logstash that is both more featureful and is cross platform compatible (unlike

Re: Label: Ready For Review

On 12/08/14 10:30, Nate Finch wrote: Hmm, that's a good point. This whole only owners can label stuff is annoying. I wonder if we should just make everyone owners. Seriously... no. We need to find a different approach. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify

Re: First customer pain point pull request - default-hook

-BEGIN PGP MESSAGE- Charset: windows-1252 Version: GnuPG v1 hQIMA233D38ktbXXAQ//W+ymYmuIbjOlDOtOTwJ494ZP5dB0K4ITftBo8ESeZDjM m+av246NKJlXsH+iyFJNOUC3ouaNF/W/1NuBCJXa/IJNKX//TyMCVF3yh5m5R77h CWbcTwguameiDsA0pmcuf1ezZgtFA3SeSf9Tuhu5CkGbRVXkSunQOTwP7nAUcYsC

Re: First customer pain point pull request - default-hook

WTH happened there? /me tries to remember what he wrote. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: First customer pain point pull request - default-hook

-BEGIN PGP MESSAGE- Charset: windows-1252 Version: GnuPG v1 hQIMA233D38ktbXXAQ/+OxwEOmqX/SS+lyJGh7WBYOZge3P8G9+bdu0u8v/sGioD xbPcpRAp4D3GaCyaMS231JTdvWjMgegw9f6AnnaeLiEdcmFi3YBEzvnDCR5+Lfpb KNMZFUsL9CYtsBy+tWBFkowsFwiKy66UiOQDRGW6G6V+5v/L2v4TUoDN+LE74/h2

Re: First customer pain point pull request - default-hook

On 18/08/14 09:11, Tim Penhey wrote: WTH happened there? /me tries to remember what he wrote. Tim Some encryption settings have been changed somewhere. Again, what I was saying was that my concerns seem to be moot after reading the code. As long as the script can be told which hook

Landing bot restrictions

Hi all, I'm sure everyone is aware of the landing bot changes that have gone in from CI. While these are painful now, they are helping us improve our test passing percentages. There was a pressure release valve added, the JFDI flag, to override the restrictions. I've seen this flag used more

Mentored reviewers - ACTION needed by team leads

Hi folks The mentored reviewers spreadsheet [1] has seven people down as people who would like review mentors. I'd like the team leads now to make sure that the people on their teams have a mentor assigned. The purpose of the mentor is to review the review. The idea here is that the mentored

Re: First customer pain point pull request - default-hook

On 21/08/14 02:50, Nate Finch wrote: I would expect a lot of people will implement their charms as a single script (especially given the number of charms we've seen implemented that way even with minimal support for it). If the special hook file is called default-hook, it makes those

gccgo internal compiler errors

Hi folks, I spent some time this morning looking at https://bugs.launchpad.net/juju-core/+bug/1362636 A critical regression that was breaking CI on power. There is a bug in gccgo where we hit an internal compiler error when comparing an interface to a concrete type that implements the

Re: Logger prefixes for api/apiserver are changing

On 02/09/14 23:07, David Cheney wrote: Wow. I'm sorry I broke that, it didn't even occur to me. I wonder if there is a better way to handle this default case of the name of the logger follows the package path), ie var logger = loggo.Logger() // or something, it could be a new method,

Re: reviewboard

On 10/09/14 02:47, Eric Snow wrote: On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com wrote: On 09/09/14 04:32, Eric Snow wrote: To install rbt: sudo pip install --allow-unverified rbtools --allow-external rbtools rbtools Ah... no. Perhaps in a virtual env

Re: Juju Actions - Use Cases

On 10/09/14 06:59, John Weldon wrote: Hi; We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too.

Fixed reviewer schedule

Hi folks, Those of you who are reviewers should now have invites to your bi-weekly review time. This now occurs on the same day every two weeks. I have tried to have the mentors on the day after the mentees (or overlapping). Also tried to spread out the different timezones. It will never be

Re: State should not depend on the API server

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 based behind the interface segregation principle. Effectively this boils down to don't depend on things you don't

Re: psa pls don't use transactions for single doc unobserved atomic updates

There is one that I talked with Kapil about this morning. When a user connects over the client api, we record the last login time. Currently this uses a transaction, but doesn't need to. In fact using a transaction here takes an order of magnitude longer, and wakes up watchers when it doesn't

RFC: state entities, replace globalKey() with .Tag().String()

Hi folks, I have been going through much of the code in the state package looking at the work to migrate all the collection keys to handle multiple environments. In the long and distant past (earlier this year), the Tag() method returned a string. There is a second tag like thing in the state

Re: RFC: state entities, replace globalKey() with .Tag().String()

On 24/09/14 18:02, Dimiter Naydenov wrote: On 24.09.2014 06:53, Tim Penhey wrote: Hi folks, I have been going through much of the code in the state package looking at the work to migrate all the collection keys to handle multiple environments. In the long and distant past (earlier

Re: ACTION: if you have admin hardcoded in scripts, this is a warning that things will change soon(ish)

On 26/09/14 20:39, Bjorn Tillenius wrote: On Fri, Sep 26, 2014 at 04:57:17PM +1200, Tim Penhey wrote: Hi folks, All environments that exist so far have had an admin user being the main (and only) user that was created in the environment, and it was used for all client connections. Code has

Re: ACTION: if you have admin hardcoded in scripts, this is a warning that things will change soon(ish)

-info or something like that, which essentially gives you the structured .jenv information that you would use (cert information, username, password, IP addresses, etc) John =:- On Mon, Sep 29, 2014 at 12:54 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen

Re: ACTION: if you have admin hardcoded in scripts, this is a warning that things will change soon(ish)

On 29/09/14 09:54, Tim Penhey wrote: On 26/09/14 20:39, Bjorn Tillenius wrote: On Fri, Sep 26, 2014 at 04:57:17PM +1200, Tim Penhey wrote: Hi folks, All environments that exist so far have had an admin user being the main (and only) user that was created in the environment, and it was used

debug-log broken for local provider again

Hi folks, while testing today I noticed that debug-log is broken for the local provider because the all-machines.log file isn't being written out. Not done any more follow up yet. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Juju devel 1.21-alpha2 is available

On 24/10/14 13:37, Curtis Hovey-Canonical wrote: A new development release of Juju, juju-core 1.21-alpha2, is now available. This release replaces 1.21-alpha1. Multiple-user Support Juju now supports multiple people connecting to the environment with their own identity and credentials.

Re: how to update dependencies.tsv

On 29/10/14 21:05, Dimiter Naydenov wrote: On 29.10.2014 09:46, David Cheney wrote: Does your $GOPATH include more than one entry ? No, it only has a single path. The make target should probably just expect godeps to be in your $PATH. That's a good point. I did some experiments adding:

User Management part 1 all there for 1.21

Hi All, The final piece of User Management part 1 landed in master for the 1.21 release. This means that Juju is now user aware. You are able to create additional users, change your password, and list the users that are in the Juju server. More details about this are in the 1.21 release notes

Menno's reviewer graduation

Hey there fellow Juju developers, I'd like to announce Menno's reviewer graduation. I have been very happy with the quality and understanding shown in Menno's reviews. Congratulations. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: how to update dependencies.tsv

this way. On Oct 30, 2014 4:22 AM, roger peppe roger.pe...@canonical.com wrote: On 29 October 2014 21:03, Tim Penhey tim.pen...@canonical.com wrote: On 30/10/14 01:11, roger peppe wrote: A better solution here, which I've been meaning to do for a while, would be to change godeps so that it can

Splitting cloud credentials out of config.Config

Hi All, This is a bit of a brain dump and thoughts around this. Some of this may be a bit rambly... The cloud credentials are not needed by any worker other than the provisioner and firewaller (I think). If they are, the worker should be one that is only run on the main state server machines.

Re: Automatic environment filtering for DB queries

Wrapping the collection objects that are returned from the `getCollection` method shouldn't be too hard and it could wrap the Find and FindId calls. It would have fixed this missed call below: // aliveUnitsCount returns the number a alive units for the service. func aliveUnitsCount(service

New checker jc.IsNil

'ello 'ackers, This is something that I have been meaning to add for quite some time. We have been recording stack traces with the juju/errors library, but until now, they have been of limited use. One of the key places I have wanted to see the stack trace for a while is when running tests, and

Re: Too space, or not two space

I learned to type on a typewriter (both mechanical and electric) back in the 1980s, and it was two spaces then. Personally I don't care and I'll go with whatever is suggested. Tim On 19/11/14 13:24, Nick Veitch wrote: It should be a single space, unless the comments are being written on a

Re: Fwd: New checker jc.IsNil

On 19/11/14 01:16, roger peppe wrote: On 18 November 2014 04:22, Tim Penhey tim.pen...@canonical.com wrote: 'ello 'ackers, This is something that I have been meaning to add for quite some time. We have been recording stack traces with the juju/errors library, but until now, they have been

Re: Fwd: New checker jc.IsNil

On 24/11/14 14:02, Tim Penhey wrote: On 19/11/14 01:16, roger peppe wrote: On 18 November 2014 04:22, Tim Penhey tim.pen...@canonical.com wrote: 'ello 'ackers, This is something that I have been meaning to add for quite some time. We have been recording stack traces with the juju/errors

Re: Fwd: New checker jc.IsNil

On 24/11/14 21:05, roger peppe wrote: On 24 November 2014 at 02:39, Tim Penhey tim.pen...@canonical.com wrote: On 24/11/14 14:02, Tim Penhey wrote: On 19/11/14 01:16, roger peppe wrote: On 18 November 2014 04:22, Tim Penhey tim.pen...@canonical.com wrote: 'ello 'ackers, This is something

Proposal: feature flag implementation for Juju

Hi all, There are often times when we want to hook up features for testing that we don't want exposed to the general user community. In the past we have hooked things up in master, then when the release branch is made, we have had to go and change things there. This is a terrible way to do it.

Re: Proposal: feature flag implementation for Juju

On 26/11/14 14:18, Andrew Wilkins wrote: On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Hi all, There are often times when we want to hook up features for testing that we don't want exposed to the general user

Re: Proposal: feature flag implementation for Juju

/11/14 17:10, John Meinel wrote: Given the constraints you just listed (globally set in the environment, etc), why not just make it environment config, rather than yet-another-way to set env config? John =:- On Wed, Nov 26, 2014 at 5:22 AM, Tim Penhey tim.pen...@canonical.com

ISSUE with juju 1.21-beta3

During our team's testing with many upgrade scenarios we have found a problem with tools and the jujuc commands on upgrades from 1.20 to 1.21-beta3. We are investigating. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: ISSUE with juju 1.21-beta3

On 27/11/14 10:07, Tim Penhey wrote: During our team's testing with many upgrade scenarios we have found a problem with tools and the jujuc commands on upgrades from 1.20 to 1.21-beta3. We are investigating. Definitely a problem. Critical bug created: https://bugs.launchpad.net/juju-core

Re: Proposal: feature flag implementation for Juju

. I think the env variable implementation is ok too - this keeps everything very loosely coupled and avoids polluting a juju environment with an extra config attribute. On 26/11/14 08:47, Tim Penhey wrote: Hi all, There are often times when

Dear reviewers,

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 responsibility to respond to the developer

Re: Things which may be of interest in Go v1.4

I also couldn't help but read through the release notes of Go 1.4 last night. I agree with Gustavo that we should avoid code generation unless absolutely necessary. I have a strong feeling that it won't be necessary given how far we have come without it. I did like the internal packages,

Re: local provider

On 13/12/14 08:54, Curtis Hovey-Canonical wrote: On Fri, Dec 12, 2014 at 1:57 PM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: first as you say its people first experience with juju and the way its deployment usage fits very well with some folks production needs ( ie. i have a

NETWORKER ALERT: network worker causing problems in 1.21

Hi folks, There is something I'd like you to talk about while you are together in Cape Town. The new networker worker was added in 1.21, and is causing many problems in the wild. The lxcbr0 IP address is erroneously being chosen as the best address for a machine. The worker enumerates all the

A cautionary tale of names

Hi folks, I hit an issue that surprised me at the time, but became obvious to me when I thought about our implementation. I managed to destroy my production environment by accident, and this is always a problem. What I was trying to do was to bring up my new production environment in parallel

Re: A cautionary tale of names

On 12/01/15 22:23, roger peppe wrote: On 12 January 2015 at 03:17, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. +1. The environment name should be purely

Re: A cautionary tale of names

On 13/01/15 04:55, Eric Snow wrote: On Sun, Jan 11, 2015 at 8:17 PM, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. Tim, I'm glad you brought this up. We

Re: Unit test failure in juju/errors

Actually it is testing the DeferredAnnotatef method, so yes it does need to use the defer. Strange that the line number is changing though. Tim On 07/02/15 07:58, roger peppe wrote: Interesting. It seems that the line reported for a defer has changed in 1.4. That said, I'm not really sure

Re: NETWORKER ALERT: network worker causing problems in 1.21

On 05/02/15 20:56, Dimiter Naydenov wrote: Hey Tim, I'm sorry the networker is causing trouble for you guys. It was causing issues for us in MaaS and EC2 as well, there were several fixes to reduce the networker's impact and in fact it is now totally disabled on trunk. It will stay that way

Re: GCE provider, successful bootstrap and deploy

\o/ Well done team! On 08/01/15 11:17, Wayne Witzel wrote: Eric Snow and myself have recently been working on the GCE provider. As of today, we have officially bootstrapped and deployed and setup a Wordpress instance and related MySQL instance. We are still manually working around some

master upgrade problems

Hi folks, A branch I landed yesterday broke all the upgrade tests. This was a branch that added a new login version. Since 1.23 writes the environment UUID to the agent config, I had wrongly assumed that it would all be good. This has now been rectified with commit b56d0a30

Re: Please, no more types called State

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 of packages where state needs to be persisted,

Re: Proposal: move package replicaset to its own GitHub repo

Agreed. Makes a lot of sense to me. On 26/03/15 00:33, David Cheney wrote: Do it! On Wed, Mar 25, 2015 at 9:22 PM, Nate Finch nate.fi...@canonical.com wrote: +100, thanks for doing this, Andrew! On Wed, Mar 25, 2015 at 6:16 AM, roger peppe roger.pe...@canonical.com wrote: This seems

Re: serializing to json

On 01/04/15 08:22, Nate Finch wrote: FYI: Serializing a struct to json works without having to specify struct tags: type foo struct { Name string Age int } f := foo{ Bob, 40 } serializes (marshals) into { Name : Bob, Age : 40 } No struct tags needed. The

Re: Trivial bugs hurting progress

On 04/03/15 19:05, Andrew Wilkins wrote: The bugs were fixed in this branch: https://github.com/juju/juju/pull/1738 - invalid printf-style formatting will cause go vet to fail My bad. I had deleted the pre-push hook script some time ago when go vet failed continuously, and I hadn't reinstated

Re: bugs, fixes and targeting Juju versions

git cherry-pick does this as a git command. Tim On 05/05/15 13:03, Jesse Meek wrote: Hi All, tl;dr `git diff --no-prefix master diff.patch; patch -p0 diff.patch` is useful for landing bug fixes in different versions of juju. As a lot of us are currently bug hunting and needing to land

Juju Core Reviews and Reviewers

Hi All, Last year we initiated a process called the Mentored Reviewers where new team members entered the review process but a ship it from them was not considered enough to land code. The process was what I'd call a partial success. One key part of learning how to be a good Juju Core reviewer

REMINDER: run tests with -race before submitting for review

Hi All, As was mentioned in earlier emails, we are trying to get rid of the races in our code as identified by the Go race detector. What wasn't clear I guess is Why now? We have had races for ages. If we skip over the obvious points of because it is the right thing to do, and the weird

Re: I'm concerned

On 19/06/15 01:47, Aaron Bentley wrote: On 2015-06-18 12:12 AM, Tim Penhey wrote: The certupdater worker was making the mistake of trusting a watcher. It was blindly getting the addresses and updating the certificate. Is this relevant? https://bugs.launchpad.net/juju-core/+bug/1466514

Re: I'm concerned

package), do whatever cleanup is needed, then os.Exit, unhandle the signal and try to send SIGQUIT to ourselves, or just panic. On Wed, Jun 17, 2015 at 3:25 PM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Hey team

I'm concerned

Hey team, I am getting more and more concerned about the length of time that master has been cursed. It seems that sometime recently we have introduced serious instability in cmd/jujud/agent, and it is often getting wedged and killed by the test timeout. I have spent some time looking, but I

I'm very confused about this error: jc.DeepEquals

This morning I noticed a Curse on the jes-cli branch, which included this one on ppc64el: http://reports.vapour.ws/releases/2855/job/run-unit-tests-trusty-ppc64el/attempt/3487 Upon looking I saw this: storage_test.go:147: c.Assert(info, jc.DeepEquals, expect) ... obtained

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

I'm in agreement with Bogdan, Roger and William on this one. If your test suite is composed of other suites, and you override the default setup or teardown of either the suite or the test, you MUST call the respective methods of the embedded suites. Roger, if it is easy to write some code to

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

On 17/07/15 01:36, Nate Finch wrote: I agree that this is the correct thing to do. However, it is error prone and non-obvious. Why? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

ppc64le timeouts cursing things

Hi Curtis, I have been looking at some of the recent cursings from ppc64le, and the last two included timeouts for the worker/uniter tests. On my machine, amd64, i7, 16 gig ram, I get the following: $ time go test 2015-07-17 03:53:03 WARNING juju.worker.uniter upgrade123.go:26 no uniter state

New feature branch: model-migration

Just a heads up on a new feature branch. This is the target branch for the new model migration work. There is also a separate feature branch for machine-dep-engine which is the focus of moving the machine agent to use the dependency engine, which model migration will depend on. The machine

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

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

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

New feature branch - machine-dep-engine

Hi folks, Just a heads up, created a new feature branch that will be the target for the work to make the machine agent use the dependency engine for the workers. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: local juju users: bob vs bob@local

On 10/10/15 02:41, roger peppe wrote: > We've been working on adding external user support to juju > and a discussion arose from a throwaway comment on the > IRC channel: > > "The difference between Canonical() and Id() seems confusing to me" > > The comment referred to two names.UserTag methods

Cheryl graduating

Hi folks, I have been very happy with the quality of Cheryl's reviews and the time is right for her to be considered a fully graduated reviewer. Thanks for all the reviews Cheryl. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: workers using *state.State

On 09/09/15 12:36, Horacio Duran wrote: > There is lazy and there is also "I just based in that other worker" > which happens, I am the proud parent of statushistorypruner and a > rewrite is underway too, sorry. Don't get me wrong, lazy developers are generally good. We try to find the simplest

Re: workers using *state.State

On 09/09/15 11:22, Andrew Wilkins wrote: > On Wed, Sep 9, 2015 at 6:14 AM Ian Booth > wrote: > > Those workers below aren't the only ones. There's also minunits and > peergrouper > workers. > > No-one does these things on

Re: peergrouper tests badly need fixing

This will also be why the wily CI tests don't pass as wily has Go 1.5 Tim On 16/09/15 16:53, Tim Penhey wrote: > Hi all, > > Using Go 1.5 on trusty has the peergrouper tests failing very often. 1 > or 2 almost every time. > > Dave suggested trying "GOMAXPROCS=1" w

Re: Running upgrade steps for units

wrote: > > > On 16/09/15 12:06, Menno Smits wrote: >> On 16 September 2015 at 08:41, Tim Penhey <tim.pen...@canonical.com> wrote: >> >>> On 15/09/15 19:38, William Reade wrote: >>>> Having the machine agent run unit agent upgrade steps would

Running upgrade steps for units

Hi William and Menno, I've been investigating this bug: https://bugs.launchpad.net/juju-core/+bug/1494070 The upgrade steps were never planned to be executed for unit agents, only on machine agents, but there are two upgrade steps identified in this bug where they were clearly expecting

<    1   2   3   >