git tutorial

Here's a link to a nice git tutorial: https://www.atlassian.com/git/tutorial/ Another nice resource: http://git-scm.com/doc ...particularly the getting-started section in the book: http://git-scm.com/book/en/Getting-Started-Git-Basics -eric -- Juju-dev mailing list

Splitting out state/api into its own repo

(I've put a more structured proposal below, but here's some context.) Over the last couple weeks I've been spinning up on the juju code base, which is large enough to dissipate any hope of understanding it all quickly. wink Most of what I've focused on is relative to the juju tools and the remote

Re: Splitting out state/api into its own repo

On Fri, Jun 27, 2014 at 3:05 AM, William Reade william.re...@canonical.com wrote: I think one of the biggest problems is the naming: state/api is a hackish and minimal api client implementation, while state/apiserver is where the actual api is defined... except the params package, which for

Re: Splitting out state/api into its own repo

On Fri, Jun 27, 2014 at 5:36 AM, Nate Finch nate.fi...@canonical.com wrote: have the code somewhere easily accessible in some repo, preferably without needing to download the entire juju codebase. Good point. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or

Re: Splitting out state/api into its own repo

On Thu, Jun 26, 2014 at 11:04 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: Hey Eric, Some comments below, offering a slightly different perspective to be used as a data point in your quest. That was totally helpful. And with the further discussion (thanks everyone!), I'm still hopeful

Re: Splitting out state/api into its own repo

Thanks to all the responses thus far. While the discussion has been insightful, I'm also hopeful that it will still be fruitful. :) Understandably the responses have been focused on the main point of my original post, splitting out the API client into its own repo. However, there were a few

Re: full functional tests for API methods

On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow eric.s...@canonical.com wrote: Yep. For my case (backup/restore) we have a good enough solution already. Incidentally, do we have documentation somewhere on CI tests (e.g. backup/restore)? Specifically, where are they, how do they work, and how do you

Re: full functional tests for API methods

there. John =:- On Tue, Jul 22, 2014 at 7:10 PM, Eric Snow eric.s...@canonical.com wrote: On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow eric.s...@canonical.com wrote: Yep. For my case (backup/restore) we have a good enough solution already. Incidentally, do we have documentation somewhere on CI

backup API in 1.20

The API server side of backup made it into 1.20 (the client-side and CLI did not). However, the API is exposed via HTTP POST rather than through websockets RPC. We are correcting this right now. The question is, are there any objections to removing backup from the state API in 1.20 (or, less

Re: backup API in 1.20

On Wed, Jul 30, 2014 at 12:25 AM, John Meinel j...@arbash-meinel.com wrote: So as discussed, I think we still want to support a HTTP GET based API for actually downloading the content to the client. And the CLI can do steps like: RPC to a request to create a backup (either this is synchronous

Re: Logger prefixes for api/apiserver are changing

On Tue, Sep 2, 2014 at 5:07 AM, David Cheney david.che...@canonical.com wrote: 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, logger.Default(), or

Re: State should not depend on the API server

On Mon, Sep 1, 2014 at 12:03 AM, John Meinel j...@arbash-meinel.com wrote: FWIW I'd favor 3 layers, though it does mean you have to do copying between structs that would likely otherwise be almost identical. A State layer for saving in the DB, an API layer for communication, and a Model layer

Re: my first charm

On Wed, Sep 3, 2014 at 11:37 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow eric.s...@canonical.com wrote: Here's a write-up on my experience writing a charm for the first time. Thanks for writing this up. Blame Nate! He had the sense to ask

Re: reviewboard

been done yet. I'll roll those out when I can. Also note that for some of the config settings I'm using values other than what I've listed in the spreadsheet. Each of those will be changed to the correct value before we switch over. -eric On Fri, Sep 5, 2014 at 7:09 PM, Eric Snow eric.s

Re: reviewboard

On Mon, Sep 8, 2014 at 4:37 AM, Ian Booth ian.bo...@canonical.com wrote: Hi Eric Fantastic, thank you. Quick question - can we set up a Juju team group and have that group automatically be assigned as a reviewer for newly created review requests? I tried to create a new request using the

Re: reviewboard

On Mon, Sep 8, 2014 at 10:21 AM, Eric Snow eric.s...@canonical.com wrote: In the meantime I recommend using rbt (as echoed by Adam). I know As a bonus, rbt allows you to create review requests relative to a parent revision (ergo branch), so you can chain patches. Wayne just pointed out to me

Re: reviewboard

On Mon, Sep 8, 2014 at 10:21 AM, Eric Snow eric.s...@canonical.com wrote: In the meantime I recommend using rbt (as echoed by Adam). I know As a bonus, rbt allows you to create review requests relative to a parent revision (ergo branch), so you can chain patches. To install rbt: sudo pip

Re: reviewboard

On Mon, Sep 8, 2014 at 10:23 AM, Eric Snow eric.s...@canonical.com wrote: Wayne just pointed out to me that rbt + our OAuth-based users aren't a great mix. This is because the auto-registered reviewboard users are not set up with passwords. I'll figure out a solution for us. The OAuth stuff

Re: Review Request 15: juju-run: allow commands to specifiy a relation context

--- This is an automatically generated e-mail. To reply, visit: http://reviews.vapour.ws/r/15/#review4 --- A general comment. - ericsnowcurrently On None, wwitzel3 wrote:

Re: reviewboard

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. Is it the sudo or the flags to which you object

Re: ReviewBoard and our workflow

On Wed, Sep 10, 2014 at 3:34 PM, Menno Smits menno.sm...@canonical.com wrote: Thanks Eric! I've used Reviewboard at a previous job and I'm fairly sure that it aligns better with the way the Juju Core team likes to work than Github's review features. Two questions: 1. Is this what we're

Re: ReviewBoard and our workflow

On Thu, Sep 11, 2014 at 1:34 AM, Frank Mueller frank.muel...@canonical.com wrote: For switching to a new tool and a new workflow I would like to not simply discuss it in a somehow undefined way together with subjunctive terms (Everybody should now ...) here via mail. Please lets fix the

repos in reviewboard

Which of the repositories listed at https://github.com/juju should be set up in reviewboard? I'm pretty sure on most of them, but a more authoritative list would help me out. In the meantime I'm adding the ones I'm sure on. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify

Re: ReviewBoard is now the official review tool for juju

On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits menno.sm...@canonical.com wrote: Eric, Thanks for setting this up. Firstly, in your email you mention rbt pull several times. I think you mean rbt post right? I don't see a pull command documented anywhere. Correct. I meant rbt post. :) I've

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow eric.s...@canonical.com wrote: Yeah, those steps are a lot, though keep in mind that effectively it's only 2 steps more than before if you use the -p flag to rbt post and were already keeping your local master up to date. Just to be clear, here

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our reviews are now disconnected from what will actually be landed into trunk. In

Re: ReviewBoard is now the official review tool for juju

On Mon, Sep 15, 2014 at 12:54 PM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: - From my meager experience with writing git plugins (any executable in $PATH with git- prefix), what are you describing can be easily achieved. If you write a git plugin, named e.g. git-rbpropose, using

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 7:55 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: +1, In addition you can always check https://github.com/juju/juju/pulls to see what's in the queue. For sub-repositories it's the same, like https://github.com/juju/names/pulls. While I agree it's not all

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 8:34 AM, Eric Snow eric.s...@canonical.com wrote: I agree that reviewboard as we currently have it now adds extra work to our workflow. Not only does this impact the juju team, but it does add a stumbling block to more community involvement. However, my firm belief

Re: Is ReviewBoard a good thing?

On Fri, Sep 19, 2014 at 6:11 AM, Gabriel Samfira gsamf...@cloudbasesolutions.com wrote: Just a suggestion: A git plugin similar to what Gerrit has would simplify things. For example, Gerrit has a nice little plugin called Review. Simply doing: git review In your current branch would push

Re: Is ReviewBoard a good thing?

On Thu, Sep 18, 2014 at 6:32 PM, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. It will be worth being extra clear on ReviewBoard's

The Pros and Cons of ReviewBoard.

Given that I've in some part driven the switch to ReviewBoard, I want to make sure we are all on the same page and any decision on its future can be made objectively. This is an outgrowth of the current discussion on whether or not we should ditch reviewboard. Let's look at the pros and cons of

Re: The Pros and Cons of ReviewBoard.

On Fri, Sep 19, 2014 at 9:37 AM, Eric Snow eric.s...@canonical.com wrote: Given that I've in some part driven the switch to ReviewBoard, I want to make sure we are all on the same page and any decision on its future can be made objectively. This is an outgrowth of the current discussion

Re: Is ReviewBoard a good thing?

On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek jesse.m...@canonical.com wrote: On 20/09/14 02:34, Eric Snow wrote: I was not seriously suggesting we return to lp. Using ReviewBoard reintroduces what we gave up with lp: both the good (tooling that addresses pain points) and the bad (not a well

reviewboard-github integration

With the switch to Reviewboard we introduced extra steps to our workflow (mostly involving rbt). This in turn made things more difficult for new/existing contributors. I've been able to take some time in the last couple weeks to improve the situation by adding some integration between github and

Re: reviewboard-github integration

Also, I did this as a reviewboard extension. All the code is online (BSD license): https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension. I haven't charmed it up, but it should be pretty easy to adapt the charm I wrote for rb_oauth. -eric On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow

Re: reviewboard-github integration

And of course if you see any problems please let me know. :) -eric On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow eric.s...@canonical.com wrote: With the switch to Reviewboard we introduced extra steps to our workflow (mostly involving rbt). This in turn made things more difficult for new

Re: reviewboard-github integration

to the RB issue page and manually uploaded the generated diff and published it. So most definitely the hook generating RB issues have to upload the diff as well :) It's coming together, keep up the good work! Cheers, Dimiter On 20.10.2014 16:53, Eric Snow wrote: On Mon, Oct 20, 2014 at 6

Re: reviewboard-github integration

This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. -eric On Mon, Oct 20, 2014 at 7:34 PM, Eric Snow eric.s...@canonical.com wrote: Yeah, this is the same issue that Ian brought up. I'm looking into it. Sorry for the pain. -eric

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 11:40 AM, Michael Foord michael.fo...@canonical.com wrote: On 20/10/14 22:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. I still have the issue I'm afraid. No reviewer set, no diff

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 3:40 AM, Michael Foord michael.fo...@canonical.com wrote: On 20/10/14 22:38, Eric Snow wrote: This should be resolved now. I've verified it works for me. If it still impacts anyone, just let me know. I still have the issue I'm afraid. No reviewer set, no diff

Re: reviewboard-github integration

On Tue, Oct 21, 2014 at 10:12 AM, Eric Snow eric.s...@canonical.com wrote: For now I've hard-coded adding juju-team. If anyone still has trouble with this please let me know. The issue with not finding files in the repo should be fixed now. This means that auto-generated review requests should

Re: reviewboard - most recent diff by default?

On Mon, Oct 27, 2014 at 9:05 PM, Jesse Meek jesse.m...@canonical.com wrote: Is possible and preferable to show the most recent diff by default? If you mean instead of showing the reviews page by default, ReviewBoard doesn't support that out of the box. Certainly we could customize RB to do so,

Re: per-database mongodump

with fresh eyes, option 2 seems much more feasible and palatable. My only concern is that it relies on what amount to implementation details of mongodump (and mongorestore). -eric John =:- On Tue, Oct 28, 2014 at 3:07 AM, Eric Snow eric.s...@canonical.com wrote: For backup we currently

Re: Menno's reviewer graduation

On Wed, Oct 29, 2014 at 7:13 PM, Tim Penhey tim.pen...@canonical.com wrote: 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. Good job! -eric --

deprecating the juju-backup (and juju-restore) CLI plugin

The new juju backups create can be used instead of juju backup (a CLI plugin). So you would think we could deprecate and later remove the old plugin. Unfortunately, juju backups create won't work with 1.20 or earlier API servers. So it's not quite as simple as I'd hoped as long as newer clients

Re: deprecating the juju-backup (and juju-restore) CLI plugin

On Fri, Oct 31, 2014 at 8:35 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Thu, Oct 30, 2014 at 2:10 PM, Eric Snow eric.s...@canonical.com wrote: What would be the best approach for deprecating the old backup plugin? I was going to simply gut it (it's a bash script) and stick

Re: review board not syncing?

On Tue, Nov 11, 2014 at 12:28 PM, Jesse Meek jesse.m...@canonical.com wrote: The latest three reviews on GitHub (#1103,#1102,#1101) I cannot see in Review Board. Do we have a loose wire? For 1101 at least, it's in reviewboard (402). I'll look into it. I'm pretty sure the github integration

Re: Please stop adding dependencies to the state package

On Thu, Nov 13, 2014 at 4:05 PM, David Cheney david.che...@canonical.com wrote: Hello, Please stop adding dependencies to the state package. The dependency tree for state must go mgo - state - things that depend on state At the moment state depends on things like backups, multiwatchers,

reviewboard update

FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour limit instead of 60) 3. pull request bodies now get updated with a link to the new review

Re: reviewboard update

On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: I can confirm RB diffs for backports to 1.21 get generated correctly now, and the PR description is updated to include a link to the RB diff. Thanks for reporting on this. There's one issue however -- the

Re: Too space, or not two space

On Tue, Nov 18, 2014 at 5:13 PM, David Cheney david.che...@canonical.com wrote: To quote Butterick's http://practicaltypography.com/one-space-between-sentences.html And to quote that same page: If you have to use a typewriter-style font, you can use two spaces after sentences. Otherwise,

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

Thanks for writing this up, Katherine! On Thu, Dec 11, 2014 at 9:21 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: go generate https://golang.org/doc/go1.4#gogenerate This is *very* powerful and could reduce the number of copy/paste snippets, or unsafe reflection code we

Re: Feedback on a base fake type in the testing repo

On Wed, Feb 11, 2015 at 6:43 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Looks okay in principal, though I'm not sure how much benefit it would add to the existing, tailored fakes in the codebase. It seems a little bit weird that error results are encapsulated, but not non-error

Re: A cautionary tale of names

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 have followed the lead of the EC2

Re: Testing on windows

. From: Eric Snow [eric.s...@canonical.com] Sent: Thursday, March 19, 2015 4:33 PM To: Gabriel Samfira Cc: juju-dev@lists.ubuntu.com Subject: Re: Testing on windows Thanks for bringing this up. And thanks to Bogdan (and anyone else involved) for writing up that great walkthrough! I had

Re: Testing on windows

Thanks for bringing this up. And thanks to Bogdan (and anyone else involved) for writing up that great walkthrough! I had expected it to be more complicated. I'm going to be running the unit tests on windows from now on. :) I'm sure I've broken then a bunch in the last couple weeks. What

using the reviewboard dashboard effectively

I realized today that some folks may not be aware of some of the helpful columns in the reviewboard dashboard. You can see the full list of available columns by clicking on the pencil icon on the right. There are a handful of columns that I've found really helpful to me as a reviewer. Most

Re: restoring juju state

On Tue, Mar 24, 2015 at 9:25 PM, Tim Penhey tim.pen...@canonical.com wrote: I'm seriously not in favour of calling it recover, and not just because it has a particular meaning in Go. I'm glad you said so then. :) Perhaps rebuild or recreate, but recover feels wrong. Got it. I'm not married

Re: GCE provider

On Wed, Mar 25, 2015 at 1:04 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hey folks, I just signed up for a GCE trial, and tested out the provider on master. Found a couple of issues. I've filed https://bugs.launchpad.net/juju-core/+bug/1436191. I suspect the same issue would

Re: restoring juju state

On Wed, Mar 25, 2015 at 4:14 AM, roger peppe roger.pe...@canonical.com wrote: Ooh, a proper bikeshed! :) If this command is still doing the same thing it was when I first wrote the original hack version, then it's more like

Re: backporting changes to packages that use gopkg.in

On Thu, Mar 26, 2015 at 7:53 PM, Nate Finch nate.fi...@canonical.com wrote: tl;dr: godeps overrides gopkg.in, so you can have godeps pin a commit from a different branch than gopkg.in is retrieving (i.e. make a release-number branch, like 1.22 and use godeps to pin commits from there, even if

restoring juju state

juju 1.23 adds the new restore, all written in Go and integrated into core. This is a great thing and the result of a lot of effort by Horacio. In discussions with him about it, there are two things that came up that I wanted to bring up here. First, the name restore is misleading. It gives

Re: Migrating imports away from code.google.com/p to golang.org/x

On Fri, Mar 27, 2015 at 9:59 AM, Nate Finch nate.fi...@canonical.com wrote: Just an FYI: As you've probably heard, code.google.com is going away. It'll be read-only for a year IIRC and then poof. Most of the packages from the go authors lived there (crypto, etc), but now will be maintained

Re: GCE provider

On Wed, Mar 25, 2015 at 8:00 PM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: One thing to bear in mind. It seems the europe-west1-a AZ is considered deprecated and will be shut down soon (end of this month I believe). It will be nice to skip this AZ when trying to place instances.

Re: restoring juju state

I've opened https://bugs.launchpad.net/juju-core/+bug/1435413 for renaming restore to recover. -eric On Mon, Mar 23, 2015 at 10:00 AM, Horacio Duran horacio.du...@canonical.com wrote: Nope this is not very accurate I believe that you got some parts wrong out of our conversation. I am currently

possible approach for test tags

We've had discussions here a couple of times (since I joined the team) about classifying tests in our suite so they could be run more flexibly. We've also already added explicit handling for a specific kind of test along those same lines: featuretests. Additionally you can think of the CI tests

Re: possible approach for test tags

On Wed, May 13, 2015 at 9:59 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Main thing that concerns me is that it's all opt-in. Same here. I guess it doesn't matter too much, as long as CI continues to run all the tests. There's nothing stopping people from skipping running the

link to review request in launchpad

All, After posting a review request (i.e. a PR), please be sure to add a link to the review request/PR (as a comment) to the lp issue the patch addresses. Otherwise it's a pain trying to track down which commits actually relate to the issue. Similarly, be sure to include a link to the related

Re: Reminder: on June 15th, Go 1.4 will stop compiling things from code.google.com.

On Tue, Jun 2, 2015 at 5:57 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: I think there was an effort to remove this from our code, but I thought I'd send out a reminder to check and for personal projects. May the source be with you... code.google.com/p/winsvc is the only

Re: use --upload-tools when bootstrapping the LXD provider

On Fri, Nov 6, 2015 at 8:41 AM, Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > That may be true, but the LXD provider branch has a stale version > number. Once the version number is updated to 1.26-alpha2, I imagine > the lxd provider

Re: Juju devel 1.26-alpha2 is available for testing

On Fri, Nov 27, 2015 at 9:00 AM, Marco Ceppi wrote: > On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley > wrote: >> Requirements >> >> - Running Wily (LXD is installed by default) >> > > For the LXD provider, I have the latest LXD

Re: lxd provider in master

On Sun, Nov 22, 2015 at 8:50 PM, Tim Penhey 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 environments.yaml file I added a very simple clause: > >lxd: > type: lxd This is

Re: trouble with dependent repos

On Mon, Nov 23, 2015 at 9:32 PM, Nate Finch wrote: > Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable, I had a similar experience last week with backward-incompatible changes in the utils repo. :( > and using that code from master of

Re: LXD support (maybe)

I also left a review. Mostly LGTM. I just wanted a bit of feedback before giving it a ship-it. :) -eric On Thu, Feb 25, 2016 at 8:11 AM, Andrew McDermott wrote: > I took a quick look through it as I was OCR - comments in RB. > > On 25 February 2016 at 15:00,

Re: Planning for Juju 2.2 (16.10 timeframe)

On Fri, Mar 18, 2016 at 8:57 AM, Tom Barber wrote: > c) upload files with actions. Currently for some things I need to pass in > some files then trigger an action on the unit upon that file. It would be > good to say path=/tmp/myfile.xyz and have the action upload that

Move provider implementations under their related projects.

Perhaps we should move the implementation of some providers over to the repos for the projects with which the providers interact (and then just import them in providers/all). Then those providers would be more likely to stay up-to-date in the face of changes in the project, particularly

Re: auto-upgrading models

On Mon, Apr 25, 2016 at 6:38 PM, Andrew Wilkins wrote: > Whatever we do, #2 should never be optional. Agreed. > > I would like us to have all of #2, #3, #4, #7. This is my opinion too. Menno suggested another option (call it #8): a model config setting equivalent

Re: auto-upgrading models

On Mon, Apr 25, 2016 at 5:24 PM, Menno Smits wrote: > A per-model flag which indicates that the model should automatically upgrade > when the controller does might be nice too (this what #7 means I think?). I meant a CLI flag for "juju upgrade-juju". If I understood

Re: Static Analysis tests

On Wed, Apr 27, 2016 at 9:14 PM, Nate Finch wrote: > So, I don't really think the method of testing should determine where a test > lives or how it is run. I could test the exact same things with a more > common unit test - check the tls config we use when dialing the

auto-upgrading models

In a recent bug I was working on the issue of auto-upgrading models came up. I also ran into this personally not too long ago. Currently, running "juju upgrade-juju -m admin --upload-tools"[1] upgrades the admin model to a new version. To set the version of any other model to the uploaded one,

Re: Machine agents uninstall themselves upon worker.ErrTerminateAgent.

On Mon, May 9, 2016 at 1:56 AM, Andrew Wilkins wrote: > But... I've just looked at the 1.25 branch again, and the fix *was* made > there. And from Jorge's comment > https://bugs.launchpad.net/juju-core/+bug/1514874/comments/4, we can see > that the uninstall logic

Re: Machine agents uninstall themselves upon worker.ErrTerminateAgent.

On Mon, May 9, 2016 at 10:50 AM, Eric Snow <eric.s...@canonical.com> wrote: > I'll check it with 1.25 too, though I expect that the result will be the same. Under 1.25, using the local provider, I was able to reproduce the behavior. On the and even got the same confusing log entry:

Machine agents uninstall themselves upon worker.ErrTerminateAgent.

See https://bugs.launchpad.net/juju-core/+bug/1514874. When starting, the machine agent starts up several workers in a runner (more or less the same in 1.25 and 2.0). Then it waits for the runner to stop. If one of the workers has a "fatal" error then the runner stops and the machine agent

Re: Machine agents uninstall themselves upon worker.ErrTerminateAgent.

On Fri, May 6, 2016 at 11:37 AM, William Reade <william.re...@canonical.com> wrote: > On Fri, May 6, 2016 at 5:50 PM, Eric Snow <eric.s...@canonical.com> wrote: >> >> See https://bugs.launchpad.net/juju-core/+bug/1514874. > > > Mainly, we just shouldn't do it. T