Re: Juju 2.0-beta12 ETA

[Cheryl Jennings]

There are no API changes planned for beta12, but if any do come up, they
will be announced on the mailing lists.

On Wed, Jul 6, 2016 at 8:59 PM, Marco Ceppi 
wrote:

> On Wed, Jul 6, 2016 at 3:51 PM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Hi Everyone,
>>
>> Due to the US holidays and with much of the team at core and networking
>> sprints, we will be releasing 2.0-beta12 next week.  There are currently 6
>> assigned critical bugs [0] that need to be addressed for the next beta.
>>
>> This next beta is targeted to replace the out of date beta7 current
>> uploaded into Xenial. We are moving the date out to allow developers time
>> to fix these critical issues and make sure that beta12 is backported into
>> Xenial allowing more users to test and beat on Juju 2.0.
>>
>
> To date, does beta12 introduce any API changes?
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.0-beta12 ETA

[Cheryl Jennings]

Hi Everyone,

Due to the US holidays and with much of the team at core and networking
sprints, we will be releasing 2.0-beta12 next week.  There are currently 6
assigned critical bugs [0] that need to be addressed for the next beta.

This next beta is targeted to replace the out of date beta7 current
uploaded into Xenial. We are moving the date out to allow developers time
to fix these critical issues and make sure that beta12 is backported into
Xenial allowing more users to test and beat on Juju 2.0.

Thanks!
-Cheryl

[0]  https://bugs.launchpad.net/juju-core/+milestone/2.0-beta12
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.0-beta9 ETA

[Cheryl Jennings]

Hi Everyone,

Due to a critical bug [0] found in the daily PPA, the release of 2.0-beta9
will be delayed while we test the fix.  We are aiming for a release
tomorrow.

Thanks!
-Cheryl

[0] https://bugs.launchpad.net/juju-core/+bug/1592210

On Fri, Jun 10, 2016 at 1:20 PM, Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> The team has been busily working on 2.0-beta9 with an aim to address
> usability feedback and ensure that beta9 will be upgradeable to subsequent
> releases.  Ensuring upgradeability has required a significant amount of
> work to finalize internal details, and the team needs a few extra days to
> make sure this work is completed.
>
> To achieve this guarantee, we are moving the expected date for 2.0-beta9
> to Tuesday, June 14.
>
> Some of the great things coming in beta9 include:
> - Renaming of 'service' to 'application' to better align terminology
> - Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
> - Addition of a `juju unregister` command to remove references to
> controllers
> - Separation of controller config vs. model config
> - Improved status output
> - Numerous bug fixes
>
> There is an early beta9 available in the juju daily ppa (ppa:juju/daily)
> for those who wish early access to the above features.
>
> If you have any questions, please let me know.
> Thanks!
> -Cheryl
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.0-beta9 ETA

[Cheryl Jennings]

The team has been busily working on 2.0-beta9 with an aim to address
usability feedback and ensure that beta9 will be upgradeable to subsequent
releases.  Ensuring upgradeability has required a significant amount of
work to finalize internal details, and the team needs a few extra days to
make sure this work is completed.

To achieve this guarantee, we are moving the expected date for 2.0-beta9 to
Tuesday, June 14.

Some of the great things coming in beta9 include:
- Renaming of 'service' to 'application' to better align terminology
- Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
- Addition of a `juju unregister` command to remove references to
controllers
- Separation of controller config vs. model config
- Improved status output
- Numerous bug fixes

There is an early beta9 available in the juju daily ppa (ppa:juju/daily)
for those who wish early access to the above features.

If you have any questions, please let me know.
Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to add machine that uses public/private key based authentication

[Cheryl Jennings]

Hi Phani,

Is the key used for the machine known to juju?  You can view the ssh keys
with `juju authorized-keys list` for juju 1.x, and `juju list-ssh-keys` for
juju 2.0.

If it's not there, you can use the following commands to add the key and
juju will try to use it when connecting to the machine:
juju 1.x:  `juju authorized-keys add`
juju 2.0:  `juju add-ssh-key`

Let me know if this works for you.
Thanks!
-Cheryl

On Sat, May 21, 2016 at 5:18 AM, phani shankar 
wrote:

> Hi,
>
>  I am trying to use add-machine command to add a machine to juju
> environment. The machine being added uses public/private key
> authentication. I am facing following error.
>
> juju add-machine ssh:ubuntu@10.115.0.2
> ERROR subprocess encountered error code 255 (Permission denied
> (publickey).)
>
>
> This works fine when I use the command to add a machine which does
> password based authentication. I understand that it is due to not passing
> the correct key credentials. But I am not sure how I can pass necessary
> credentials. Please advise.
>
> Regards,
> PHANI SHANKAR
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: go test github.com/juju/juju/state takes > 10 minutes to run

[Cheryl Jennings]

Are you using mongo 3.2?  (see bug
https://bugs.launchpad.net/juju-core/+bug/1573294)

On Mon, May 16, 2016 at 9:52 PM, David Cheney 
wrote:

> Testing this package takes 16 minutes on my machine*; it sure didn't
> use to take this long.
>
> What happened ?
>
> * yes, you have to raise the _10 minute_ timeout to make this test run.
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Connecting to the controller database w/mongodb 3.2

[Cheryl Jennings]

The QA team is looking at adding the mongo client into the juju-mongodb3.2
package.  In the meantime, I've been bootstrapping with a trusty controller
if I need to be able to examine the db.

On Fri, May 13, 2016 at 11:17 AM, Horacio Duran  wrote:

> so, for case 1) this link explains how to add the repo
> http://askubuntu.com/questions/724749/install-mongo-3-2-on-ubuntu-15-10
> for 2) following
> https://docs.mongodb.com/manual/reference/connection-string/ should work
>
>
>
> On Fri, May 13, 2016 at 12:57 PM, Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
>> On Fri, May 13, 2016 at 10:52 AM, Horacio Duran <
>> horacio.du...@canonical.com> wrote:
>>
>>> By connect I assume you mean to use the shell, for this you need the
>>> mongodb-org papa and install mongodb-org-shell, I am currently on the phone
>>> but as soon as I get to a computer I'll send you links
>>>
>>>
>> Well, for use case #1, yes, use the shell.
>>
>> For use case #2, I'd be using github.com/dcu/mongodb_exporter, which
>> uses mgo.v2 and just needs a mongodb URI
>> 
>> .
>>
>>
>>> On Friday, 13 May 2016, Casey Marshall 
>>> wrote:
>>>
 I seem to be unable to connect to the Juju 2.0 controller database
 lately. I'm thinking this might be related to the move to mongodb 3.2.

 Can someone in the know please share how to do this? While most users
 should never, ever connect directly to the controller's database, I have
 two good use cases for it:

 1. It's sometimes necessary for debugging the state of a live
 controller.
 2. I'd like to instrument a controller's mongodb with prometheus.io,
 but in order to do this, I need to derive the new connection info.

 Much thanks,
 Casey

>>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Please run go test -race before pushing code

[Cheryl Jennings]

Hey everyone,

There have been some new races showing up in the CI race detector test.  As
you're making your bug fixes, please make sure you run go test -race before
pushing your code up for review to make sure you have not introduced new
races.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Master is blocked - do not JFDI

[Cheryl Jennings]

Hey guys,

In the transition to go 1.6 everywhere, we have found a number of failures
in our unit tests on Windows and CentOS with go 1.6.  We had been using go
1.2 in our unit tests for those platforms, but have decided to make the go
1.6 unit tests voting and eliminate the go 1.2 unit tests.

This means those failure need to get fixed before we can do a release.

Please do not use JFDI to get around master being blocked.  You can use the
$$fixes-$$ notation to merge fixes for blocking bugs.

Please let me know if you have any questions.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Command rename: create-model -> add-model

[Cheryl Jennings]

Copying juju list.

On Tue, Apr 26, 2016 at 5:15 PM, Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> Hi Everyone,
>
> Just a heads up that I'm merging a PR to rename the create-model command
> to add-model to be more consistent in our terminology.
>
> The next 2.0 release will contain this rename, and those of you building
> from master will need to use add-model once the PR lands.
>
> Thanks!
> -Cheryl
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Command rename: create-model -> add-model

[Cheryl Jennings]

Hi Everyone,

Just a heads up that I'm merging a PR to rename the create-model command to
add-model to be more consistent in our terminology.

The next 2.0 release will contain this rename, and those of you building
from master will need to use add-model once the PR lands.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Master is blocked in preparation for 2.0-beta4

[Cheryl Jennings]

Hi Everyone,

Master is currently blocked to allow us to get to a stable 2.0-beta4.
While we are working towards that goal, please do not JFDI changes into
master.  We are aiming to have a release tomorrow or Wednesday, so this
window should be short.

Please let me know if you have questions or concerns.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Thunderbirds are Go 1.6

[Cheryl Jennings]

Thank you for all your work on this, Curtis!

On Sun, Apr 10, 2016 at 11:55 AM, Curtis Hovey-Canonical <
cur...@canonical.com> wrote:

> Ladies and Gentlemen, We build with Go 1.6 everywhere.
>
> Take a moment to consider the implications, because that means we do
> not use Go 1.2, 1.3, or 1.5. Juju 1.x and 2.x for Windows, OS X, and
> Linux (precise, trusty, wily, xenial, and centos7) are built with Go 1.6.
>
> There was concern about how to support precise if the code grew 1.2
> incompatibilities. Michael Hudson-Doyle's fabulous package was trivial
> to backport to precise. We don't need to create a new process to support
> precise. The golang-1.6 packages was also easy to copy to wily. since
> the Go 1.5 unit tests are less reliable than the Go 1.6 unit tests, the
> hour spent setting up wily to build with golang-1.6 will pay for itself
> in a day.
>
> Some unit tests combinations are still using Go 1.2 because the tests
> assume OS features because of the Golang version instead of checking
> the OS:
>
> 1. The Makefile rules for installing deps are very stale. Precise unit
> tests will fail when forced to use Go 1.6 because they cannot
> start mongo:
> error command line: unknown option sslOnNormalPorts
> But we see that actual deployments of precise built with Go 1.6 work.
>
> 2. Centos and Windows unit test are still Go 1.2 because many lxd
> related tests fail when run with Go 1.6.
>
> The git-merge-juju job is using the xenial daily image to gate merges.
> The released image it too stale to do an unattended dist-upgrade
>
> The unit test runs for xenial-amd64, xenial-arm64, xenial-s390x,
> xenial-ppc64el, wily-amd64, trusty-amd64, trusty-i386, and
> trusty-ppc64el will use the golang (1.6) or golang-1.6 (1.6) packages.
> The go1.2 trusty unit tests amd64, arm64, i386, and ppc64el are gone.
>
> Ubuntu source packages prefer the golang-1.6 package, and fallback to
> golang (>= 1.2). We needed a new builder because Go 1.6 needs more
> memory. We saw errors like this with 2G of memory
> golang-1.6/pkg/tool/linux_amd64/link: running gcc failed:
> fork/exec /usr/bin/gcc: cannot allocate memory
> Centos is created using the same Go package as trusty. Windows is
> cross compiled as 64 bit for agent and 32 bit for clients. OS X is
> natively compiled using Go 1.6 on CI's OS X host.
>
> We also got word is was safe to upgrade our arm64 host to xenial. This
> is done. The ppc64el hosts were also upgraded this week. We are
> expanding tests for arm64 and ppc64el
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Cheryl Jennings]

Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426

Maybe kill-controller tries to destroy through the API, but has a time out
if things get "stuck" where it will fall back to the provider.  I was
joking when I suggested yesterday in IRC that we should bring back --force
for kill-controller, but maybe we need it (or at least a timeout).

On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch  wrote:

> Oh I see.  Yes, I agree that we should always try the right way first and
> only use the provider if necessary (especially if using the provider leaves
> garbage around).
>
> It seems like there's no reason why we couldn't make a --force flag do it
> that way in 2.0 (aside from time constraints).
>
> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 2016-04-06 10:45 AM, Nate Finch wrote:
>> > Wait, didn't destroy-environment --force fall back to the provider?
>> > I thought that was the whole point of --force
>>
>> No, it didn't fall back.  It uses the provider unconditionally,
>> without trying a normal destroy-controller first.
>>
>> Aaron
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
>> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
>> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
>> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
>> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
>> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
>> =vm/H
>> -END PGP SIGNATURE-
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Cheryl Jennings]

Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059

We should provide a way to clean up controllers without making the user
manually edit juju's files.

On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch  wrote:

> This just happened to me, too.  Kill-controller needs to work if at all
> possible.  That's the whole point.  And yes, users may not hit specific
> problems, but devs do, and that wastes our time trying to figure out how to
> manually clean up the garbage.
>
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
> wrote:
>
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> In a non-beta release we would make sure that the config changes aren't
>>> backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
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.6 is now in trusty-proposed

[Cheryl Jennings]

These intermittently failing unit tests are often due to unreliable unit
tests, rather than problems in the code.  As nice as it would be to not
have to retry tests (particularly unit tests), I'd much rather we spend our
precious resources on fixing bugs that are causing pain for our users.

There are currently 168 Triaged bugs targeted against 2.0-beta4 [0], many
of which have been reported by actual users and have been deferred release
after release.  For comparison, there are 18 go 1.5 /1.6 bugs found by CI.

Thanks,
-Cheryl

[0] https://launchpad.net/juju-core/+milestone/2.0-beta4

On Mon, Mar 28, 2016 at 9:08 AM, Nate Finch 
wrote:

> +1, don't retry... devs need to feel the pain in order to get proper
> motivation to fix this stuff...
>
> On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>> Just wanted to say thank you 100x to all involved!
>>
>> On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
>> > Hi,
>> >
>> > As of a few minutes ago, there is now a golang-1.6 package in
>> > trusty-proposed:
>> > https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the
>> > review and copy, Steve).
>> >
>> > One difference between this and the package I prepared earlier is that
>> > it does not install /usr/bin/go but rather /usr/lib/go-1.6/bin/go so
>> > Makefiles and such will need to be adjusted to invoke that directly or
>> > put /usr/lib/go-1.6/bin on $PATH or whatever. (This also means it can
>> > be installed alongside the golang packages that are already in
>> > trusty).
>> >
>> > Cheers,
>> > mwh
>> > (Hoping that we can now really properly ignore gccgo-4.9 ppc64el bugs!)
>> >
>> > On 17 February 2016 at 07:58, Michael Hudson-Doyle
>> >  wrote:
>> >> I have approval for the idea but also decided to wait for 1.6 and
>> upload
>> >> that instead. I'm also on leave currently so hopefully this can all
>> happen
>> >> in early March.
>> >>
>> >> Cheers,
>> >> mwh
>> >>
>> >> On 17/02/2016 1:17 am, "John Meinel"  wrote:
>> >>> To start with, thanks for working on this. However, doesn't this also
>> >>> require changing the CI builds to use your ppa?
>> >>>
>> >>> What is the current state of this? I was just looking around and
>> noticed
>> >>> golang1.5-go isn't in anything specific for Trusty that I can see. I
>> realize
>> >>> if its going into an SRU it requires a fair amount of negotiation
>> with other
>> >>> teams, so I'm not  surprised to see it take a while. I just wanted to
>> check
>> >>> how it was going.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> John
>> >>> =:->
>> >>>
>> >>> On Mon, Jan 18, 2016 at 7:32 AM, Michael Hudson-Doyle
>> >>>  wrote:
>>  Hi all,
>> 
>>  As part of the plan for getting Go 1.5 into trusty (see here
>>  https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty) I've built
>>  packages (called golang1.5-go rather than golang-go) for trusty in my
>>  ppa:
>> 
>> 
>> https://launchpad.net/~mwhudson/+archive/ubuntu/go15-trusty/+packages
>> 
>>  (assuming 3:1.5.3-0ubuntu4 actually builds... I seem to be having a
>>  "make stupid packaging mistakes" day)
>> 
>>  I'll write up a SRU bug to start the process of getting this into
>>  trusty tomorrow but before it does end up in trusty it would seem
>> like
>>  a good idea to run the CI tests using juju-core packages built with
>>  this version of the go compiler. Is that something that's feasible to
>>  arrange
>> 
>>  The only packaging requirement should be to change the build-depends
>>  to be on golang1.5-go rather than golang-go or gccgo.
>> 
>>  Cheers,
>>  mwh
>> 
>>  --
>>  Juju-dev mailing list
>>  Juju-dev@lists.ubuntu.com
>>  Modify settings or unsubscribe at:
>>  https://lists.ubuntu.com/mailman/listinfo/juju-dev
>> >>>
>>
>> --
>> -
>> Katherine
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
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.6 is now in trusty-proposed

[Cheryl Jennings]

Addressing flaky tests is definitely a long term goal we should have.

Given that we are aiming for beta4 next week, I'd rather our energies in
the short term are directed at fixing stakeholder bugs than fixing
intermittent failures that prevent us from releasing because we are no
longer retrying tests.

On Mon, Mar 28, 2016 at 10:27 AM, Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> While agreeing with the spirit of your email, Cheryl, I'd like to opine
> that in the long-term fixing flaky tests will improve the code and help to
> fix (and prevent!) bugs.
>
> Put another way, flaky tests are indirectly causing pain for our users.
>
>
> On 03/28/2016 10:24 AM, Cheryl Jennings wrote:
>
> These intermittently failing unit tests are often due to unreliable unit
> tests, rather than problems in the code.  As nice as it would be to not
> have to retry tests (particularly unit tests), I'd much rather we spend our
> precious resources on fixing bugs that are causing pain for our users.
>
> There are currently 168 Triaged bugs targeted against 2.0-beta4 [0], many
> of which have been reported by actual users and have been deferred release
> after release.  For comparison, there are 18 go 1.5 /1.6 bugs found by CI.
>
> Thanks,
> -Cheryl
>
> [0] https://launchpad.net/juju-core/+milestone/2.0-beta4
>
> On Mon, Mar 28, 2016 at 9:08 AM, Nate Finch 
> wrote:
>
>> +1, don't retry... devs need to feel the pain in order to get proper
>> motivation to fix this stuff...
>>
>> On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday <
>> katherine.cox-bu...@canonical.com> wrote:
>>
>>> Just wanted to say thank you 100x to all involved!
>>>
>>> On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
>>> > Hi,
>>> >
>>> > As of a few minutes ago, there is now a golang-1.6 package in
>>> > trusty-proposed:
>>> > https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the
>>> > review and copy, Steve).
>>> >
>>> > One difference between this and the package I prepared earlier is that
>>> > it does not install /usr/bin/go but rather /usr/lib/go-1.6/bin/go so
>>> > Makefiles and such will need to be adjusted to invoke that directly or
>>> > put /usr/lib/go-1.6/bin on $PATH or whatever. (This also means it can
>>> > be installed alongside the golang packages that are already in
>>> > trusty).
>>> >
>>> > Cheers,
>>> > mwh
>>> > (Hoping that we can now really properly ignore gccgo-4.9 ppc64el bugs!)
>>> >
>>> > On 17 February 2016 at 07:58, Michael Hudson-Doyle
>>> >  wrote:
>>> >> I have approval for the idea but also decided to wait for 1.6 and
>>> upload
>>> >> that instead. I'm also on leave currently so hopefully this can all
>>> happen
>>> >> in early March.
>>> >>
>>> >> Cheers,
>>> >> mwh
>>> >>
>>> >> On 17/02/2016 1:17 am, "John Meinel" < 
>>> j...@arbash-meinel.com> wrote:
>>> >>> To start with, thanks for working on this. However, doesn't this also
>>> >>> require changing the CI builds to use your ppa?
>>> >>>
>>> >>> What is the current state of this? I was just looking around and
>>> noticed
>>> >>> golang1.5-go isn't in anything specific for Trusty that I can see. I
>>> realize
>>> >>> if its going into an SRU it requires a fair amount of negotiation
>>> with other
>>> >>> teams, so I'm not  surprised to see it take a while. I just wanted
>>> to check
>>> >>> how it was going.
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> John
>>> >>> =:->
>>> >>>
>>> >>> On Mon, Jan 18, 2016 at 7:32 AM, Michael Hudson-Doyle
>>> >>>  wrote:
>>> >>>> Hi all,
>>> >>>>
>>> >>>> As part of the plan for getting Go 1.5 into trusty (see here
>>> >>>> https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15InTrusty) I've built
>>> >>>> packages (called golang1.5-go rather than golang-go) for trusty in
>>> my
>>> >>>> ppa:
>>> >>>>
>>> >>>>
>>> https://launchpad.net/~mwhudson/+archive/ubuntu/go15-trusty/+packages
>>> <https://l

Merge master for your feature branches

[Cheryl Jennings]

Hi everyone,

The admin-controller-model branch which merged into master yesterday
brought the new behavior of two models being created upon bootstrap -
"admin" and "default".  Significant changes were needed in CI to support
this new behavior.

You will need to merge master into your feature branches to pick up this
change, or CI will not pass on your branch.

Please let me know if you have any questions.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Master is blocked in preparation for 2.0-beta3

[Cheryl Jennings]

Hi Everyone,

Master is currently blocked to allow us to get to a stable 2.0-beta3.
While we are working towards that goal, please do not JFDI changes into
master.

Please let me know if you have questions or concerns.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Preparing for the next beta - CI runs on feature branches

[Cheryl Jennings]

Hey Everyone!

The cutoff for the next beta is just around the corner (Monday, March 21)!
In order to meet this cutoff, please pay attention to the CI reports [0] on
your branches and address failures on your branch when they arise.

To avoid wasting CI test time on branches with known errors, we will be
introducing a way to skip CI runs for those feature branches.  If your
branch has a unique failure, or has not pulled in an updated master
containing fixes for known CI bugs, a bug will be opened against your
branch with the "block-ci-testing" tag[1].  Branches with
"block-ci-testing" bugs in a non-Fix Committed state will not be run
through CI.

For example, master is currently blocked because of bug #1558158[2].  Once
that bug is fixed, your branch will not be tested until you pull in an
updated version of master which contains that fix.  Feature branches
without pre-existing "block-ci-testing" bugs are being tested until that
bug is marked as Fix Released.

Once you have brought in the latest master, and / or addressed the
unique-to-your-branch bug, set the "block-ci-testing" bug against your
branch to Fix Committed to signal that your branch is ready for CI testing.

Please let me know if you have any questions.
Thanks!
-Cheryl

[0] http://reports.vapour.ws/releases
[1] https://bugs.launchpad.net/juju-core/+bugs/?field.tag=block-ci-testing
[2] https://bugs.launchpad.net/juju-core/+bug/1558158
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.0-beta2 update

[Cheryl Jennings]

The Juju Core team is working towards a stable release of 2.0-beta2, but
will need to delay the release due to some issues that arose in the last
two weeks.  The outstanding issues are:

[0] 1549545 - Bundle deploys fail at lxc-start when bridge br-eth1 is
created
Found in CI; proposed fix is being tested.

[1] 1551854 - LXD bootstrap issues on xenial
Observed outside of Juju; investigations ongoing.  Workaround included in
bug.

[2] 1551842 / 1552423 - Machines getting 127.0.0.1 for DNS / PUBLIC_ADDRESS
Currently being investigated.

The team is also incorporating user feedback from beta1 to help improve the
Juju 2.0 experience.  We are aiming to release 2.0-beta2 next week.  Please
let me know if you have any comments or questions.

Thanks!
-Cheryl

[0] https://bugs.launchpad.net/juju-core/+bug/1549545
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551854
[2] https://bugs.launchpad.net/juju-core/+bug/1551842
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Master is unblocked (for now)

[Cheryl Jennings]

Hi Everyone,

Given the decision that we are releasing alpha2 next week instead of a
separate alpha3, I have unblocked master so that people can get some
changes in before the next alpha stabilization period.

Please merge your bug fixes / blessed feature branches into master before
18:00 UTC on Monday.  People wanting to merge into master after that time
will need to coordinate with me and the QA / Release team.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju 2.0-alpha2

[Cheryl Jennings]

Hi Everyone,

In preparing for Juju 2.0-alpha2, CI caught a race condition exposed by
some of the new feature code to support 2.0. Because of this, we are going
to move 2.0-alpha2 out to next week to allow time to fix the race.
Features that were targeted to 2.0-alpha3, planned for next week, will be
included in the 2.0-alpha2 release instead.

Please let me know if you have any questions.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

API / command renames coming for 2.0-alpha2

[Cheryl Jennings]

Hi Everyone,

There will soon be a feature branch landing that changes internal names,
message strings and commands to use the new model / controller
terminology.  Significant CI changes were made to support this rename.

Once this branch lands, you will need to merge master into your feature
branches to pick up these changes, or CI will no longer pass on your
branches.

The branch is called api-command-rename, if you'd like to examine the
branch early.

Please let me know if you have any questions.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Build errors

[Cheryl Jennings]

Neale,  make sure you check out the section on godeps.  I've run into
errors like yours before I ran that command.

Thanks!
-Cheryl

On Mon, Feb 1, 2016 at 4:15 PM, Neale Ferguson  wrote:

> The “Getting Started” part of that document says that the:
>  go get -d -v github.com/juju/juju/...
> command needs to be run. This is the command which is giving me the
> Azure-related error.
>
> Neale
>
>
> Juju is not structured to work with go get, per se.  Please see the
> contributing document for details on building juju:
>
> https://github.com/juju/juju/blob/master/CONTRIBUTING.md
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Master is unblocked

[Cheryl Jennings]

Hi Everyone,

Yesterday we had a blessed CI run on master which we will be releasing as
our 2.0-alpha1.  The final touches will be put on the release notes and we
will turn the crank to get an official release shortly.

In the meantime, I've unblocked master.  So, let the thundering herd of
merges begin!

Thanks again for your patience while we worked towards a stable 2.0-alpha1!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 1.26-alpha3 moving to 2.0-alpha1

[Cheryl Jennings]

Hi Everyone,

While we are still moving towards a 2.0 release, not all of the CLI /
behavior changes that will occur in Juju 2.0 are ready for an alpha
release.  To allow consumers to test new functionality in a timely manner,
we will be releasing a new development version called 1.26-alpha3.  This
release will contain:
- The new Rackspace Provider
- Support for CentOS and Windows images in streams
- Improved local charm deployment
- Support for Multi Series Charms

The next development release will be in mid-January and will be named
2.0-alpha1.  It will contain additional new features, and CLI / behavior
changes such as:
- Moving to a flat namespace for commands (for example, juju user add will
be juju add-user)
- Multi-environment (soon to be Multi-Model) support active by default

The 2.0-alpha1 release will be accompanied by a listing of CLI and behavior
changes, so that users may adjust any scripts / automation around Juju.

Thanks!
-Cheryl

On Fri, Dec 4, 2015 at 1:06 PM, Alexis Bruemmer <
alexis.bruem...@canonical.com> wrote:

> Hi All,
>
> Juju 2.0 has been a long time coming and we will see it release in April
> 2016 with Ubuntu 16.04!  Among many other improvements, the 2.0 release
> will have a better bootstrap experience that leverages all the great work
> done around multi-model solutions.  Juju 2.0 bootstrapping will
> automatically create a controller (previously known as a Juju State Server)
> with a hosted model (previously known as an environment); the new behavior
> automatically provides the user with a usable model and a clear path for
> adding more models to the bootstrapped controller.  This improvement
> however, changes the expected functionality of the current 1.X bootstrap
> command.  Our commitment to Juju users on LTS releases states clearly that
> we do not break backwards compatibility on point releases (including
> changing base expected behavior).  For this reason we will be dropping
> the 1.26.0 release and turning the current 1.26-alpha3 into 2.0-alpha1.
>
>
> This is an update to our current release plans (
> https://github.com/juju/juju/wiki/Juju-Release-Schedule) which has a
> 1.26.0 release scheduled for January.  Although this means waiting a little
> longer for features, moving to a 2.0 enables the development team to
> deliver a strong and correct 2.0 user experience.  The Juju team will
> continue to release alphas and betas on a regular cadence so that new
> features will be available in the devel ppa (ppa:juju/devel).  The first
> 2.0-alpha1 is scheduled to release the week of December 7th.
>
> If you have any questions please do not hesitate to ask.
>
> Thanks!
> Alexis
>
> --
> Alexis Bruemmer
> Juju Core Manager, Canonical Ltd.
> (503) 686-5018
> alexis.bruem...@canonical.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 1.26-alpha3 moving to 2.0-alpha1

[Cheryl Jennings]

>
>
> Is there a feature mapping to what's landing in each Alpha?
>
> We will be working on that list next week when the core team has their
sprint.  Once it is complete, I will send it out to the juju list.

Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feature Request: -about-to-depart hook

[Cheryl Jennings]

I'll be tracking these kind of feature requests here:
https://github.com/juju/juju/wiki/Feature-Requests

There's not much there yet, but we'll be filling it out as we go through
the other various requests we've gotten.

Thanks!
-Cheryl

On Mon, Nov 23, 2015 at 6:13 PM, Rick Harding 
wrote:

> Thank you Cheryl!
>
> On Mon, Nov 23, 2015, 6:33 PM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> This is already on my list.  I'm still figuring out a good way to
>> organize / record these in a publicly viewable place.
>>
>> I'll send out a link once I get something together.  (Hopefully tonight!)
>>
>> Thanks!
>>
>>
>> -Cheryl
>> On Nov 23, 2015 5:20 PM, "Rick Harding" 
>> wrote:
>>
>>> Thanks for the feedback. I think this is something we should try to make
>>> some time for. I've copied Alexis and we'll see what can be done with the
>>> team.
>>>
>>> Alexis, can you put this on the list of things to investigate for future
>>> roadmap?
>>>
>>> Thanks
>>>
>>> On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo <
>>> mario.spliv...@canonical.com> wrote:
>>>
>>>> On 02/12/2015 07:41 PM, Jorge Niedbalski wrote:
>>>> >> While typing up https://bugs.launchpad.net/juju-core/+bug/1417874 I
>>>> >> realized that your proposed solution of a pre-departure hook is the
>>>> >> only one that can work. Once -departed hooks start firing both the
>>>> >> doomed unit and the leader have already lost the access needed to
>>>> >> decommission the departing node.
>>>> >
>>>> > I have been struggling the last hours with the same exact issue trying
>>>> > to add replication to memcached.
>>>> >
>>>> > The problem is that there is no a point on which i can identify
>>>> > what's the exact departing unit?
>>>> >
>>>> > And this leads to manual operator intervention, which is _highly_ non
>>>> > desirable for a juju deployed environment.
>>>> >
>>>> > +1 for having this feature implemented.
>>>>
>>>> Hola!
>>>>
>>>> I'm bumping this thread to get some chatter going on - we hit a similar
>>>> issue with percona-cluster charm, which is reported in this bug:
>>>>
>>>> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472
>>>>
>>>> The issue is somewhat similar as to those with mongodb - when unit is
>>>> leaving relation (issued by 'juju remove-unit'), charm should first shut
>>>> down percona server on the departing unit. Failing to do results in
>>>> 'lost quorum' situation where remaining node thinks that network has
>>>> partitioned. Unfortunately there is now way for a relation's -departed
>>>> hook to know if it's executing on departing unit or on the other one so
>>>> it can't know weather or not to stop percona server. Implementing a
>>>> -about-to-depart hook would solve this issue.
>>>>
>>>> Mario
>>>>
>>>>
>>>> --
>>>> Juju-dev mailing list
>>>> Juju-dev@lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feature Request: -about-to-depart hook

[Cheryl Jennings]

This is already on my list.  I'm still figuring out a good way to organize
/ record these in a publicly viewable place.

I'll send out a link once I get something together.  (Hopefully tonight!)

Thanks!
-Cheryl
On Nov 23, 2015 5:20 PM, "Rick Harding"  wrote:

> Thanks for the feedback. I think this is something we should try to make
> some time for. I've copied Alexis and we'll see what can be done with the
> team.
>
> Alexis, can you put this on the list of things to investigate for future
> roadmap?
>
> Thanks
>
> On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo <
> mario.spliv...@canonical.com> wrote:
>
>> On 02/12/2015 07:41 PM, Jorge Niedbalski wrote:
>> >> While typing up https://bugs.launchpad.net/juju-core/+bug/1417874 I
>> >> realized that your proposed solution of a pre-departure hook is the
>> >> only one that can work. Once -departed hooks start firing both the
>> >> doomed unit and the leader have already lost the access needed to
>> >> decommission the departing node.
>> >
>> > I have been struggling the last hours with the same exact issue trying
>> > to add replication to memcached.
>> >
>> > The problem is that there is no a point on which i can identify
>> > what's the exact departing unit?
>> >
>> > And this leads to manual operator intervention, which is _highly_ non
>> > desirable for a juju deployed environment.
>> >
>> > +1 for having this feature implemented.
>>
>> Hola!
>>
>> I'm bumping this thread to get some chatter going on - we hit a similar
>> issue with percona-cluster charm, which is reported in this bug:
>>
>> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1514472
>>
>> The issue is somewhat similar as to those with mongodb - when unit is
>> leaving relation (issued by 'juju remove-unit'), charm should first shut
>> down percona server on the departing unit. Failing to do results in
>> 'lost quorum' situation where remaining node thinks that network has
>> partitioned. Unfortunately there is now way for a relation's -departed
>> hook to know if it's executing on departing unit or on the other one so
>> it can't know weather or not to stop percona server. Implementing a
>> -about-to-depart hook would solve this issue.
>>
>> Mario
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Cut-off for 1.25.1 Release - This Thursday

[Cheryl Jennings]

Hi Everyone,

The cut-off for changes going into 1.25.1 will be this Thursday, Nov 19th
at 18:00 UTC.  Any changes that aren't Fix Committed by then will be
deferred to 1.25.2.

We hope to have a 1.25.1 release next week, depending on test results.

Please let me know if you have any questions.
Thanks!
-Cheryl
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev