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

Re: juju-local bootstrap: connection refused

On 25/10/13 01:17, Peter Waller wrote: Hi All, I'm on Ubuntu 12.04.3 with the juju stable repository and trying to experiment with juju locally. I can't seem to get past the bootstrap though. I've followed the instructions here: https://juju.ubuntu.com/docs/config-local.html But when

Re: Troubleshooting the local provider docs now available.

On 05/11/13 09:16, Jorge O. Castro wrote: Hi everyone, We've started to collect best practice for troubleshooting the local provider: https://juju.ubuntu.com/docs/troubleshooting-local.html These docs are NOT yet indexed on the main table of contents on the side, I wanted to give you

Re: juju-local

On 04/11/13 22:55, Stuart Bishop wrote: On Mon, Nov 4, 2013 at 11:40 AM, Yasmany Cubela Medina yasman...@gmail.com wrote: Im trying to configure juju-local on my virtual-box machine to test some environments, learn, play and then make some desition to deploy to my cloud. I follow the docs on

Re: docker hype and juju's future

On 21/11/13 21:43, Ramez Hanna wrote: I am sure it is on the roadmap to containerize services on the juju deployed services Containerisation is simple, but networking is hard. We have lxc containers working in juju now, but they are currently only addressable in MAAS. We have some work

Re: Vagrant boxes with Juju now available

On 07/12/13 07:46, Daniele Stroppa wrote: John, David, the reason why I'm destroying the service and re-deploy it's because I'm testing/debugging my charm's hooks, specifically the install hook in this case. My understanding is that 'juju upgrade-charm' will trigger the upgrade-charm

Re: Fwd: How to make juju aware of IP address changes?

On 07/12/13 05:04, roger peppe wrote: I think that there are a few things that could help here, most important points first: - We should limit agent restarting in some way (exponential backoff or retry limits or both) I think this is a key one. If the agent is repeatedly failing, we should

Re: Questions about the integration of the Outscale cloud provider into juju-core

will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage

The PostgreSQL charm, AWS and robustness

Hi folks, I'm writing not as a canonical core developer, but as a user who is occasionally stupid :-) I have a new project that I'm wanting to deploy and it is a django project backed with a postgresql database. Pretty simple really. I want to manage my deployment with Juju, but I want to

Re: The PostgreSQL charm, AWS and robustness

On 30/05/14 01:28, Patrick Hetu wrote: I have a new project that I'm wanting to deploy and it is a django project backed with a postgresql database. Pretty simple really. If you plan to use the python-django charm be sure to use this branch:

Having trouble with the block-storage-broker and ec2

Hi folks, I'm attempting to get postgresql working on EC2 with the new block-storage-broker so the postgresql database can be stored on a persistent s3 device. https://manage.jujucharms.com/charms/precise/block-storage-broker I copied the basis of the bundle below from the docs above, however

Re: Having trouble with the block-storage-broker and ec2

On 07/06/14 00:29, Andreas Hasenack wrote: On Fri, Jun 6, 2014 at 7:39 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: options: provider: ec2 key: my key endpoint: WHAT_GOES_HERE

Re: Having trouble with the block-storage-broker and ec2

On 15/08/14 15:27, Charles Butler wrote: Thread Necromancy, Have we had any movement on this Tim? If not I'd like to file a bug to move the BSP off of the euca2ools and instead use either the AWS SDK or write API client wrappers for this. I've not done anything, but I'd agree that the

Re: Juju is still too hard

On 22/09/14 03:29, Michael Schwartz wrote: Guys, I hate to break this to you, but deploying and managing Juju is still too hard and too unreliable. I hear this in the market, and my own experience confirms it. The two times I tried, once on my local system, once on Azure, it didn't

Re: Gluu Server Juju Charm

On 24/09/14 16:20, Michael Schwartz wrote: Juju team, Thanks to Charles and José, I was able to get my local deployment of Juju running, and later I was successful getting the Gluu Server and Gluu OpenDJ charms installed, which is great progress. Good to hear. Tim -- Juju mailing list

Re: python-django charm questions

On 03/12/14 06:38, Simon Davy wrote: On 2 December 2014 at 17:04, sheila miguez she...@pobox.com wrote: * Why is django_extra_settings used in config_changed but not during install? I expect that's a bug. The config_changed hook is called after the install hook when first installing. Tim

Re: feedback about juju after using it for a few months

On 18/12/14 11:24, Caio Begotti wrote: Folks, I just wanted to share my experience with Juju during the last few months using it for real at work. I know it's pretty long but stay with me as I wanted to see if some of these points are bugs, design decisions or if we could simply to talk about

problems working with bundletester

Hi folks, tl;dr: lots of problems with bundletester, ping me on IRC I have been spending several hours today trying to get bundletester working properly, and a clean environment from which to run it. Based on a clean trusty install, pip install bundletester fails. The build failed due to

Re: Upcoming change in 1.24: tags in EC2

On 22/05/15 17:26, Andrew Wilkins wrote: Hi all, Just a small announcement, in case anyone cares. In the EC2 provider, from 1.24, we will start tagging instances and volumes with their Juju-internal names and the Juju environment UUID. Instances, for example, will have a name of machine-0,

Re: ERROR cannot read info: lock timeout exceeded

ck and look for a process with the same PID as in the lock file > and if it doesn't exist break it automatically. This assumes all local > access, (so sharing $HOME over NFS is risky). > > John > =:-> > > > On Mon, Sep 28, 2015 at 12:42 AM, Tim Penhey <tim.pen...@c

Re: ERROR cannot read info: lock timeout exceeded

On 26/09/15 22:02, Mark Shuttleworth wrote: > On 25/09/15 15:43, Tim Van Steenburgh wrote: >> >>> Generating separate JUJU_HOMEs will insulate your from bug >>> https://bugs.launchpad.net/juju-core/+bug/1467331 >> >> Thanks, I'm going to try this approach and see what happens. Although, it >>

Re: ERROR cannot read info: lock timeout exceeded

The code does just hold the lock for the duration of the read or write. Since it is possible to have multiple environments sharing a server, and the server data, the access to that data is synchronized. There *shouldn't* be a case where the lock is held but not released. The lock file itself

Re: Juju 2.0-beta9 ETA

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

Re: Use of Jujucharms to launch non-opensource code

IANAL either, but if you are just using Juju and public charms to deploy a commercial project or product, then I think that is fine. Like deploying a private django app (which is what I do). This is just using the tools for what they were designed for. However, if you are modifying Juju source,

Re: Logging into the API on Juju 2.0

On 01/03/16 03:48, Adam Stokes wrote: > Is there a way to list all models for a specific controller? Yes. > https://godoc.org/github.com/juju/juju/api/controller > and https://godoc.org/github.com/juju/juju/api/modelmanager seem to do > the same thing wrt listing models. This also only does it

Re: Logging into the API on Juju 2.0

an.bo...@canonical.com>> wrote: > > > > On 01/03/16 11:25, Adam Stokes wrote: > > On Mon, Feb 29, 2016 at 7:24 PM, Tim Penhey > <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>> > > wrote: > > > >> On 01/

Re: Juju Secrets

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

Re: BDX <-> Juju

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

Re: Deploying local code

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

Re: Feedback wanted: Changes to the Ubuntu Charm

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

Re: Increasing the size of VERSION in tabular status output

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

Re: List plugins installed?

On Thu, Sep 29, 2016, 6:07 PM Tim Penhey <tim.pen...@canonical.com <mailto:tim.pen...@canonical.com>> wrote: If we do that, then we can make the plug-in also install a metadata file that explains help and usage, so you don't call the script to do that. It makes it easy to l

Re: Juju 2.0 is here!

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

Re: A (Very) Minimal Charm

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

Re: Constraints for Additional Units

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

Re: LXD bootstrap inside KVM failed

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

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

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

Re: Upgrading juju2

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

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

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

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

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

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

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

PROPOSAL: stop recording 'executing update-status hook'

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

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

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

Juju 2.3 release train starting

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

Re: Debug logs

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

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

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

Beware 2.2.7 release

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

Re: Juju 2.3-rc2 is here!

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

Re: EC2 availability zones and bundles

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: LXD on Manual incorrect resolv.conf

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

Re: juju 2.3.3 failing to bootstrap localhost

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

Moving conversations to discourse and closing this list.

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

Re: Aggregate all bundle.yaml | API endpoint

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

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

Intro to Juju webinar in about 13 hours

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

Re: More juju upgrade-juju failings

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

Re: Policies for coding

On 23/08/13 21:37, roger peppe wrote: On 23 August 2013 04:11, Tim Penhey tim.pen...@canonical.com wrote: // TODO (thumper): 2013-08-23 bug 1654321 // Details about the change needed, or things to do. This seems reasonable, but there's one down side - currently for most TODOs, a grep

Clean Code and single character variable names

Hi all, If you haven't yet, please get a copy of Clean Code [1] as we will be starting reviews of it soon. I have found a reference in that book that pretty clearly describes my dislike for single character variable names. I type that section here. Avoid Mental Mapping [2] Readers shouldn't

Re: Null provider and failing early

On 27/08/13 11:50, Andrew Wilkins wrote: On Tue, Aug 27, 2013 at 8:44 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Perhaps we should have a sanity-check type callback into the provider with the constraints at the time we want to add a machine

Re: Policies for coding

On 27/08/13 15:30, Gustavo Niemeyer wrote: On Mon, Aug 26, 2013 at 11:50 PM, Tim Penhey tim.pen...@canonical.com wrote: On 27/08/13 14:33, Gustavo Niemeyer wrote: On Mon, Aug 26, 2013 at 8:03 PM, Tim Penhey tim.pen...@canonical.com wrote: Information hiding and abstracting implementation

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 least

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

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

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:

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

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

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

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

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 ian.bo...@canonical.com mailto:ian.bo...@canonical.com 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

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 gust...@niemeyer.net 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

Re: Synchronous Bootstrap

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

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! It is kinda hard to confirm it fully works right now. I need

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

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 cur...@canonical.com 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

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 cur...@canonical.com 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 21 | tee

Re: new dependency

that will show more usage. Tim On Feb 5, 2014 7:29 PM, Martin Packman martin.pack...@canonical.com mailto:martin.pack...@canonical.com wrote: On 04/02/2014, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Docs need a little work. Can you

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

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

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/errgo.

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 possible

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 used to work

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 the

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 the

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 tim.pen...@canonical.com 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. For a long time Go 1.3 beta could not build

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

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

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

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

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

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

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 We

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

On 28/05/14 12:43, Nate Finch wrote: This sounds like one of those if you have to ask this question, you're doing something wrong. Can you give an example of where we need this? Sure... let's say we have a stack of errors, for simplicity of the argument lets say it is a slice of error

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

also change the meaning of cause, so a nil cause means get the cause from the previous (underlying) error. Do you not agree with me though that in the general Go language there should be a way to check identity? Or do you not agree? Tim On May 27, 2014 8:48 PM, Tim Penhey tim.pen

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

On 28/05/14 13:48, Andrew Wilkins wrote: On Wed, May 28, 2014 at 8:47 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: On 28/05/14 12:43, Nate Finch wrote: This sounds like one of those if you have to ask this question, you're doing something

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

On 28/05/14 15:48, John Meinel wrote: I think we need concrete examples which Tim should have in the test suite. John =:- On May 28, 2014 6:50 AM, Andrew Wilkins andrew.wilk...@canonical.com mailto:andrew.wilk...@canonical.com wrote: On Wed, May 28, 2014 at 10:39 AM, John Meinel

Re: The juju devel branch version is WRONG

On 03/06/14 03:14, Curtis Hovey-Canonical wrote: Juju CI is not testing devel branch because it claims to be a version that is released. Juju version cannot be set to 1.19.4 https://bugs.launchpad.net/juju-core/+bug/1325074 1.19.3 is released, but the gobot fails my branch that sets the

  1   2   3   >