Re: Juju 2.0 is here!

[Tim Penhey]

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 joy to train people on it. Well done.

Mark

On 14/10/16 06:34, Nicholas Skaggs wrote:

Juju 2.0 is here! This release has been a year in the making. We’d
like to thank everyone for their feedback, testing, and adoption of
juju 2.0 throughout its development process! Juju brings refinements
in ease of use, while adding support for new clouds and features.

## New to juju 2?

https://jujucharms.com/docs/2.0/getting-started

## Need to install it?

If you are running Ubuntu, you can get it from the juju stable ppa:

sudo add-apt-repository ppa:juju/stable
sudo apt update; sudo apt install juju-2.0

Or install it from the snap store

snap install juju --beta --devmode

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0.0

## Want to upgrade to GA?

Those of you running an RC version of juju 2 can upgrade to this
release by running:

juju upgrade-juju

## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
j...@lists.ubuntu.com and join us on #juju on freenode. We would love
to hear
your feedback and usage of juju.







--
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 is here!

[Mark Shuttleworth]

Congrats everyone, this is a release to be proud of. Multi-user
multi-model, great CLI, it's a joy to train people on it. Well done.

Mark

On 14/10/16 06:34, Nicholas Skaggs wrote:
> Juju 2.0 is here! This release has been a year in the making. We’d
> like to thank everyone for their feedback, testing, and adoption of
> juju 2.0 throughout its development process! Juju brings refinements
> in ease of use, while adding support for new clouds and features.
>
> ## New to juju 2?
>
> https://jujucharms.com/docs/2.0/getting-started
>
> ## Need to install it?
>
> If you are running Ubuntu, you can get it from the juju stable ppa:
>
> sudo add-apt-repository ppa:juju/stable
> sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0.0
>
> ## Want to upgrade to GA?
>
> Those of you running an RC version of juju 2 can upgrade to this
> release by running:
>
> juju upgrade-juju
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> j...@lists.ubuntu.com and join us on #juju on freenode. We would love
> to hear
> your feedback and usage of juju.
>
>


-- 
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 is here!

[Alexis Bruemmer]

WOOT!

On Thu, Oct 13, 2016 at 9:34 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Juju 2.0 is here! This release has been a year in the making. We’d like to
> thank everyone for their feedback, testing, and adoption of juju 2.0
> throughout its development process! Juju brings refinements in ease of use,
> while adding support for new clouds and features.
>
> ## New to juju 2?
>
> https://jujucharms.com/docs/2.0/getting-started
>
> ## Need to install it?
>
> If you are running Ubuntu, you can get it from the juju stable ppa:
>
> sudo add-apt-repository ppa:juju/stable
> sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0.0
>
> ## Want to upgrade to GA?
>
> Those of you running an RC version of juju 2 can upgrade to this release
> by running:
>
> juju upgrade-juju
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>



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

Juju 2.0 is here!

[Nicholas Skaggs]

Juju 2.0 is here! This release has been a year in the making. We’d like 
to thank everyone for their feedback, testing, and adoption of juju 2.0 
throughout its development process! Juju brings refinements in ease of 
use, while adding support for new clouds and features.


## New to juju 2?

https://jujucharms.com/docs/2.0/getting-started

## Need to install it?

If you are running Ubuntu, you can get it from the juju stable ppa:

sudo add-apt-repository ppa:juju/stable
sudo apt update; sudo apt install juju-2.0

Or install it from the snap store

snap install juju --beta --devmode

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0.0

## Want to upgrade to GA?

Those of you running an RC version of juju 2 can upgrade to this release 
by running:


juju upgrade-juju

## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
j...@lists.ubuntu.com and join us on #juju on freenode. We would love to 
hear

your feedback and usage of juju.


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

Re: Github Reviews vs Reviewboard

[Tim Penhey]

-1, like Menno I was initially quite hopeful for the github reviews.

My main concerns are around easily having a list to pull from, and being 
able to see status, comments on a single dashboard.


Tim

On 14/10/16 11:44, Menno Smits wrote:

We've been trialling Github Reviews for some time now and it's time to
decide whether we stick with it or go back to Reviewboard.

We're going to have a vote. If you have an opinion on the issue please
reply to this email with a +1, 0 or -1, optionally followed by any
further thoughts.

  * +1 means you prefer Github Reviews
  * -1 means you prefer Reviewboard
  * 0 means you don't mind.

If you don't mind which review system we use there's no need to reply
unless you want to voice some opinions.

The voting period starts *now* and ends my*EOD next Friday (October 21)*.

As a refresher, here are the concerns raised for each option.

*Github Reviews*

  * Comments disrupt the flow of the code and can't be minimised,
hindering readability.
  * Comments can't be marked as done making it hard to see what's still
to be taken care of.
  * There's no way to distinguish between a problem and a comment.
  * There's no summary of issues raised. You need to scroll through the
often busy discussion page.
  * There's no indication of which PRs have been reviewed from the pull
request index page nor is it possible to see which PRs have been
approved or otherwise.
  * It's hard to see when a review has been updated.

*Reviewboard*

  * Another piece of infrastructure for us to maintain
  * Higher barrier to entry for newcomers and outside contributors
  * Occasionally misses Github pull requests (likely a problem with our
integration so is fixable)
  * Poor handling of deleted and renamed files
  * Falls over with very large diffs
  * 1990's looks :)
  * May make future integration of tools which work with Github into our
process more difficult (e.g. static analysis or automated review tools)

There has been talk of evaluating other review tools such as Gerrit and
that may still happen. For now, let's decide between the two options we
have recent experience with.

- Menno




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

Re: Github Reviews vs Reviewboard

[Menno Smits]

-1

I was really excited by Github Reviews initially but after using it for a
while I've switched my position.

On 14 October 2016 at 11:44, Menno Smits  wrote:

> We've been trialling Github Reviews for some time now and it's time to
> decide whether we stick with it or go back to Reviewboard.
>
> We're going to have a vote. If you have an opinion on the issue please
> reply to this email with a +1, 0 or -1, optionally followed by any further
> thoughts.
>
>- +1 means you prefer Github Reviews
>- -1 means you prefer Reviewboard
>- 0 means you don't mind.
>
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
>
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
>
> As a refresher, here are the concerns raised for each option.
>
> *Github Reviews*
>
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still
>to be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
>
> *Reviewboard*
>
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
>
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
>
> - Menno
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Github Reviews vs Reviewboard

[Ian Booth]

-1000 :-)

On 14/10/16 08:44, Menno Smits wrote:
> We've been trialling Github Reviews for some time now and it's time to
> decide whether we stick with it or go back to Reviewboard.
> 
> We're going to have a vote. If you have an opinion on the issue please
> reply to this email with a +1, 0 or -1, optionally followed by any further
> thoughts.
> 
>- +1 means you prefer Github Reviews
>- -1 means you prefer Reviewboard
>- 0 means you don't mind.
> 
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
> 
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
> 
> As a refresher, here are the concerns raised for each option.
> 
> *Github Reviews*
> 
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still to
>be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
> 
> *Reviewboard*
> 
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
> 
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
> 
> - Menno
> 
> 
> 

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

Github Reviews vs Reviewboard

[Menno Smits]

We've been trialling Github Reviews for some time now and it's time to
decide whether we stick with it or go back to Reviewboard.

We're going to have a vote. If you have an opinion on the issue please
reply to this email with a +1, 0 or -1, optionally followed by any further
thoughts.

   - +1 means you prefer Github Reviews
   - -1 means you prefer Reviewboard
   - 0 means you don't mind.

If you don't mind which review system we use there's no need to reply
unless you want to voice some opinions.

The voting period starts *now* and ends my* EOD next Friday (October 21)*.

As a refresher, here are the concerns raised for each option.

*Github Reviews*

   - Comments disrupt the flow of the code and can't be minimised,
   hindering readability.
   - Comments can't be marked as done making it hard to see what's still to
   be taken care of.
   - There's no way to distinguish between a problem and a comment.
   - There's no summary of issues raised. You need to scroll through the
   often busy discussion page.
   - There's no indication of which PRs have been reviewed from the pull
   request index page nor is it possible to see which PRs have been approved
   or otherwise.
   - It's hard to see when a review has been updated.

*Reviewboard*

   - Another piece of infrastructure for us to maintain
   - Higher barrier to entry for newcomers and outside contributors
   - Occasionally misses Github pull requests (likely a problem with our
   integration so is fixable)
   - Poor handling of deleted and renamed files
   - Falls over with very large diffs
   - 1990's looks :)
   - May make future integration of tools which work with Github into our
   process more difficult (e.g. static analysis or automated review tools)

There has been talk of evaluating other review tools such as Gerrit and
that may still happen. For now, let's decide between the two options we
have recent experience with.

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

Re: upcoming change in Juju 2.0 to bootstrap arguments

[Jason Hobbs]

Thanks for the heads up Ian - we will adjust our scripts to accomodate.

Jason

On Thu, Oct 13, 2016 at 12:36 AM, Ian Booth  wrote:

> See https://bugs.launchpad.net/juju/+bug/1632919
>
> The order of the cloud/region and controller name arguments will be
> swapped.
>
> Old:
>
> $ juju bootstrap mycontroller aws/us-east-1
>
> New:
>
> $ juju bootstrap aws/us-east-1 mycontroller
> or now
> $ juju bootstrap aws/us-east-1
>
> Notice how controller name is optional. It will default to cloud-region.
> eg
>
> $ juju bootstrap aws
> Creating Juju controller "aws-us-east-1" on aws/us-east-1
> ...
>
> The only fallout I expect will be for folks like OIL who use scripts will
> have
> to tweak their scripts to swap the arguments. The bootstrap API itself is
> unaffected so Python client and other API users will see no difference.
> It's
> just a CLI change.
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fwd: Big memory usage improvements

[Christian Muirhead]

Oops, meant to reply-all.

-- Forwarded message -
From: Christian Muirhead 
Date: Thu, 13 Oct 2016, 09:26
Subject: Re: Big memory usage improvements
To: Katherine Cox-Buday 




On Wed, 12 Oct 2016, 22:36 Katherine Cox-Buday, <
katherine.cox-bu...@canonical.com> wrote:

Awesome, good work, Christian!


:)
Thanks for your help with the StatePool!


Not to detract from this fantastic news, but it's still worrisome that an
idle Juju seems to have a memory which is growing linearly (before picture
looked like the beginning of an exponential curve?). Do we feel this is
memory which will at some point be GCed?


No, I think there's still a leak there. The other ones I fixed were
goroutine leaks which were a bit easier to track down. There aren't any
goroutines escaping now so I'll need to switch back to looking at heap
dumps to find more.

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

Re: Big memory usage improvements

[Christian Muirhead]

On Wed, 12 Oct 2016, 21:39 Menno Smits,  wrote:

> Interestingly the MongoDB memory usage profile is quite different as well.
> I'm not sure if this is due to Christian's improvements or something else.
>

Thanks Menno! One of the fixes was a state.State instance being leaked when
the model was destroyed, and that held a Mongo session open which would've
held memory in the mongod process as well.

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

Re: Big memory usage improvements

[Danilo Šegan]

Indeed, this is amazing stuff: good job, it's great to see so
significant improvements!
I can't help but wonder about the bootstrap time: it goes up by 75s
(from 114s to 189s, or ~66% increase)? Do you perhaps have multiple
runs comparing just the bootstrap times to ensure it's related more to
the environment state (hardware, network, load) than changes in the
code? Is there any explanation for the difference in the number of
deployments done and models created in roughly the same time (46/946 vs
52/1092, 13/15% decrease)?
It might still be a trade-off worth accepting, and even if it'd be even
better with no trade-offs, it's fine as long as we know about it and
make sure that we evaluate the value/cost proposition for each case.
Cheers,
Danilo
У чет, 13. 10 2016. у 09:39 +1300, Menno Smits пише:
> Christian (babbageclunk) has been busy fixing various memory leaks in
> the Juju controllers and has made some significant improvements.
> Chris (veebers) has been tracking resource usage for a long running
> test which adds and removes a bunch of models and he noticed the
> difference.
> 
> Take a look at the memory usage graphs here:
> 
> Before: http://people.canonical.com/~leecj2/perfscalemem/
> After: http://people.canonical.com/~leecj2/perfscalemem2/
> 
> Interestingly the MongoDB memory usage profile is quite different as
> well. I'm not sure if this is due to Christian's improvements or
> something else.
> 
> There's possibly still some more small leaks somewhere but this is
> fantastic regardless. Thanks to Christian for tackling this and Chris
> for tracking the numbers.
> 
> - Menno
> 
> 
> -- 
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l
> istinfo/juju-dev-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev