Re: Juju 2.0 is here!

2016-10-14 Thread Chance Ellis 
Congratulations to the Juju team for a great release! It has been a lot of fun 
watching this come together!



On 10/14/16, 12:34 AM, "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
juju@lists.ubuntu.com and join us on #juju on freenode. We would love to 
hear
your feedback and usage of juju.


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




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

Re: Juju 2.0 is here!

2016-10-14 Thread Andrew Wilkins 
On Fri, 14 Oct 2016, 12:34 p.m. 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.


What an epic release! I for one am proud of what we've created together.
Great work everyone.

## 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
juju@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-...@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0 is here!

2016-10-14 Thread Andrew Wilkins 
On Fri, 14 Oct 2016, 12:34 p.m. 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.


What an epic release! I for one am proud of what we've created together.
Great work everyone.

## 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
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

[ANN] Kubernetes core bundle

2016-10-14 Thread Matt Bruzek 
10/14 Release Notes

The container team at Canonical has released more Kubernetes goodies for
people to use and deploy on the public clouds. If you have seen the email
from Charles Butler you may already know we have been working on adding new
operations and improving the Canonical Distribution of Kubernetes (CDK).
That cluster requires 11 machines which can get expensive if you were
interested in evaluating Kubernetes on your favorite public cloud. So we
created a smaller “hyper converged” Juju bundle that uses LXD to create a
Kubernetes cluster with only two machines!

We call this one Kubernetes core and it is available at:
https://jujucharms.com/kubernetes-core/

Since this bundle reuses the same charms you get many of the same
operations in the core cluster just with less machines.

This is a work in progress so if you find any bugs with this Juju bundle
please create issues here:
https://github.com/juju-solutions/bundle-kubernetes-core/issues

If you have questions, you can find us on irc in #juju on chat.freenode.net.
My nickname is mbruzek.

Kubernetes Core Bundle

A minimal Kubernetes cluster, only deploying the bare minimum required to
evaluate Kubernetes. Useful when doing Kubernetes development in resource
constrained environments.


   -

   The kubernetes-core bundle has been updated with our latest release of
   the Canonical Distribution of Kubernetes (CDK) charms.
   -

   Brand new README imported from the CDK bundle.
   -

   Updated tests


This bundle is the fastest and cheapest way to get started with Kubernetes.
It does not have all the bells and whistles of our Canonical Distribution
of Kubernetes but you can always deploy that bundle if you need more
monitoring and log aggregation. https://jujucharms.com/canonical-kubernetes/

We are interested in your feedback on the cluster and how you are using
Kubernetes. If you want to contact me, please reply directly to this email,
or find me on slack or irc as “mbruzek”. Remember to file bugs or issues at
our github repository:
https://github.com/juju-solutions/bundle-kubernetes-core/issues

Thanks!

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

Re: Github Reviews vs Reviewboard

2016-10-14 Thread Casey Marshall 
+1, as I work on many other Github projects besides Juju and it's familiar.
It's not perfect by any means but I can work with it.

I thought the ReviewBoard we had was pretty ugly and buggy, but it was
reasonably easy to use. Gerrit is cleaner and clearer to me -- though I
feel like Gerrit is also kind of rough on the uninitiated. Maybe if a newer
version of RB was sufficiently improved and it was charmed up well, its
operation would be more manageable, and it'd be OK?

-Casey

On Fri, Oct 14, 2016 at 12:34 PM, Andrew McDermott <
andrew.mcderm...@canonical.com> wrote:

>
> On 14 October 2016 at 16:26, Mick Gregg  wrote:
>
>> I would probably chose gerrit over either, but that's not the question
>> today.
>>
>
> Oooh, yes to gerrit. +2
>
>
>
> --
> Andrew McDermott 
> Juju Core Sapphire team 
>
> --
> 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: Github Reviews vs Reviewboard

2016-10-14 Thread Andrew McDermott 
On 14 October 2016 at 16:26, Mick Gregg  wrote:

> I would probably chose gerrit over either, but that's not the question
> today.
>

Oooh, yes to gerrit. +2



-- 
Andrew McDermott 
Juju Core Sapphire team 
-- 
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

2016-10-14 Thread Reed O'Brien 
+1

I expect there will be updates and improvements to GH reviews over time.
e.g. the 'show notes' checkbox to hide the notes when looking at the
changes. I don't recall seeing that last week. I think gitlab's funding and
cadence if putting pressure on GH to improve their UI and feature set.

They are just tools. Neither is perfect, but I find GH to be less
problematic and less bumpy in my general work flow. I've lost work in RB
more than a few times, which is not an experience I've had with GH. I find
the diffs in RB inscrutable at times and have had go to look a them in GH.

I'd be happy to try gerrit. I haven't used it, but everyone I've spoken
with who has reported a positive experience. I'd also be happy to try
gitlab, but that is another, enormous, can of worms.



On Thu, Oct 13, 2016 at 3:59 PM, Ian Booth  wrote:

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



-- 
Reed O'Brien
✉ reed.obr...@canonical.com
✆ 415-562-6797
-- 
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

2016-10-14 Thread Mick Gregg 
+1 Perhaps I'm too new to understand what rb truly offers, but one less
tool has been noticeably better for me, and I haven't felt any pain in
gh.

I would probably chose gerrit over either, but that's not the question
today.

On Fri, Oct 14, 2016 at 12:10:56PM -0300, Horacio Duran wrote:
> +1 to Github, I prefer the papercuts of githubs to the swordcuts from
> reviewboard.
> 
> On Fri, Oct 14, 2016 at 12:09 PM, Dimiter Naydenov <
> dimiter.nayde...@canonical.com> wrote:
> 
> > +1, Nate said what I was thinking :)
> >
> > On 10/14/2016 05:34 PM, Nate Finch wrote:
> > > +1
> > >
> > > Keeping the PR and reviews together really makes it easier for me to
> > > keep track of what's going on with a PR.  It's also really nice not
> > > having to context switch out of github for every single PR.
> > >
> > > Reviewboard and related infrastructure breaks like once couple weeks,
> > > and I'm not convinced it'll get better, since we've been using it for
> > > quite some time now.
> > >
> > > I have missed exactly zero of the features of reviewboard since using
> > > github, and haven't really cared about the drawbacks of github.
> > >
> > > One point - you *can* minimize comments in the files view - there's a
> > > checkbox per file that will hide the comments in that file.
> > >
> > > On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > > > wrote:
> > >
> > > On 14 October 2016 at 12:45, Adam Collard
> > > >
> > wrote:
> > > > Not sure I get a vote, but -1
> > > >
> > > > You're running an old version of ReviewBoard (2.0.12 released in
> > > January
> > > > 2015) and many of the issues I think you've been hitting are fixed
> > > in later
> > > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> > > development and
> > > > brings a chunk of new UI improvements.
> > > >
> > > > Release notes for 2.5
> > > >
> > > > 3.0 demo site
> > >
> > > I'm still not convinced.
> > >
> > > Even 3.0 still deletes draft comments without so much as a
> > by-your-leave
> > > when you double-click somewhere else in the text. And because it
> > > doesn't use
> > > real text entry boxes, the Lazarus plugin, my usual saviour in such
> > > cases,
> > > doesn't work. I've lost far too much time to this in the past.
> > >
> > > Replying to a comment still involves a page reload and associated
> > > lost context.
> > >
> > > I can't see anything in the 2.5 release notes about fixing behaviour
> > > on file
> > > move/rename, though I may well have missed it.
> > >
> > > And not being able to deal with really large PRs is a definite issue
> > > too (not
> > > that github is better there).
> > >
> > >   cheers,
> > > rog.
> > >
> > > --
> > > Juju-dev mailing list
> > > Juju-dev@lists.ubuntu.com 
> > > Modify settings or unsubscribe at:
> > > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > >
> > >
> > >
> >
> >
> > --
> > Dimiter Naydenov 
> > Juju Core Sapphire team 
> >
> >
> > --
> > 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: Github Reviews vs Reviewboard

2016-10-14 Thread Dimiter Naydenov 
+1, Nate said what I was thinking :)

On 10/14/2016 05:34 PM, Nate Finch wrote:
> +1
> 
> Keeping the PR and reviews together really makes it easier for me to
> keep track of what's going on with a PR.  It's also really nice not
> having to context switch out of github for every single PR.
> 
> Reviewboard and related infrastructure breaks like once couple weeks,
> and I'm not convinced it'll get better, since we've been using it for
> quite some time now.
> 
> I have missed exactly zero of the features of reviewboard since using
> github, and haven't really cared about the drawbacks of github.
> 
> One point - you *can* minimize comments in the files view - there's a
> checkbox per file that will hide the comments in that file.
> 
> On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > wrote:
> 
> On 14 October 2016 at 12:45, Adam Collard
> > wrote:
> > Not sure I get a vote, but -1
> >
> > You're running an old version of ReviewBoard (2.0.12 released in
> January
> > 2015) and many of the issues I think you've been hitting are fixed
> in later
> > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> development and
> > brings a chunk of new UI improvements.
> >
> > Release notes for 2.5
> >
> > 3.0 demo site
> 
> I'm still not convinced.
> 
> Even 3.0 still deletes draft comments without so much as a by-your-leave
> when you double-click somewhere else in the text. And because it
> doesn't use
> real text entry boxes, the Lazarus plugin, my usual saviour in such
> cases,
> doesn't work. I've lost far too much time to this in the past.
> 
> Replying to a comment still involves a page reload and associated
> lost context.
> 
> I can't see anything in the 2.5 release notes about fixing behaviour
> on file
> move/rename, though I may well have missed it.
> 
> And not being able to deal with really large PRs is a definite issue
> too (not
> that github is better there).
> 
>   cheers,
> rog.
> 
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 


-- 
Dimiter Naydenov 
Juju Core Sapphire team 



signature.asc
Description: OpenPGP digital signature
-- 
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

2016-10-14 Thread Horacio Duran 
+1 to Github, I prefer the papercuts of githubs to the swordcuts from
reviewboard.

On Fri, Oct 14, 2016 at 12:09 PM, Dimiter Naydenov <
dimiter.nayde...@canonical.com> wrote:

> +1, Nate said what I was thinking :)
>
> On 10/14/2016 05:34 PM, Nate Finch wrote:
> > +1
> >
> > Keeping the PR and reviews together really makes it easier for me to
> > keep track of what's going on with a PR.  It's also really nice not
> > having to context switch out of github for every single PR.
> >
> > Reviewboard and related infrastructure breaks like once couple weeks,
> > and I'm not convinced it'll get better, since we've been using it for
> > quite some time now.
> >
> > I have missed exactly zero of the features of reviewboard since using
> > github, and haven't really cared about the drawbacks of github.
> >
> > One point - you *can* minimize comments in the files view - there's a
> > checkbox per file that will hide the comments in that file.
> >
> > On Fri, Oct 14, 2016 at 8:22 AM roger peppe  > > wrote:
> >
> > On 14 October 2016 at 12:45, Adam Collard
> > >
> wrote:
> > > Not sure I get a vote, but -1
> > >
> > > You're running an old version of ReviewBoard (2.0.12 released in
> > January
> > > 2015) and many of the issues I think you've been hitting are fixed
> > in later
> > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active
> > development and
> > > brings a chunk of new UI improvements.
> > >
> > > Release notes for 2.5
> > >
> > > 3.0 demo site
> >
> > I'm still not convinced.
> >
> > Even 3.0 still deletes draft comments without so much as a
> by-your-leave
> > when you double-click somewhere else in the text. And because it
> > doesn't use
> > real text entry boxes, the Lazarus plugin, my usual saviour in such
> > cases,
> > doesn't work. I've lost far too much time to this in the past.
> >
> > Replying to a comment still involves a page reload and associated
> > lost context.
> >
> > I can't see anything in the 2.5 release notes about fixing behaviour
> > on file
> > move/rename, though I may well have missed it.
> >
> > And not being able to deal with really large PRs is a definite issue
> > too (not
> > that github is better there).
> >
> >   cheers,
> > rog.
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com 
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
>
>
> --
> Dimiter Naydenov 
> Juju Core Sapphire team 
>
>
> --
> 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: Github Reviews vs Reviewboard

2016-10-14 Thread roger peppe 
[from canonical email address this time]

On 14 October 2016 at 12:45, Adam Collard  wrote:
> Not sure I get a vote, but -1
>
> You're running an old version of ReviewBoard (2.0.12 released in January
> 2015) and many of the issues I think you've been hitting are fixed in later
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site

I'm still not convinced.

Even 3.0 still deletes draft comments without so much as a by-your-leave
when you double-click somewhere else in the text. And because it doesn't use
real text entry boxes, the Lazarus plugin, my usual saviour in such cases,
doesn't work. I've lost far too much time to this in the past.

Replying to a comment still involves a page reload and associated lost context.

I can't see anything in the 2.5 release notes about fixing behaviour on file
move/rename, though I may well have missed it.

And not being able to deal with really large PRs is a definite issue too (not
that github is better there).

  cheers,
rog.

On 14 October 2016 at 12:45, Adam Collard  wrote:
> Not sure I get a vote, but -1
>
> You're running an old version of ReviewBoard (2.0.12 released in January
> 2015) and many of the issues I think you've been hitting are fixed in later
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site
>
> On Fri, 14 Oct 2016 at 12:34 Michael Foord 
> wrote:
>>
>> 0
>>
>>
>> On 13/10/16 23: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
>
>
> --
> 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: Juju 2.0 is here!

2016-10-14 Thread Antonio Rosales 
Congrats on the 2.0 GA release!

-Antonio

On Thursday, October 13, 2016, 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
> juju@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-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>


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

Re: Juju 2.0 is here!

2016-10-14 Thread Katherine Cox-Buday 
Nicholas Skaggs  writes:

> Juju 2.0 is here!

YES! Time to upgrade my production 1.25 installation :D

Congratulations, everyone.

-- 
Katherine

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

Re: Issue deploying a juju controller on openstack private cloud

2016-10-14 Thread Ian Booth 
Unfortunately at the moment there's not good documentation on all of the
possible configuration options. It's something on the radar to improve.

If you did have a running 2.0 system (2.0 was released today), you could type
$ juju model-defaults

to see the available options.

On 14/10/16 00:26, sergio gonzalez wrote:
> Hello Ian
> 
> Thanks for your support. Where can I find all the configuration
> options to be passed during bootstrap?
> 
> Regards
> 
> Sergio
> 
> 2016-10-13 15:58 GMT+02:00 Ian Booth :
>> Hi Sergio
>>
>> Courtesy of Rick Harding, here's the information you need.
>>
>> The openstack provider has a network configuration attribute which needs to 
>> be
>> set to specify the network label or UUID to bring machines up on when 
>> multiple
>> networks exist.
>>
>> You pass it as an argument to bootstrap. eg
>>
>> $ juju bootstrap openstack-controller openstack-mitaka
>> --config image-metadata-url=http://10.2.1.109/simplestream/images/
>> --config network=
>>
>> On 13/10/16 06:29, sergio gonzalez wrote:
>>> Hello
>>>
>>> I am trying to deploy a juju controller, but I get the following error:
>>>
>>> juju --debug bootstrap openstack-controller openstack-mitaka --config
>>> image-metadata-url=http://10.2.1.109/simplestream/images/
>>>
>>> 2016-10-12 20:19:00 INFO juju.cmd supercommand.go:63 running juju
>>> [2.0-beta15 gc go1.6.2]
>>>
>>> 2016-10-12 20:19:00 INFO cmd cmd.go:141 Adding contents of
>>> "/home/ubuntu/.local/share/juju/ssh/juju_id_rsa.pub" to
>>> authorized-keys
>>>
>>> 2016-10-12 20:19:00 DEBUG juju.cmd.juju.commands bootstrap.go:499
>>> preparing controller with config: map[name:controller
>>> uuid:71e55928-2c38-407b-897f-94e83c60890b
>>> image-metadata-url:http://10.2.1.109/simplestream/images/
>>> authorized-keys:ssh-rsa
>>> B3NzaC1yc2EDAQABAAABAQDBoDbcBms7z/ChSG5hQyqZQYhkH6V5uA7HcINuFJH2AC9ygej6TdJ6eCdsPU77x+CgdRVLINE1PhtWsXdYFEZ11e7OV2Y4Jlt/SkMqGJK4enHNXcofIBUntbuVh90hww/yiApLxxi4/cMgHTigu4YZbkZz+QVBqCn5zZMgqPbSR55uHGsT9cbF1S+XRj/OqMpuwOkbgZ/vR880wz6lq1rUwdBOIAIblhuwXHLTT7A5y6Vck69xuqkeyjI67SUdHhxXeCDbjUkOkCqKHY9dU3LNHIH0xYsWGTB7z+FpCn8f7URfMviLQ2QX30Uda/h0KQ91/raGjYE5SHU3E/P/VWtj
>>> juju-client-key
>>>
>>>  type:openstack]
>>>
>>> 2016-10-12 20:19:00 INFO juju.provider.openstack provider.go:75
>>> opening model "controller"
>>>
>>> 2016-10-12 20:19:00 INFO cmd cmd.go:129 Creating Juju controller
>>> "openstack-controller" on openstack-mitaka/RegionOne
>>>
>>> 2016-10-12 20:19:00 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "image-metadata-url"
>>>
>>> 2016-10-12 20:19:00 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "default cloud images"
>>>
>>> 2016-10-12 20:19:00 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "default ubuntu cloud images"
>>>
>>> 2016-10-12 20:19:01 INFO juju.cmd.juju.commands bootstrap.go:641
>>> combined bootstrap constraints:
>>>
>>> 2016-10-12 20:19:01 INFO cmd cmd.go:129 Bootstrapping model "controller"
>>>
>>> 2016-10-12 20:19:01 DEBUG juju.environs.bootstrap bootstrap.go:214
>>> model "controller" supports service/machine networks: false
>>>
>>> 2016-10-12 20:19:01 DEBUG juju.environs.bootstrap bootstrap.go:216
>>> network management by juju enabled: true
>>>
>>> 2016-10-12 20:19:01 INFO juju.environs.bootstrap tools.go:95 looking
>>> for bootstrap tools: version=2.0-beta15
>>>
>>> 2016-10-12 20:19:01 INFO juju.environs.tools tools.go:106 finding
>>> tools in stream "devel"
>>>
>>> 2016-10-12 20:19:01 INFO juju.environs.tools tools.go:108 reading
>>> tools with major.minor version 2.0
>>>
>>> 2016-10-12 20:19:01 INFO juju.environs.tools tools.go:116 filtering
>>> tools by version: 2.0-beta15
>>>
>>> 2016-10-12 20:19:01 DEBUG juju.environs.tools urls.go:109 trying
>>> datasource "keystone catalog"
>>>
>>> 2016-10-12 20:19:02 DEBUG juju.environs.simplestreams
>>> simplestreams.go:680 using default candidate for content id
>>> "com.ubuntu.juju:devel:tools" are {20161007 mirrors:1.0
>>> content-download streams/v1/cpc-mirrors.sjson []}
>>>
>>> 2016-10-12 20:19:03 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "image-metadata-url"
>>>
>>> 2016-10-12 20:19:03 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "default cloud images"
>>>
>>> 2016-10-12 20:19:03 DEBUG juju.environs imagemetadata.go:112 obtained
>>> image datasource "default ubuntu cloud images"
>>>
>>> 2016-10-12 20:19:03 DEBUG juju.environs.bootstrap bootstrap.go:489
>>> constraints for image metadata lookup &{{{RegionOne
>>> http://10.2.1.111:35357/v3} [centos7 precise trusty win10 win2012
>>> win2012hv win2012hvr2 win2012r2 win2016 win2016nano win7 win8 win81
>>> xenial yakkety] [amd64 arm64 ppc64el s390x] released}}
>>>
>>> 2016-10-12 20:19:03 DEBUG juju.environs.bootstrap bootstrap.go:501
>>> found 1 image metadata in image-metadata-url
>>>
>>> 2016-10-12 20:19:04 DEBUG juju.environs.simplestreams
>>> simplestreams.go:458

Re: Github Reviews vs Reviewboard

2016-10-14 Thread roger peppe 
On 14 October 2016 at 12:45, Adam Collard  wrote:
> Not sure I get a vote, but -1
>
> You're running an old version of ReviewBoard (2.0.12 released in January
> 2015) and many of the issues I think you've been hitting are fixed in later
> revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
> brings a chunk of new UI improvements.
>
> Release notes for 2.5
>
> 3.0 demo site

I'm still not convinced.

Even 3.0 still deletes draft comments without so much as a by-your-leave
when you double-click somewhere else in the text. And because it doesn't use
real text entry boxes, the Lazarus plugin, my usual saviour in such cases,
doesn't work. I've lost far too much time to this in the past.

Replying to a comment still involves a page reload and associated lost context.

I can't see anything in the 2.5 release notes about fixing behaviour on file
move/rename, though I may well have missed it.

And not being able to deal with really large PRs is a definite issue too (not
that github is better there).

  cheers,
rog.

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

2016-10-14 Thread Adam Collard 
Not sure I get a vote, but -1

You're running an old version of ReviewBoard (2.0.12 released in January
2015) and many of the issues I think you've been hitting are fixed in later
revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
brings a chunk of new UI improvements.

Release notes for 2.5


3.0 demo site 

On Fri, 14 Oct 2016 at 12:34 Michael Foord 
wrote:

> 0
>
> On 13/10/16 23: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
>
-- 
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

2016-10-14 Thread Michael Foord 

0


On 13/10/16 23: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

2016-10-14 Thread roger peppe 
+1.

Although github reviews are by no means perfect, reviewboard is worse.

It loses draft comments if you click in the wrong place; it takes two
page reloads to
be able to reply to a comment; it doesn't work well on mobile platforms;
it doesn't understand file renames, and the comments are divorced from the
original PR.

Of course, the last point is true of any external tool, but I find reviewboard
constantly frustrating. If the decision was between github and gerrit, I'd
choose gerrit - having used it as part of the Go project, I find it's
much better
in all respects than reviewboard.

  rog.


On 13 October 2016 at 23: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
>

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

2016-10-14 Thread James Tunnicliffe 
-1

On 14 October 2016 at 02:47, Tim Penhey  wrote:
> -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

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

Re: [ANN] Canonical Distribution of Kubernetes Release Notes [week of 10/13]

2016-10-14 Thread Samuel Cozannet 
This is awesome, thanks for the update.

Also, you forgot to mention the addition of the NFS packages, which means
CDK can now consume NFS storage OOTB in addition to having Ceph as a
backend.

Great work folks :)

++
Sam


--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Thu, Oct 13, 2016 at 9:53 PM, Charles Butler <
charles.but...@canonical.com> wrote:

> 10/13 Release Notes
>
> Greetings everyone! It's been a short but busy week for us.  We've landed
> a lot more bugfixes and some new features for you all to kick the tires.
> We're excited to push this week’s rollup as it contains the early work
> (alpha?) in consuming Ceph RBD volumes for persistent volume storage in
> your kubernetes workloads.
>
> It’s missing from the readme, so here is a quick rundown below the release
> notes.  As always, bugs/comments/questions are all welcome.
> https://github.com/juju-solutions/bundle-canonical-kubernetes/issues
>
> Or you can find us on irc in #juju on irc.freenode.net
>
>
> Layer-docker
>
>
>-
>
>Added DOCKER_OPTS passthrough config option. This enables end users to
>configure the runtime of their docker-engine (Such as insecure registries)
>without having to add python code to the layers and/or re-build a fork.
>
>
>-
>
>Corrected an immutable config when attempting to switch between
>archive docker package and the docker-engine package from upstream.
>
>
> Thanks @brianlbaird and @simonklb for driving this feature during
> dev/testing.
>
> Flannel
>
>
>-
>
>Corrected the directory glob pattern on flannel which was failing and
>causing some false positives in the cloud weather report testing tool.
>
>
> Kubernetes Master
>
>-
>
>Added a create-rbd-pv action to enlist persistent storage from Ceph.
>-
>
>   This requires the use of the ceph-mon charm from the
>   openstack-charmers-next branch.
>   -
>
>Closed a bug where running microbots would yield an EOF error due to
>proxy settings. Consult the README for limited egress environments. (Thanks
>@ryebot and @cynerva)
>
>
> Kubernetes Worker
>
>-
>
>Added a kubectl wrapper for context with manifests, and a kubectl
>wrapper for arbitrary keyword args.
>-
>
>Various lint fixes.
>-
>
>Worker nodes now cleanly remove themselves from the cluster during the
>stop hook. (Thanks to @ryebot and @cynerva)
>-
>
>The ingress controller now scales to the number of deployed worker
>units. 1 ingress controller per 1 worker unit. (Thanks to @ryebot and
>@cynerva)
>
>
> Canonical Distribution of Kubernetes Bundle
>
>
>-
>
>Added documentation for proxy settings in network limited environments
>to the bundle README. (Thanks to @ryebot and @cynerva)
>-
>
>Updated the README with additional limitation notes about which charms
>are not compatible enough to run in LXD at this time.
>-
>
>Bumped each charm to their latest revision.
>
>
> Kubernetes Core Bundle
>
> A minimalist bundle, only deploying the bare minimum required to evaluate
> kubernetes. Useful when doing laptop development or resource constrained
> environments. (Thanks @cynerva and @ryebot)
>
>
>
>-
>
>The kubernetes core bundle has been updated with our latest release of
>the Canonical Distribution of Kubernetes (CDK) charms.
>-
>
>Brand new README imported from the CDK bundle.
>
>
> https://github.com/juju-solutions/bundle-kubernetes-core  - we’re still
> testing this minimal bundle, and it will be published in the charm store as
> early as next week. Thanks for your early interest!
>
> Etcd
>
>-
>
>Refactored the test to gate on the status messages before reading the
>deployment as ready and proceeding with executing tests.
>
>
>
> Quick Rundown on how to enlist RBD PV’s
>
> You’ll need to be running at bare-minimum the ceph-mon charm from the
> ~openstack-charmers-next namespace.
>
> juju deploy cs:~openstack-charmers-next/xenial/ceph-mon -n 3
>
> juju deploy cs:ceph-osd -n 3
>
> From here you will need to enlist the OSD storage devices:
>
> For example on GCE you would fulfill this request with GCE Persistent
> Disks:
>
> juju add-storage ceph-osd/0 osd-devices=gce,10gb
>
> juju add-storage ceph-osd/1 osd-devices=gce,10gb
>
> juju add-storage ceph-osd/2 osd-devices=gce,10gb
>
> This will allocate 30gb of storage, across the 3 OSD device nodes, and
> begin your ceph replicated file storage cluster.
>
> Next is to relate the storage cluster with the kubernetes master:
>
> juju add-relation kubernetes-master ceph-mon
>
> We’re now ready to enlist Persistent Volumes in