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 clari

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 cla

Re: Juju 2.3 beta2 is here!

here. > > I like the thrust of Tim'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 exam

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

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 a

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

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 Juju-dev@list

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 co

Re: More juju upgrade-juju failings

that we have a shared Google doc to mock up a nice > experience starting with the simple command 'juju upgrade' which then > walks people through the process, including the distinction between > upgrading charms, agents and controllers, as well as the ability to do

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 t

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

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... > > I&

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 bein

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 y

Help needed for the API

Hi folks, I'm hoping someone can help point me to the right bits of the API. I have to admit to being lost looking at the code under state/api. I'm wanting to have a worker that gets notified when the environment config changes in state, and I want to write another api call to request the loggin

Focus for the next three weeks

Hi folks, Lets start with the target: we have Saucy being released next month, and we want to get a rocking release done for that. Working backwards, and giving ourselves a week slack (which we will end up needing) before final freeze, takes us roughly to the end of September. I'd like to see wh

Re: Focus for the next three weeks

On 10/09/13 16:13, David Cheney wrote: > Sorry to add more wood to the pile, but 1.14.0 needs to go out, basically now. > > https://launchpad.net/juju-core/+milestone/1.14.0 > > Shows three issues (one is merged on trunk, but needs backporting) We are down to just one issue now. Tim -- Juju-

Re: Focus for the next three weeks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/13 02:43, John Arbash Meinel wrote: > On 2013-09-10 7:39, Tim Penhey wrote: ... > > >> 1. MAAS Tag support > >> This seems to be a key need for a number of engagements we have, >> and also a reason why some M

Re: Focus for the next three weeks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/13 02:33, John Arbash Meinel wrote: > ... > >>> Right now we don't have a way to restrict the users creating >>> containers that they cannot address. I propose that we add a >>> method to the environment interface that is >>> SupportsConta

Re: Update "launchpad.net/loggo"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/09/13 15:15, John Arbash Meinel wrote: > It looks like Tim's recent patch to change how logging is > monitored needs an updated "launchpad.net/loggo". > > I don't know the timing of it, but I had loggo 38 here for a long > time, and you need at

Duplicate lines in machine agent log files

Hi folks, Yes this is my fault. An unintended consequence of a logging change before. Now when you specify a log file and show log, it logs to both places. Show log goes to stderr. Upstart is real smart. It puts the output from stdout and stderr into the logfile you specify. I made --debug ke

Re: Duplicate lines in machine agent log files

On 13/09/13 17:15, Tim Penhey wrote: > Hi folks, > > Yes this is my fault. An unintended consequence of a logging change before. > > Now when you specify a log file and show log, it logs to both places. > Show log goes to stderr. > > Upstart is real smart. > >

Clean Code review

Hi All, By now you folks will have your copy of the book, and I know that some of you have started reading it already. I know that Java is used for most of the examples, but I'm sure you can get over that and see the good advice. For the first review, let's aim to have read up to the end of chap

Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

Hi folks, Rereading this book reminded me how good I found it. I went through and picked out some bits that I think that should be repeated. Small things matter. There has been a joke amongst some Canonical folks for a while that the company name should be "Pedantical". I'm a big supporter of

Re: Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

On 17/09/13 18:20, Andrew Wilkins wrote: > On Tue, Sep 17, 2013 at 2:02 PM, Jeroen Vermeulen > mailto:jeroen.vermeu...@canonical.com>> > wrote: > Tim described duplication as a symptom. The difference is in > identifying the cause. Sometimes it takes you in much better > directions th

Re: Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

On 18/09/13 07:33, Gustavo Niemeyer wrote: > This isn't, by all means, to suggest that we should stop caring about > the quality of our code base. I'm all for improving variable names, > type names, and whatever else, as people who actually worked with me > can confirm. It's rather just a small rem

Re: Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

On 20/09/13 04:57, Mark Canonical Ramm-Christensen wrote: > *Rules of Thumb for Code Cleanup* > > But, for everyday work, I'm also very aware that we need some shortcuts, > and rules of thumb. We can't make every single code cleanup decision by > trying to weigh all the costs and all the benefits.

Fwd: Re: PatchEnvironment and PatchValue on cleanup suite (issue 13770045)

Moving this to the mailing list, because comments on landed code means most people don't see it. > On 2013/09/19 15:15:12, rog wrote:> I just noticed this. > >> "The Set function was moved from testing/checkers to >> testing. It wasn't a checker and it has also been >> renamed to PatchValue, and

Re: Fwd: Re: PatchEnvironment and PatchValue on cleanup suite (issue 13770045)

On 20/09/13 13:50, Tim Penhey wrote: > Perhaps we add a new package for these, and the patch methods in order > to limit the dependencies, and to also add a test for that package to > make sure that extra dependencies don't creep in. So, I did just this: r1848 moves th

Re: Updating state on agent upgrade

On 26/09/13 14:46, Andrew Wilkins wrote: > On Thu, Sep 26, 2013 at 3:20 AM, William Reade > I strongly agree that when we're in a position to manage upgrades > sanely, we should by default apply all upgrades until we reach the > latest version. The requirement to advance in .2s is only

issues with the local provider and saucy

Hi folks Gary has reported issues with the local provider on saucy. Is there anyone else that can confirm? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Logging changes coming with juju 1.15

Hi All, Last night I was pointed at a bug where one of the main problems was poor communication on my part as to changes, so here is the comprehensive details. For a long time (all of juju-core up to now), all the machine agents logged everything at debug. Logging at the debug level is used prim

Re: Logging changes coming with juju 1.15

On 27/09/13 10:26, Kapil Thangavelu wrote: > I don't think the log collection is the issue though this is still > useful to help mitigate perhaps some of the log accumulation on disk > (despite rotation archival). The problem is the primitive log display > which amounts to tail aggregated syslog. A

local provider issues with trunk (2 fixed)

Hi folks, I came in this morning to attack the LXC issues, but got stuck into two other issues first. The local provider wasn't bootstrapping properly, it would say it was, but it wasn't. There were two issues: 2013-09-26 23:12:26 ERROR juju.worker environ.go:51 loaded invalid environment confi

Re: Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

On 26/09/13 22:30, Nate Finch wrote: > Sorry, I've had this half typed out for like a week and a half. > > A general overview - I was actually really excited about the book. I try > to stress in words and actions that readable code is so much more > important than almost anything else. However, I

Re: local provider issues with trunk (2 fixed)

On 27/09/13 14:59, Kapil Thangavelu wrote: > On the topic of local provider bootstrap i ran into this bug earlier today > > Bootstrapping a local provider first prevents bootstrap on any other > environment > https://bugs.launchpad.net/juju-core/+bug/1231724 This is new addition, I've assigned th

Re: local provider issues with trunk (2 fixed)

On 30/09/13 07:37, Kapil Thangavelu wrote: > On Fri, Sep 27, 2013 at 12:33 AM, Tim Penhey <mailto:tim.pen...@canonical.com>> wrote: > > On 27/09/13 14:59, Kapil Thangavelu wrote: > > On the topic of local provider bootstrap i ran into this

Consistent test failures with saucy

Hi folks, Most of the upgrade worked fine. I am however finding some problems with the test suite. I have one test that consistently fails: bootstrap_test.go:78: s.runAllowRetriesTest(c, test) bootstrap_test.go:99: c.Check(findToolsRetryValues, gc.DeepEquals, test.expectedAllowRetry) ..

Branch owner change for lp:gomaasapi

Hi folks, lp:gomaasapi is now owned by ~juju. We should put it under our go-bot control. If you haven't already done this, change the pull location of the branch to be lp:gomaasapi, this will get resolved to: bzr+ssh://bazaar.launchpad.net/+branch/gomaasapi So if the owner changes, you won't c

Local provider broken (AGAIN) in 1.16

I have filed a critical bug and will start on it right now. https://bugs.launchpad.net/juju-core/+bug/1240709 Please, when you change stuff in bootstrap, test the local provider. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com

Re: Local provider broken (AGAIN) in 1.16

. But theoretically, yes. Tim > On Wednesday, October 16, 2013, Tim Penhey wrote: > > I have filed a critical bug and will start on it right now. > > https://bugs.launchpad.net/juju-core/+bug/1240709 > > Please, when you change stuff in bootstrap, test the l

Re: State interfaces

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/11/13 01:57, John Arbash Meinel wrote: > On 2013-10-31 16:21, Andrew Wilkins wrote: >> Does anybody object to converting the public entity structs in >> state to interfaces? i.e. State, Machine, Unit, etc. > >> I'd like to write some tests for

Re: State interfaces

On 01/11/13 08:49, Nate Finch wrote: > Preferably, if you find yourself needing an interface that only has A, > make an interface that only has A, and have your function use that > interface. :) > > But that is a neat trick for when the above isn't possible for whatever > reason. Well, sometimes

Re: API work

On 02/11/13 03:32, Kapil Thangavelu wrote: > I'd suggest creating a bug per command (some already have extant bugs), > there's vastly differing amounts of work in them, and its easier to > track progress with appropriately sized tasks. ie kanban style cli api > is a story. As discussed at the spri

Lots of outstanding merge proposals

Hi folks, The active reviews page is looking OMG long. code.launchpad.net/juju-core/+activereviews Please take some time today to look at the outstanding work that you have, and work out what can be landed, and chase reviewers for work. As the author of the work, it is your responsibility to ma

Re: API work

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/13 00:45, John Arbash Meinel wrote: >> https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-cli-api > >> I also went through the photo I took of our big bit of paper >> and marked done those that were (although sync-tools seemed to b

Rolling 1.16.3

Hi Curtis, The local provider was broken again with an update to cgroups-lite. This then triggered an apparmor protection mechanism from the host machine, and left apt in an incomplete state. The symptoms are that install hooks fail to run for units. Tracked in bug https://bugs.launchpad.net/juj

Re: High Availability command line interface - future plans.

On 07/11/13 09:11, David Cheney wrote: > +1 (million), this solution keeps coming up, and I still feel it is > the right one. > > On Thu, Nov 7, 2013 at 7:07 AM, Kapil Thangavelu > wrote: >> >> instead of adding more complexity and concepts, it would be ideal if we >> could reuse the primitives w

Re: High Availability command line interface - future plans.

On 07/11/13 15:00, Andrew Wilkins wrote: > On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth > wrote: > > So, I haven't been involved directly in a lot of the discussion, but > my 2c is: > > +1 to juju ensure-ha > > Users don't give a f*ck about how Juju

Re: High Availability command line interface - future plans.

On 07/11/13 16:23, Marco Ceppi wrote: > On a final note, if namespacing does become a thing, can we /please /use > a unique character for the separation of namespace:service? A : would be > fantastic as calling something juju-db could very well be mistaken or > deployed as another service? `juju de

Re: High Availability command line interface - future plans.

On 09/11/13 03:04, roger peppe wrote: > On 8 November 2013 13:51, Gustavo Niemeyer wrote: >> juju add-state-server --api-only-please-thanks > > And if we want to allow a machine that runs the environment-manager > workers but not the api server or mongo server (not actually an unlikely thing > gi

Re:

On 18/11/13 23:09, William Reade wrote: > Curtis, I think you're correct, but I'd like to see Tim's confirmation. I was looking to backport the changes into the 1.16 branch, but Roger ended up doing it, as he had a related change (I seem to recall). I updated the bug task, but it was Roger's comm

Re: API compatibility policy and practices between juju versions

On 20/11/13 12:05, Curtis Hovey-Canonical wrote: > I am not sure if I am leading a discussion or just stating that we > have a problem that I don't believe can be ever solved. > > We abandoned the release of 1.16.4 because we found it was > incompatible with 1.16.3 > https://bugs.launchpad.net

Re: API compatibility policy and practices between juju versions

something. What I'm referring to is the api server, and the agents as clients, not the command line. Tim > On Nov 19, 2013 8:43 PM, "Tim Penhey" <mailto:tim.pen...@canonical.com>> wrote: > > On 20/11/13 12:05, Curtis Hovey-Canonical wrote: > > I am no

Re: Fwd: API compatibility policy and practices between juju versions

On 21/11/13 09:26, Curtis Hovey-Canonical wrote: > Resend to the list. > > > On Tue, Nov 19, 2013 at 11:42 PM, John Meinel wrote: >> I know William and I are well aware that 1.18 cli wont work with a 1.16 >> server (and most likely the reverse is true). >> Agent compatibility is actually easy at

Re: Synchronous Bootstrap

On 04/12/13 03:49, Andreas Hasenack wrote: > On Tue, Dec 3, 2013 at 12:41 PM, William Reade > mailto:william.re...@canonical.com>> wrote: > > On Tue, Dec 3, 2013 at 12:49 PM, Andreas Hasenack > mailto:andr...@canonical.com>> wrote: > > On Tue, Dec 3, 2013 at 4:31 AM, Andrew Wilkin

KVM provisioning now in trunk

Hi folks, For those who like living on the edge, we now have KVM container support in trunk. It is kinda hard to confirm it fully works right now. I need to actually test it on a MAAS install that is KVM capable. Constraints aren't yet supported, that should be coming tomorrow (fingers crossed).

Re: KVM provisioning now in trunk

On 05/12/13 02:22, Daniel Westervelt wrote: > > > On 12/04/2013 05:51 AM, James Page wrote: >> Hi Tim On 04/12/13 04:44, Tim Penhey wrote: >>> For those who like living on the edge, we now have KVM container >>> support in trunk. >> >> Nice work

Re: KVM provisioning now in trunk

On 05/12/13 09:40, Kapil Thangavelu wrote: > > > > On Wed, Dec 4, 2013 at 11:58 AM, Daniel Westervelt > <mailto:daniel.westerv...@canonical.com>> wrote: > > > > On 12/04/2013 02:36 PM, Tim Penhey wrote: > > On 05/12/13 02:22, Daniel Westerve

Can we get an update on the individual juju CLI/API tasks?

Here are the outstanding items from the blueprint [1] api-endpoints: TODO upgrade-charm: TODO sync-tools: TODO [dimitern] deploy: INPROGRESS [gz] status: INPROGRESS [axwalk] destroy-environment: INPROGRESS This hasn't been updated for ages, and I know that we have moved on to the hard ones now,

strawman - make the agents not run as root

Hi folks, We have been telling people for ever not to run things as root. Most packages that run systems things create users for that purpose. Every time I think of our machine and unit agents running as root, I end up feeling a little guilty. Why is this fine for us? However, we can't just make

juju system ssh keys - revisiting

Hi all, A while back Andrew raised the suggestion that we create a SSH key for the purpose of monitoring the juju bootstrap. This has raised its head again for several reasons: 1) Many windows users don't have ssh keys, nor even ssh installed. We have a go ssh implementation that we can fall bac

Re: juju system ssh keys - revisiting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/12/13 19:33, John Arbash Meinel wrote: > On 2013-12-17 10:20, John Arbash Meinel wrote: >> ... >>> This hints to me that Juju run is improperly design. We already >>> have a way to inform all machines that we have work for them >>> to do. Which

Closed network support

Hi folks, We have a rather nebulous work item called closed network support where we mention supporting proxies. Do we have a list of what proxies we need to support and where we currently fall down? Obviously there is apt. What proxy configuration or exports are we missing? HTTP proxies I gues

Re: Juju 1.17.1 milestone

On 22/01/14 16:10, Ian Booth wrote: > IMO, a 1.17.1 release this week would be great. There's a number of important > user visible fixes eg > 1. many local provider improvements/fixes (done this week) > 2. much better custom image metadata workflow > 3. fixes for ssh key management > 4. ready to bo

Dunedin core sprint results

Hi folks, This week Tim, Ian, Andrew and Jesse were sprinting our little hearts out in Dunedin, NZ. Our primary focus was to look at improving closed network support, and making some local provider improvements, with a side of knowledge sharing and induction stuff. I think it has been a very suc

Re: lxc bug blocks 1.17.1 release.

On 26/01/14 19:28, Andrew Wilkins wrote: > On Sat, Jan 25, 2014 at 11:17 PM, Curtis Hovey-Canonical > mailto:cur...@canonical.com>> wrote: > CI has not passed local upgrade to 1.17.1 and deploy with 1.17.1 tests > since lp:juju-core r2248. The next revision tested was 2253 (a lot of > r

Re: lxc bug blocks 1.17.1 release.

On 26/01/14 19:28, Andrew Wilkins wrote: > On Sat, Jan 25, 2014 at 11:17 PM, Curtis Hovey-Canonical > mailto:cur...@canonical.com>> wrote: > CI sees this on when is uses 1.17.1 juju to boostrap: > > juju --debug bootstrap -e local --constraints mem=2G 2>&1 | tee > bootstrap.log > 2

Intermittent test failures

Hi folks, Recently I have been hit by two particular tests that have intermittent failures on a very regular basis. About two times out of three. cmd/jujud - seems to get hit by machine not provisioned problems Has anyone looked into this? The other is in: replicaset ---

Re: lxc bug blocks 1.17.1 release.

On 27/01/14 08:13, Tim Penhey wrote: > On 26/01/14 19:28, Andrew Wilkins wrote: >> On Sat, Jan 25, 2014 at 11:17 PM, Curtis Hovey-Canonical >> mailto:cur...@canonical.com>> wrote: >> CI sees this on when is uses 1.17.1 juju to boostrap: >> >> juju -

Re: Intermittent test failures

On 27/01/14 09:53, Nate Finch wrote: > The second one I've seen often on the bot but rarely my machine. That's > in my new replica set code. My guess is that it's just the Mongo server > taking a long time to start up, but I'm not certain of that. Hmm, perhaps the opposite? I have a very fast i7

Re: Dunedin core sprint results

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/01/14 02:29, John Arbash Meinel wrote: > On 2014-01-24 8:10, Tim Penhey wrote: >> Hi folks, > >> This week Tim, Ian, Andrew and Jesse were sprinting our little >> hearts out in Dunedin, NZ. > >> Our prima

Re: lxc bug blocks 1.17.1 release.

On 28/01/14 08:19, Kapil Thangavelu wrote: > > sudo su - jenkins would work here and avoids triggering the ref'd issue, > its giving a login shell without the SUDO env vars (ie shed the original > identity) that juju was looking up to try to find the original user to > chown. FWIW the fix has lan

Fwd: [Branch ~go-bot/juju-core/trunk] Rev 2268: [r=thumper] Move the loggo import to the github location

49:22 - From: nore...@launchpad.net Reply-To: nore...@launchpad.net To: Tim Penhey Merge authors: Tim Penhey (thumper) Related merge proposals: https://code.launchpad.net/~thumper/juju-core/move-loggo-to-github/+merge/203620 proposed by: Tim Penhey (th

new dependency

Heads up folks, a new dependency has been added. github.com/errgo/errgo This can replace most fmt.Errorf calls. errgo captures the location of the calls to New, Annotate and Translate and will create a call stack. errgo.New to create a new error errgo.Annotate to add contextual information. Do

Re: new dependency

te something more about that will be put into the README.md that will show more usage. Tim > On Feb 5, 2014 7:29 PM, "Martin Packman" <mailto:martin.pack...@canonical.com>> wrote: > > On 04/02/2014, Tim Penhey <mailto:tim.pen...@canonical.com>> wro

Re: manual bootstrap in 1.18

On 04/03/14 15:22, Andrew Wilkins wrote: > On Tue, Mar 4, 2014 at 12:54 AM, William Reade > However, blocking 1.18 on this change would be most unhelpful to > many people, so we would like to simply switch off manual provider > bootstrap for the 1.18 release; this would *not* be a regre

Upcoming import change for loggo

Hi all, I'm just preparing a branch that will change the loggo imports from github.com/loggo/loggo to github.com/juju/loggo I felt that it would be good to get a bunch of useful Go libraries under the juju banner, and I saw no reason not to put loggo there. If you are using loggo

Re: Where should loggo live (and errgo, ...)?

On 06/03/14 15:46, Ian Booth wrote: > Hi > > Currently, the loggo library used by juju-core is hosted on Github at > github.com/loggo/loggo. > > Given juju-core is moving to github.com/juju, it's been proposed that loggo > move > across to github.com/juju/loggo. We already have github.com/juju/e

Re: Landing bot alive again

On 07/03/14 07:59, Martin Packman wrote: > At second attempt, the landing bot is now running again, moved over to > lcy01. Feel free to mark any branches 'Approved' to land them. > > As part of the setup, several people's keys were added to the tarmac > machine, but most management should be possi

github.com/juju/testing

In the continued process to break up juju-core where appropriate for our other Go based code, I have made available our testing additions. This adds CleanupSuite, LoggingSuite, the various Patch* functions, and the checkers that have been written. We should soonish move juju-core to use this new

Landing bot not updating dependencies

Hi there, I tried to land a branch that updated the golxc version in our dependencies.tsv file. This used to work, and now the current bot doesn't do it. After a bit of poking around I find the /home/tarmac/.config/tarmac/tarmac.conf file. [lp:juju-core] debug_log_location = /home/tarmac/logs/

Re: Landing bot not updating dependencies

It seems that I have mis-remembered and the bot has never done this, but the CI process has. Can we make the bot do it please? Tim On 13/03/14 10:47, Tim Penhey wrote: > Hi there, > > I tried to land a branch that updated the golxc version in our > dependencies.tsv file. This

Re: "destroy-environment" and /var/log/juju*

On 24/03/14 18:48, John Meinel wrote: > I just did a "juju destroy-environment -y local" and it did kill the > agents, but it left the /var/log/juju-jameinel-local directory lying around. > It also left ~/.juju/local/ (with storage and db dirs), though the log > dir is gone. That was by design, as

Re: Implementing Juju Actions

On 27/03/14 20:47, John Meinel wrote: > Juju run is currently a way to execute arbitrary shell code on machines > inside of a hook context. Actions are running charm-defined shell code > inside a hook context. There is a certain amount of overlap between the two. > > As I understand it, juju-run a

local provider destroy-environment sometimes fails with a weird error

Hi folks, I noticed this at the end of last week, but shelved the thoughts until this weed as other things were taking priority. $ juju destroy-environment local -y [sudo] password for tim: ERROR readdirent: no such file or directory ERROR failed to destroy environment "local" If the environment

Re: local provider destroy-environment sometimes fails with a weird error

It appears to be a race between the machine agent deleting the data-dir, and the destroy function deleting the data-dir. I'll work around it somehow. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Go 1.3 beta can build Juju

On 17/04/14 13:20, David Cheney wrote: > Hello, > > Go 1.3 beta will ship this week, or at some point before the > conference on the 24th. > > For a long time Go 1.3 beta could not build Juju properly, the tests > would crash the runtime and other strange issues. > > I've been able to work with

Re: Go 1.3 beta can build Juju

On 17/04/14 13:24, David Cheney wrote: > On Thu, Apr 17, 2014 at 11:22 AM, Tim Penhey wrote: >> On 17/04/14 13:20, David Cheney wrote: >>> Hello, >>> >>> Go 1.3 beta will ship this week, or at some point before the >>> conference on the 24th. >&g

Developer docs

Here are some notes from the discussion we had last week. A key part was to make sure that the developer documentation was available outside the actual source tree. We thought something like: https://juju.ubuntu.com/dev/ - Developer Documentation The actual files are in the source tree in th

Re: Preferred wrapping for long function declarations

I'm in general agreement with Dave. I don't think it really matters too much as long as gofmt keeps it sane. As we have already found, everyone will have differing opinions about this, and I'm not going to share mine here. While I understand the desire to get consensus on this topic, we have a t

Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

Hi all, I took it upon myself to get Rog's errgo library used inside juju-core. Dimiter recently did a hunk of work in the juju-core/errors package to have functions to add context to some core error types while keeping their type. What I did was to move this errors package out of juju-core and

Making juju work better with gccgo

Hi folks, I'm sure most of you are aware that we now use gccgo to compile juju for the ppc64el and arm64 architectures. We have a great [0] test suite with juju, and also for most of the packages that we depend on. However we can't gate every commit on testing with both compilers on all the arch

Re: Making juju work better with gccgo

I realise I left this bit hanging: On 16/05/14 14:41, Tim Penhey wrote: > A key issue that Dave and I have been poking with a stick is the test > suite for juju/errgo, as it had some failures with gccgo (all passed > with gc). In the end it had to do with the runtime.Caller method

Schema migration process

Hi folks, We have been talking about how to handle database schema updates for a long time, and many times things were deferred as we had clients connecting directly to the database. Due to the hard work of the team, we are no in a place where this is no longer the case as all external connection

testing (was Re: Making juju work better with gccgo)

a few tests which do not pass under trusty, these > are tracked with bugs in lp, just look for the gccgo label if you find > yourself at a loose end. > > Cheers > > Dave > > [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not >

Re: Schema migration process

On 16/05/14 17:29, John Meinel wrote: > So I'm pretty sure the ability to do schema upgrades was scoped in the > HA work that Nate is working on. I believe the idea is roughly: OK, I see the card on the board on Nate's team for this iteration. Is it likely to get done? Since this is something th

Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

On 23/05/14 02:47, roger peppe wrote: > Any particular reason to wrap the errgo functions rather than using errgo > directly? Personally, I see the role of the errors package to be about > specific error classifications (something that errgo tries hard to be entirely > agnostic about), but errgo co

Version numbering (was Re: new alpha beta support broke CI)

On 27/05/14 16:09, Curtis Hovey-Canonical wrote: > The alpha beta support affects packaging.and tools naming. This chagne > should have been discussed with Juju QA before landing. CI cannot make > a package or extract tools. > http://juju-ci.vapour.ws:8080/job/publish-revision/415/console > >

interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 11:46, William Reade wrote: > Re unsafe: where we can't check equality, we fall back on identity. We > know it's a hack; and if it's fundamentally broken, we'd like to know > why, so we can fix it. Please clarify your objections. I do have a question around this and it is one that I ha

  1   2   3   4   >