Re: AZs and placement

On 16/12/2016, Brent Clements wrote: > This is great info. > > I apologize for my ignorance but what would that, as placement for each > unit, look like in a bundle? For each application, it can look something like this: an-application: charm: ./a-charm

AZs and placement

There have been a couple of reports of Juju struggling with availability zones recently. This isn't new code, it was introduced in 1.20, but with 2.0 it appears that we're not surfacing errors from improper zone selection[1], which is a particular issue when we also seem to not be selecting a

Using juju ssh from windows clients

Looking at juju ssh session from windows client bug: The core issue is simple. We pass stdin straight over the ssh connection, without coping with it being a windows text stream. So lines are terminated with '\r\n' rather than just '\n', which

New functional-endpoint-bindings tests are non-voting

The new functional-endpoint-bindings tests on maas 2.0 and 2.1 are non-voting while they gather a few runs and and the test environment is tweaked. Includes

New functional-ssh-keys test is non-voting

The new functional-ssh-keys test is non-voting while it gathers a few runs and awaits a branch landing. The test was written as part of fixing lp:1555727 as we lacked functional test coverage for the key management in juju, and with some

Uniter test failure from utils update

Nicholas was struggling today to land his snapcraft pull request: As a side effect this updates some dependencies, including a couple of changes to juju/utils, which it turns out, causes UniterSuite.TestRebootFromJujuRun to fail. Here's a run of master,

Juju stable 1.25.6 is released

# juju-core 1.25.6 A stable release of Juju, juju-core 1.25.6, is now available. This release replaces version 1.25.5. ## Getting Juju juju-core 1.25.6 is available for Xenial and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Windows,

Juju stable 1.25.6 is released

# juju-core 1.25.6 A stable release of Juju, juju-core 1.25.6, is now available. This release replaces version 1.25.5. ## Getting Juju juju-core 1.25.6 is available for Xenial and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Windows,

Juju stable 1.25.6 is proposed for release

# juju-core 1.25.6 A new proposed stable release of Juju, juju-core 1.25.6, is now available. This release may replace version 1.25.5 on Thursday July 21. ## Getting Juju juju-core 1.25.6 is available for Xenial and backported to earlier series in the following PPA:

Juju stable 1.25.6 is proposed for release

# juju-core 1.25.6 A new proposed stable release of Juju, juju-core 1.25.6, is now available. This release may replace version 1.25.5 on Thursday July 21. ## Getting Juju juju-core 1.25.6 is available for Xenial and backported to earlier series in the following PPA:

Juju plugins should start juju-

Landing in the next beta of Juju 2.0, plugins will not only have to start 'juju-' but the next character must be [a-zA-Z]. For details see: If you've written your own juju plugin, make sure it's named something that starts with a letter rather

Re: The mean time for a CI run has risen to 33 minutes

On 16/05/2016, David Cheney wrote: > This got significantly worse in the last 6 weeks. What happened ? Either the juju tests are slower, or trusty on aws is slower. It's a fresh cloud instance each run, and still trusty because we switched to xenial and the lxd tests

MAAS 2.0 in CI

CI now has revision testing for MAAS 2.0 provider support, though master does not yet bootstrap successfully in our environment. End of last week start of this, Curtis and I updated finfolk and its hosted 1.9 vmaas to xenial, and maas 2.0 (with some small adventures along the way). Today I also

Re: LXD polish for xenial

On 18/04/2016, Tycho Andersen wrote: >> >> Unlike other providers, lxd exposes no way to use the daily images >> instead of release images, so at present any machine using lxd >> containers with juju for the first time will get the xenial beta2 >> image then upgrade

Re: LXD polish for xenial

On 18/04/2016, Martin Packman <martin.pack...@canonical.com> wrote: > > "autopkgtest lxd provider tests fail for 2.0" > <https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1571082> > > So, at present we don't have confidence that the LXD provi

LXD polish for xenial

With the LXD 2.0 release at the start of last week and the prospect of some stability, I spent a good chunk of the week testing of Juju and LXD. What CI has been doing so far this cycle has been running our standard deployment tests with the lxd provider on a pre-prepared machine with a

Re: New juju in ubuntu

On 06/04/2016, Stuart Bishop wrote: > > How do our plugins know what version of juju is in play? Can they > assume that the 'juju' binary found on the path is the juju that > invoked the plugin, or is there some other way to tell using > environment variables or such?

Re: New juju in ubuntu

On 05/04/2016, Adam Collard wrote: > Will there be a transitional release of 1.25.x that also gives us a juju1 > binary to facilitate this? Yes, the plan entails both an update to the juju in main for the 2.0 release and a new juju 1.25 in universe that cooperates

New juju in ubuntu

Some of you will be aware of the excitement over the last week getting Juju 2.0 into Xenial, this is an update mail so everyone knows what the goal is with the user experience. The challenge here is we want Juju 2.0 and all the new functionality to be the default on release, but not break our

Re: New feature for charmers - min-juju-version

On 23/03/2016, Ryan Beisner wrote: > > To summarize: > If we do nothing with regard to juju 1.25.x or the various tools, and if a > relevant charm grows a series list in metadata, a load of existing > validation and demo bundles will no longer be deployable with 1.25.x

Re: Go 1.6 is now in trusty-proposed

On 27/03/2016, David Cheney wrote: > Hi Martin, > > I was told that the Go 1.6 tests were voting, so these bugs should be > blocking bugs. Is this not the case ? The tests are voting, and giving blesses, so no blocking bugs, but a lot of the remaining issues are

Re: Go 1.6 is now in trusty-proposed

On 24/03/2016, Ian Booth wrote: > > Not yet. The builders and test infrastructure all need to be updated, and > the package needs a week to transition out of proposed. I'd also encourage people to look again at the go 1.5/1.6 unit test intermittent failures, as we're

armhfentures

There is a bug filed over Juju 2.0 not building with go 1.2 on armhf: I believe I understand all the moving parts here, but it's a little fiddly and we're going to have to make a choice about how we plan to build 2.0, so wanted some input. The

Re: LXD and trusty-backports

On 20/01/2016, John Meinel wrote: > So according to https://help.ubuntu.com/community/UbuntuBackports backports > is enabled by default, as long as you explicitly request the packages from > backports. Yeah, that's the case for fresh machines, backports just has a lower

Re: Automatic retries of hooks

Another common error we see in CI is apt mirrors being unhappy leading to hook failures. Just retry later does tend to be the right option there, though it will often be an our or two until the archive is in a usable state again. On 20/01/2016, William Reade wrote: >

Re: Juju-CI revision testing paused

On 24/12/2015, John George wrote: > As no one will be monitoring resources or test results over the holiday > break, Juju-CI has been paused. Anything landed will be tested when the > system is re-enabled on January 4th. I reenabled CI this morning, and revision

Starting a new CI test

I just added a cheaty way of getting started on a new CI test. $ make new-assess name=new_feature With 'new_feature' as the name you want for your test. This generates a new test script, and some unit tests to go along with it, which you can run as normal with: $ make test p=*new_feature* The

gomaasapi moved to github

The gomaasapi project has been moved from launchpad to the juju organisation on github: As part of this, the project is using the standard juju gating, so add the magic string $$merge$$ to a github comment after review to merge. Martin -- Juju-dev mailing

Re: Upgrading minimum Go version?

On 26/11/2015, David Cheney wrote: > Martin: Can you setup a unit test job that uses Go 1.5 ? I will apply > the same process I did for the -race job, to get the build voting, > then reenable the tests that were skipped. We've had that since near the start of the wily

Re: juju bootstrap fails with vSphere 6.0

On 05/11/2015, Forstner Michael wrote: > > Response 4 (Invalid XML; attaching Hex view): > 1f 8b 08 Aha, that's just gzip encoded. Once decoded, the response looks sane: http://paste.debian.net/325311 So, need the http headers as well. If the vSphere server

Re: Juju 1.24.7 is proposed for stable release

On 16/10/2015, Casey Marshall wrote: > I just upgraded to 1.24.7 and tried bootstrapping, got this message: > > Starting new instance for initial state server > WARNING failed to find 1.24.7 tools, will attempt to use 1.24.6 Did you remember to set `agent-stream:

Re: User creation with cloud-init

Have run the branch through CI twice. Fixed the issues that showed up first time so second run is blessed. It did mean reverting to the old way of setting keys on precise specifically, as the cloud-init we have there is too old to support 'users' configuration. What's left before this can land is

User creation with cloud-init

I proposed a branch this week that alters how juju uses cloud-init to create the ubuntu user when provisioning a machine. I've had code review, but would appreciate further feedback: The main aim here is to avoid depending on the /etc/cloud/cloud.cfg in the

Re: Running upgrade steps for units

On 16/09/2015, Tim Penhey wrote: > > When is the 1.24.6 release? We've been trying to release for a while, currently cursed by the following bug with failing to deploy the landscape bundle: This seems to be a

Juju devel 1.25-alpha1 is released

# juju-core 1.25-alpha1 A new development release of Juju, juju-core 1.25-alpha1, is now available. ## Getting Juju juju-core 1.25-alpha1 is available for Wily and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Windows, Centos, and OS X

Juju devel 1.25-alpha1 is released

# juju-core 1.25-alpha1 A new development release of Juju, juju-core 1.25-alpha1, is now available. ## Getting Juju juju-core 1.25-alpha1 is available for Wily and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Windows, Centos, and OS X

Re: Uniter tests for update-status hook - BLOCKER

On 20/07/2015, Tim Penhey tim.pen...@canonical.com wrote: Earlier today I was investigating this CRITICAL BLOCKER bug: https://bugs.launchpad.net/juju-core/+bug/1475724 At first I thought that bug was referring to a different one, which I fixed by skipping a part of a test that was

Re: Uniter tests for update-status hook - BLOCKER

On 20/07/2015, Martin Packman martin.pack...@canonical.com wrote: So, I'm not sure what bugs we want to file to track the work to get master in a good state. As best as I can work out we have: Okay, becoming clearer now, 1) Windows regression from uniter-status change: http

Dreamhost progress

Andrew landed a change on master to allow the Openstack provider to track state servers using metadata on the instances rather than object-store. This should fix the bug I raised[0] but for one small extra change needed, and gets us onto the next problem bootstrapping with Dreamhost. To try out

Re: Blocking bugs process

On 13/07/2015, Nate Finch nate.fi...@canonical.com wrote: Can you put this in the wiki? Done, with Aaron's addition: https://github.com/juju/juju/wiki/Blocking-bugs -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Blocking bugs process

Thank you for responding Ian. On 13/07/2015, Ian Booth ian.bo...@canonical.com wrote: == Definition of blocking bugs == Master and all release branches should always be in a releasable state. If a bug must be fixed for the next minor release, it is considered a ‘blocker’ and will prevent all

Re: Keystone error

You may have more luck asking on the new 'openstack-charmers' list as this sounds more like an issue with how to use those rather with juju in general: https://lists.ubuntu.com/mailman/listinfo/openstack-charmers On 17/06/2015, dinesh.senap...@wipro.com dinesh.senap...@wipro.com wrote: The part

Re: like go test, but faster

On 15/06/2015, Nate Finch nate.fi...@canonical.com wrote: Russ Cox has an experimental command called gt, which replaces the go test tool, and caches test output when you run it. The next time you run gt, if none of the files in a package have changed and none of the files of packages it

Re: Rackspace deployment without os-security-groups support.

On 11/06/2015, Mark Hannessen m.hannes...@youwe.nl wrote: Looking on the internet i found the setting firewall-mode which had a promising description for working around this. https://jujucharms.com/docs/devel/config-general Unfortunately firewall-mode won't help. We still create the global

Re: REMINDER: run tests with -race before submitting for review

On 10/06/2015, Tim Penhey tim.pen...@canonical.com wrote: So... for the tests that you are writing for the code you are changing, please run these tests with the race flag. This should at least help us not introduce new races. I've linked up the race detection CI job to our outcome analyser:

Rule #2 should die

Currently juju-reports has a rule matching on failures where our CI harness interrupted the test because it took too long: http://reports.vapour.ws/releases/rules/2 This seems too generic a symptom, generally if a test is not completing within the time we've allocated for it, there's another

Re: Getting back to t1.micros

On 14/05/2015, José Antonio Rey j...@ubuntu.com wrote: * When I set the same constraints at bootstrap, it just gives me an error saying it uses a different HDD type. Could we at least get that fixed? There's now a pull request up that fixes the virt type of t2 instances:

Re: Resolving the same windows test failures again

On 05/05/2015, Andrew Wilkins andrew.wilk...@canonical.com wrote: Those fixes were not made on v5, and only existed on v6-unstable. I later came along and merged some changes into v5 and updated Juju's dependencies.tsv to the latest commit on v5. That meant the fixes were dropped. Not easy

Resolving the same windows test failures again

There was some confusion about the regression to the windows test failures on trunk. https://bugs.launchpad.net/juju-core/+bug/1450919 Partly my fault, Curtis initially looked at the 1.24 branch and I looked at trunk, and each branch has a different issue. Here's what I've just done to diagnose.

Do not land code on blocked branches

It has been great that everyone has been diving in and tackling the backlog of bugs over the last week. However, please only merge pull requests that are actually fixing bugs blocking that branch. In particular, the JFDI instruction to the lander is an escape hatch to allow for merging in

Re: Running Juju in Google compute engine

On 01/05/2015, Eric Snow eric.s...@canonical.com wrote: We have info in the release notes [1], but looks like we have a gap in the docs (I'll follow up on that). Also, it looks like the release notes did not get updated with the auth-file config option that Andrew mentioned. So, Jorge and I

Re: Test suite on windows now voting on trunk

On 23/04/2015, Martin Packman martin.pack...@canonical.com wrote: Well, mostly good news after Matty and I landed workarounds. There's a single remaining failure that has manifested since: TestLeadership fails on windows test slave https://bugs.launchpad.net/juju-core/+bug/1447595

Re: Public Service Annoucement

On 24/04/2015, David Cheney david.che...@canonical.com wrote: Why doesn't the bot run this hook ? It does - but there are two problems: 1) For the gating job to reject the change, the script just has not return non-zero. Seems `go tool vet` returns 0 even if it reports issues. So,

Re: Public Service Annoucement

On 24/04/2015, roger peppe roger.pe...@canonical.com wrote: Are you sure? It seems to return a non-zero exit status for me. I guess you're not using ubuntu packaged go, but something trunkier? I guess it (and the other point) might be a consequence of running a different version of govet. $

Re: Test suite on windows now voting on trunk

Well, mostly good news after Matty and I landed workarounds. There's a single remaining failure that has manifested since: TestLeadership fails on windows test slave https://bugs.launchpad.net/juju-core/+bug/1447595 On 22/04/2015, John Meinel j...@arbash-meinel.com wrote: That sounds like it

Re: 'ERROR juju.cmd supercommand.go:430 no instances found' when bootstrapping Juju on OpenStack Juno

On 23/04/2015, Robert Day robert@metaswitch.com wrote: Martin, Mark, Thank you! That was indeed the problem - once I'd changed that entry to an IP address (and fixed a couple of similar problems with my metadata files not being accessible, where the error messages were much easier to

Re: Vivid init system bug status

On 17/04/2015, Martin Packman martin.pack...@canonical.com wrote: I have put up a merge proposal making the error handling robust across go versions, and removing the map interation confusion: https://github.com/juju/juju/pull/2094 This should be on the 1.23 branch shortly. Well

Re: 'ERROR juju.cmd supercommand.go:430 no instances found' when bootstrapping Juju on OpenStack Juno

On 16/04/2015, Robert Day robert@metaswitch.com wrote: I'm trying to set up Juju on my private OpenStack Juno cloud, but 'juju bootstrap' is consistently failing with 'ERROR juju.cmd supercommand.go:430 no instances found'. My juju-core package version is 1.22.1-0ubuntu1~12.04.1~juju1.

Test suite on windows now voting on trunk

Last week we resolved a bunch of issues with the test suite, flipped the switch so it will now mark trunk builds with windows test failures as not suitable for releasing. There are three groups of failures in the latest run that still need addressing:

Re: Vivid init system bug status

On 17/04/2015, John Meinel j...@arbash-meinel.com wrote: Do you know what version of Go you're using in your custom builds? The go compiler version was the key, our CI and Oleg are using 1.3.3 on vivid. Frustrating, this issue is in large part to vivid tests not being reliable enough to gate

Vivid init system bug status

Update on where we're at with the local provider init system breakage on vivid. Oleg reported the following bug againsts 1.23: https://bugs.launchpad.net/juju-core/+bug/1443440 Short version, juju sometimes fails when trying to operate on the mongo service, during either bootstrap or

Re: Merge gating for more juju subprojects

On 25/03/2015, Rick Harding rick.hard...@canonical.com wrote: If you're using the github lander make sure the user has made it's org membership public. Thanks Rick, that was is. Thought I'd marked the bot's membership of go-goose at public previously, but had not. Martin -- Juju-dev mailing

Re: Merge gating for more juju subprojects

On 13/03/2015, Martin Packman martin.pack...@canonical.com wrote: That said, if there are any packages you think we should *not* gate landings on their test suite passing yet, please say now. With the lack of objections, I've gone ahead and made the more active projects in the juju namespace

Re: Merge gating for more juju subprojects

On 24/03/2015, Andrew Wilkins andrew.wilk...@canonical.com wrote: Katherine just tried to $$merge$$ a go-goose branch, and it looks like the script is broken: https://github.com/go-goose/goose/pull/3 Tests passed, but merge failed. Ian merged manually. Hmm, would have been nice to send it

Merge gating for more juju subprojects

I've put up a gating job for goose on our jenkins slave for juju: http://juju-ci.vapour.ws/job/github-merge-goose/ It will likely need some more work, but I fake-landed Katherine's proposed branch and it passed. The switch over steps are disabling direct landing for most/all contributers and

Re: Trivial bugs hurting progress

On 04/03/2015, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hi all, Ian asked me to mail the list about a couple of bugs that managed to get past the bot; first so that we can all be mindful of these sorts of bugs, and second to highlight the fact that they could have been caught by the

Reports artifact links added

I have deployed code on juju-reports that directly links all build artifacts from the test detail page. For instance see one of the recent runs: http://reports.vapour.ws/releases/2312 In the Last build column darker shading indicates you can hover the cell to reveal more links, which can

Linker error on gccgo/ppc64 in test

Landings were blocked today by a bug [1381671] where a recently landed test file was failing to build on the ppc64 slave. As far as I can see, there's nothing obviously broken, and the package follows the same basic layout as its api/ siblings. So, for now, I've skipped building this file to

Landing job uses pre-push script

The landing job for juju now uses the pre-push script from the juju branch before running tests. This means it's running go vet over the source, and I've fixed a couple of errors on master. What it doesn't do currently is fail the landing if vet reports issues, as the script doesn't fail in this

juju/charm master has changed

Earlier I changed the revision that the master branch of the github.com/juju/charm project refers to. In practical terms, I hope this should not matter to anyone, as the vN branches are the actively developed ones under the new versioning scheme. If there is any issue, please let me know. The

Re: Lag for unblocking CI

On 01/09/2014, Matthew Williams matthew.willi...@canonical.com wrote: Thanks Martin, yeah things have come up since it tried to land, I'll try again later today and let you know if there are any problems Your workaround of making a new pull request was fine. Underlying issue is the github

Re: Lag for unblocking CI

On 01/09/2014, John Meinel j...@arbash-meinel.com wrote: Is there some amount of caching going on somewhere? (I also noticed it took 7minutes for the bot to notice a $$merge$$ request, so maybe it does the check somehow asynchronously to processing the requests?) Maybe it was something timing

Re: CI tests are installing Juju on the CI machine ...

On 01/08/2014, David Cheney david.che...@canonical.com wrote: Creating config file /etc/mercurial/hgrc.d/hgext.rc with new version Setting up zip (3.0-4) ... Setting up juju-core (1.20.1-0ubuntu1~12.04.1~juju1) ... update-alternatives: using /usr/lib/juju-1.20.1/bin/juju to provide

Re: Possible landing bot issues

On 31/07/2014, David Cheney david.che...@canonical.com wrote: 1. the bot doesn't appear to NACK changes that are not gofmt'd, this means changes land which others cannot fix because their .gitconfig prevents them. I've proposed a change to the build script to reject non-gofmt-happy changes:

Landing changes for juju subprojects

I'm switching our various subprojects in the juju namespace on github over to having landings gated by jenkins jobs that run their test suites. For most of us this should be pretty easy to deal with, the 'Merge pull request' button will go away on the webpage as projects get switched. When it

Re: New flakey juju tests

On 10/07/2014, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: I'll take a look at both of these, since I approved the first and landed the second. Sorry about the flakiness :/ Thanks Dimiter! Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe

New flakey juju tests

We've done a lot of work recently improving the reliability of our test suite. Unfortunately, feature work has been introducing new tests that are intermittently failing. http://juju-ci.vapour.ws:8080/job/github-merge-juju/1/console FAIL: machine_test.go:1750: MachineSuite.TestWatchInterfaces

Landing bot job changed

I have switched the jenkins landing bot to a new job, as part of the work on getting it faster and more reliable. If you want to check back on old results, they are preserved for now under a different job name: http://juju-ci.vapour.ws:8080/job/github-merge-juju-old/ I'm actually having second

Re: How to show diff for a rev?

On 18/06/2014, John Meinel j...@arbash-meinel.com wrote: So the only syntax that reliably gives me what I want is: git dif 348c104^ 348c104 I was hoping there would be a better shortcut for it. Does anyone have some more voodoo that I could use to avoid having to type the same thing twice?

Re: naming repos on github

On 06/06/2014, Nate Finch nate.fi...@canonical.com wrote: As for ditching go get... yes and no (mostly no). go get is not really intended for use in contributing to an external project. It's a download and install this application. If anything, we should be making our code *more* happy

Membership changes on github

I have changed our memberships on teams under the github juju organisation, to limit commit access to the juju branch to the landing bot. Sorry for the extra email kipple from this. Everyone is now a member of @juju/hackers and everyone except team leads have been removed from owners. Branches

Switch to github beginning

I am going to stop the tarmac landing bot now and begin the process of switching our juju repository from launchpad to github. Note that any branches currently proposed will need their changes imported into a new git branch in order to land, this can be done once the git master is up and branched

Juju is on github

Juju development is now done on github: https://github.com/juju/juju See the updated CONTRIBUTING doc for the basics. To land code you want the magic string $$merge$$ in a comment on the pull request so the jenkins bot picks it up. Note that the bot is currently taking around three times as

utils/ssh updates

I've poked utils/ssh a bit during gophercon. Unfortuately the update to use tip of go.crypto can't land right now as it requires a couple of standard library crypto bits that go 1.1.2 lacks. Perhaps we can talk about bumping the requirement for building trunk juju-core to go 1.2 and adding that

Pending fix for bug 1310258

I put up a branch to fix one of our 1.19.1 blocking bugs earlier today: APIHostPorts returns 'localhost' and '127.0.0.1' https://bugs.launchpad.net/juju-core/+bug/1310258 https://codereview.appspot.com/90310043/ As I'm on a plane for most of tomorrow, feel free to mark approved to land if it

Re: [Canonical-juju-qa] Cursed (final): #1173 lp:juju-core r2511 (manual-deploy)

On 31/03/2014, Curtis Hovey-Canonical cur...@canonical.com wrote: Aaron will capture some logs of what is wrong and investigate issues with CI. Can someone investigate Juju? Juju 1.18.0 will be based on r2510 if this bug is not fixed in time. Looking at the diff of r2511 I'm pretty doubtful

Landing bot alive again

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 remotely by setting juju service config now.

Landing bot back online

Our landing bot is operational again after the canonistack lcy02 maintenance earlier today. There were quite a few hitches along the way, some of which are probably attributable to the fact we're still running an ancient juju 1.11.0 in that environment. First up the state server came up without

Re: new dependency

On 04/02/2014, Tim Penhey tim.pen...@canonical.com wrote: Docs need a little work. Can you give us an inspirational example of an error message made clearer at least? I know Roger has hacked on something along these lines in the past, I'm curious to hear his thoughts on your stab at tracebacks

Re: Juju 1.17.1 milestone

On 21/01/2014, Curtis Hovey-Canonical cur...@canonical.com wrote: I believe milestone 1.17.1 has about 4 weeks of issues targeted to it. https://launchpad.net/juju-core/+milestone/1.17.1 I have retargetted all bugs that are not actually landed or about to land on trunk against the new

Re: How to get private-address in juju status output?

On 27/11/2013, Andreas Hasenack andr...@canonical.com wrote: Hi, I have an instance on openstack (canonistack) that got a floating ip, and that address is now showing as public-address. I guess that's ok. As discussed on IRC, this is the expected behaviour, though with the limited details