Juju 2.0-rc1 is here!

[Curtis Hovey-Canonical]

A new development release of Juju, 2.0-rc1, is here!


## What's New in RC1

* The Juju client now works on any Linux flavour. When bootstrapping
  with local tools, it's now possible to create a controller of any
  supported Linux series regardless of the Linux flavour the client
  is running on.
* Juju resolved command retries failed hooks by default:
  juju resolved  // marks unit errors resolved and retries failed hooks
  juju resolved --no-retry  //marks unit errors resolved w/o
retrying hooks
* MAAS 2.0 Juju provider has been updated to use MAAS API 2.0's owner
  data for instance tagging.
* Networking fixes for containers in MAAS 2.0 when the parent device is
  unconfigured. (#1566791)
* Azure provider performance has been enhanced, utilising Azure Resource
  Manager templates, and improved parallelisation.
* Azure provider now supports an "interactive" auth-type, making it much
  easier to set up credentials for bootstrapping. The "userpass"
  auth-type has been deprecated, and replaced with
  "service-principal-secret".


## How do I get it?

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

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

Or install it from the snap store

snap install juju --beta --devmode

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

https://launchpad.net/juju/+milestone/2.0-rc1


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


## Anything else?

You can read more information about what's in this release by viewing
the release notes here:

https://jujucharms.com/docs/devel/temp-release-notes


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

Re: Bootstraping Rackspace

[Mark Shuttleworth]

On 19/09/16 23:36, James Beedy wrote:
> Thanks, Mark! By interactive bootstrap, do you mean interactive 
> add-credentials? If so, I think it already exists for RAX, but isn't quite 
> spot on yet. It looks like I should be able to get bootstrapped with the 
> information contained in the bug link in Rick's response.

Ideally, "juju bootstrap my-controller rackspace" would walk me through
the add-credentials piece too.

Mark

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

Re: Bootstraping Rackspace

[Mark Shuttleworth]

On 19/09/16 23:36, James Beedy wrote:
> Thanks, Mark! By interactive bootstrap, do you mean interactive 
> add-credentials? If so, I think it already exists for RAX, but isn't quite 
> spot on yet. It looks like I should be able to get bootstrapped with the 
> information contained in the bug link in Rick's response.

Ideally, "juju bootstrap my-controller rackspace" would walk me through
the add-credentials piece too.

Mark

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

Re: How to offer debugging help for stuck controller

[Tom Barber]

Thanks chaps, looks it, if I can get the logs I'll add them to the ticket.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 20 September 2016 at 20:15, Gregory Lutostanski <
gregory.lutostan...@canonical.com> wrote:

> In this case I think the bug in particular is: https://bugs.launchpad.net/
> juju/+bug/1566426
>
> On Tue, Sep 20, 2016 at 1:53 PM, Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
>> Hi Tom,
>> Sorry to hear you're having trouble.. I think there might be something
>> interesting in the controller logs that could help us fix it.
>>
>> If you can ssh into the controller machine, could you tar up the logs in
>> /var/log/juju and attach to a Launchpad bug (
>> https://bugs.launchpad.net/juju/+filebug)?
>>
>> Thanks,
>> Casey
>>
>> On Tue, Sep 20, 2016 at 12:23 PM, Tom Barber 
>> wrote:
>>
>>> Hi folks
>>>
>>> I have a controller on CDP thats stuck with 4 running units and 8
>>> pending.
>>>
>>> I can't destroy it or kill it, which strikes me as a bug but I don't
>>> know what I can provide to help you guys fathom it out.
>>>
>>> Obviously its still running as I can't kill it, so let me know what I
>>> can offer up to help you resolve it.
>>>
>>> Tom
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Reviews on Github

[Nate Finch]

Personally, I really enjoy having everything in the same place, more than I
expected. It's also one less barrier of entry for newcomers and outsiders.

On Tue, Sep 20, 2016, 5:54 PM Menno Smits  wrote:

> (gah, hit send too early)
>
> ... If we decide to stay with RB, that will need to be fixed.
>
> On 21 September 2016 at 09:53, Menno Smits 
> wrote:
>
>> Some of us probably got a little excited (me included). There should be
>> discussion and a clear announcement before we make a signigicant change to
>> our process. The tech board meeting is today/tonight so we'll discuss it
>> there as per Rick's email. Please contribute to this thread if you haven't
>> already and have strong opinions either way on the topic.
>>
>> Interestingly our Github/RB integration seems to have broken a little
>> since Github made these changes. The links to Reviewboard on pull requests
>> aren't getting inserted any more. If we decide to stay with RB
>>
>> On 21 September 2016 at 05:54, Rick Harding 
>> wrote:
>>
>>> I spoke with Alexis today about this and it's on her list to check with
>>> her folks on this. The tech board has been tasked with he decision, so
>>> please feel free to shoot a copy of your opinions their way. As you say, on
>>> the one hand it's a big impact on the team, but it's also a standard
>>> developer practice that not everyone will agree with so I'm sure the tech
>>> board is a good solution to limiting the amount of bike-shedding and to
>>> have some multi-mind consensus.
>>>
>>> On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
>>> katherine.cox-bu...@canonical.com> wrote:
>>>
 Seems like a good thing to do would be to ensure the tech board doesn't
 have any objections and then put it to a vote since it's more a property of
 the team and not the codebase.

 I just want some consistency until a decision is made. E.g. "we will be
 trying out GitHub reviews for the next two weeks; all reviews should be
 done on there".

 --
 Katherine

 Nate Finch  writes:

 > Can we try reviews on github for a couple weeks? Seems like we'll
 > never know if it's sufficient if we don't try it. And there's no setup
 > cost, which is nice.
 >
 > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
 >  wrote:
 >
 > I see quite a few PRs that are being reviewed in GitHub and not
 > ReviewBoard. I really don't care where we do them, but can we
 > please pick a direction and move forward? And until then, can we
 > stick to our previous decision and use RB? With people using both
 > it's much more difficult to tell what's been reviewed and what
 > hasn't.
 >
 > --
 > Katherine
 >
 > Nate Finch  writes:
 >
 > > In case you missed it, Github rolled out a new review process.
 > It
 > > basically works just like reviewboard does, where you start a
 > review,
 > > batch up comments, then post the review as a whole, so you don't
 > just
 > > write a bunch of disconnected comments (and get one email per
 > review,
 > > not per comment). The only features reviewboard has is the edge
 > case
 > > stuff that we rarely use: like using rbt to post a review from a
 > > random diff that is not connected directly to a github PR. I
 > think
 > > that is easy enough to give up in order to get the benefit of
 > not
 > > needing an entirely separate system to handle reviews.
 > >
 > > I made a little test review on one PR here, and the UX was
 > almost
 > > exactly like working in reviewboard:
 > > https://github.com/juju/juju/pull/6234
 > >
 > > There may be important edge cases I'm missing, but I think it's
 > worth
 > > looking into.
 > >
 > > -Nate

 --
 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: Reviews on Github

[Menno Smits]

(gah, hit send too early)

... If we decide to stay with RB, that will need to be fixed.

On 21 September 2016 at 09:53, Menno Smits 
wrote:

> Some of us probably got a little excited (me included). There should be
> discussion and a clear announcement before we make a signigicant change to
> our process. The tech board meeting is today/tonight so we'll discuss it
> there as per Rick's email. Please contribute to this thread if you haven't
> already and have strong opinions either way on the topic.
>
> Interestingly our Github/RB integration seems to have broken a little
> since Github made these changes. The links to Reviewboard on pull requests
> aren't getting inserted any more. If we decide to stay with RB
>
> On 21 September 2016 at 05:54, Rick Harding 
> wrote:
>
>> I spoke with Alexis today about this and it's on her list to check with
>> her folks on this. The tech board has been tasked with he decision, so
>> please feel free to shoot a copy of your opinions their way. As you say, on
>> the one hand it's a big impact on the team, but it's also a standard
>> developer practice that not everyone will agree with so I'm sure the tech
>> board is a good solution to limiting the amount of bike-shedding and to
>> have some multi-mind consensus.
>>
>> On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
>> katherine.cox-bu...@canonical.com> wrote:
>>
>>> Seems like a good thing to do would be to ensure the tech board doesn't
>>> have any objections and then put it to a vote since it's more a property of
>>> the team and not the codebase.
>>>
>>> I just want some consistency until a decision is made. E.g. "we will be
>>> trying out GitHub reviews for the next two weeks; all reviews should be
>>> done on there".
>>>
>>> --
>>> Katherine
>>>
>>> Nate Finch  writes:
>>>
>>> > Can we try reviews on github for a couple weeks? Seems like we'll
>>> > never know if it's sufficient if we don't try it. And there's no setup
>>> > cost, which is nice.
>>> >
>>> > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
>>> >  wrote:
>>> >
>>> > I see quite a few PRs that are being reviewed in GitHub and not
>>> > ReviewBoard. I really don't care where we do them, but can we
>>> > please pick a direction and move forward? And until then, can we
>>> > stick to our previous decision and use RB? With people using both
>>> > it's much more difficult to tell what's been reviewed and what
>>> > hasn't.
>>> >
>>> > --
>>> > Katherine
>>> >
>>> > Nate Finch  writes:
>>> >
>>> > > In case you missed it, Github rolled out a new review process.
>>> > It
>>> > > basically works just like reviewboard does, where you start a
>>> > review,
>>> > > batch up comments, then post the review as a whole, so you don't
>>> > just
>>> > > write a bunch of disconnected comments (and get one email per
>>> > review,
>>> > > not per comment). The only features reviewboard has is the edge
>>> > case
>>> > > stuff that we rarely use: like using rbt to post a review from a
>>> > > random diff that is not connected directly to a github PR. I
>>> > think
>>> > > that is easy enough to give up in order to get the benefit of
>>> > not
>>> > > needing an entirely separate system to handle reviews.
>>> > >
>>> > > I made a little test review on one PR here, and the UX was
>>> > almost
>>> > > exactly like working in reviewboard:
>>> > > https://github.com/juju/juju/pull/6234
>>> > >
>>> > > There may be important edge cases I'm missing, but I think it's
>>> > worth
>>> > > looking into.
>>> > >
>>> > > -Nate
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: How to offer debugging help for stuck controller

[Casey Marshall]

Hi Tom,
Sorry to hear you're having trouble.. I think there might be something
interesting in the controller logs that could help us fix it.

If you can ssh into the controller machine, could you tar up the logs in
/var/log/juju and attach to a Launchpad bug (
https://bugs.launchpad.net/juju/+filebug)?

Thanks,
Casey

On Tue, Sep 20, 2016 at 12:23 PM, Tom Barber 
wrote:

> Hi folks
>
> I have a controller on CDP thats stuck with 4 running units and 8 pending.
>
> I can't destroy it or kill it, which strikes me as a bug but I don't know
> what I can provide to help you guys fathom it out.
>
> Obviously its still running as I can't kill it, so let me know what I can
> offer up to help you resolve it.
>
> Tom
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> --
> 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: Increasing the size of VERSION in tabular status output

[Fabrice Matrat]

That would help for every platform and give users a way to configure the
output for their own platform/need.
I live with hi-res screen and would love to be able to customize it as Jay
pointed.

Fabrice.

On Tue, Sep 20, 2016 at 4:09 PM, Jay Wren  wrote:

> With an accepted minimum value, it seems like $COLUMNS or `stty size`
> could be used for variable width status output based on the current
> terminal window.
>
> Does the interest in this thread warrant that complexity?
>
> On Mon, Sep 19, 2016 at 10:21 PM, Rick Harding  > wrote:
>
>> 15 seems a bit large. James, it'd be interesting to get a screenshot of a
>> full openstack with the messages/etc in place to see how it's sizing up in
>> a large complex deploy utilizing the feature fully when rc1 cuts with the
>> change.
>>
>> Thanks
>>
>> On Mon, Sep 19, 2016 at 7:23 PM Tim Penhey 
>> wrote:
>>
>>> Yesterday we changed the limit to 15 from 7.
>>>
>>> Tim
>>>
>>> On 20/09/16 04:41, Rick Harding wrote:
>>> > The primary trouble is that we really want to enforce a limit so that
>>> > there's room for the arbitrary text at the end of the same line. I
>>> think
>>> > we could try 10. I do think we need that hard cutoff. If you need to
>>> see
>>> > the full value going to the json/yaml format output should display the
>>> > full value.
>>> >
>>> > Thanks for the feedback. As it's new it's great to see folks trying it
>>> > and bringing up the issues that get hit.
>>> >
>>> > Rick
>>> >
>>> > On Mon, Sep 19, 2016 at 12:04 PM John Meinel >> > > wrote:
>>> >
>>> > I'm not sure if the unicode ellipsis would cause table alignment
>>> > issues depending on your terminal and font. We could consider it as
>>> > it does give quite a few characters back. The longest I can come up
>>> > with that doesn't feel just gratuitous is 15
>>> > 10.10.10alpha10
>>> > But that might be going to far. I do believe the goal was to funnel
>>> > people to not giving "postgresql-9.8.0-ia32-icc" sort of version
>>> > strings. But it should be useful. 10 characters does seem pretty
>>> > good and doesn't cause us to wrap too often.
>>> > 1.2.3beta4
>>> > Fits in 10, but anything that has 2 digits anywhere would end up
>>> > wrapping. It feels a bit odd to force people into 1.2.3b4 though it
>>> > does convey the same information it makes you use a string that may
>>> > not match the actual upstream nomenclature.
>>> >
>>> > I guess I could be convinced up to 15 characters but 11 might be an
>>> > alternate if we really want people to share the line width but
>>> still
>>> > allow matching upstream version strings.
>>> >
>>> > John
>>> > =:->
>>> >
>>> >
>>> > On Sep 19, 2016 19:13, "Gregory Lutostanski"
>>> > >> > > wrote:
>>> >
>>> > Perhaps also using the utf-8 ellipsis (…) would save some
>>> > characters as well.
>>> >
>>> > --Greg
>>> >
>>> > On Mon, Sep 19, 2016 at 10:09 AM, James Page
>>> > > wrote:
>>> >
>>> > Hi All
>>> >
>>> > We've been experimenting with the new
>>> > application-version-set feature in Juju 2.0 in the
>>> OpenStack
>>> > charms team; it provides a much needed way for a charm to
>>> > indicate which version of an OpenStack component is
>>> deployed
>>> > at any given point in time.
>>> >
>>> > We've come up with an approach that either use the upstream
>>> > version of the principle component being deployed, falling
>>> > back to the codename for an OpenStack release - for
>>> > deployment from source or prior to the packages being
>>> > installed for example.
>>> >
>>> > However, we're finding that 7 chars is a bit limiting in
>>> the
>>> > default tabular status output - for example:
>>> >
>>> >   9.0.0~b3 (truncates to 9.0)
>>> >   icehouse (truncates to iceh...)
>>> >
>>> > Could this field be expandable on demand? I think our
>>> > longest example would currently be:
>>> >
>>> >   13.0.0~rc1 (10 chars)
>>> >
>>> > Cheers
>>> >
>>> > James
>>> >
>>> > --
>>> > 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: Reviews on Github

[Rick Harding]

I spoke with Alexis today about this and it's on her list to check with her
folks on this. The tech board has been tasked with he decision, so please
feel free to shoot a copy of your opinions their way. As you say, on the
one hand it's a big impact on the team, but it's also a standard developer
practice that not everyone will agree with so I'm sure the tech board is a
good solution to limiting the amount of bike-shedding and to have some
multi-mind consensus.

On Tue, Sep 20, 2016 at 1:52 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Seems like a good thing to do would be to ensure the tech board doesn't
> have any objections and then put it to a vote since it's more a property of
> the team and not the codebase.
>
> I just want some consistency until a decision is made. E.g. "we will be
> trying out GitHub reviews for the next two weeks; all reviews should be
> done on there".
>
> --
> Katherine
>
> Nate Finch  writes:
>
> > Can we try reviews on github for a couple weeks? Seems like we'll
> > never know if it's sufficient if we don't try it. And there's no setup
> > cost, which is nice.
> >
> > On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
> >  wrote:
> >
> > I see quite a few PRs that are being reviewed in GitHub and not
> > ReviewBoard. I really don't care where we do them, but can we
> > please pick a direction and move forward? And until then, can we
> > stick to our previous decision and use RB? With people using both
> > it's much more difficult to tell what's been reviewed and what
> > hasn't.
> >
> > --
> > Katherine
> >
> > Nate Finch  writes:
> >
> > > In case you missed it, Github rolled out a new review process.
> > It
> > > basically works just like reviewboard does, where you start a
> > review,
> > > batch up comments, then post the review as a whole, so you don't
> > just
> > > write a bunch of disconnected comments (and get one email per
> > review,
> > > not per comment). The only features reviewboard has is the edge
> > case
> > > stuff that we rarely use: like using rbt to post a review from a
> > > random diff that is not connected directly to a github PR. I
> > think
> > > that is easy enough to give up in order to get the benefit of
> > not
> > > needing an entirely separate system to handle reviews.
> > >
> > > I made a little test review on one PR here, and the UX was
> > almost
> > > exactly like working in reviewboard:
> > > https://github.com/juju/juju/pull/6234
> > >
> > > There may be important edge cases I'm missing, but I think it's
> > worth
> > > looking into.
> > >
> > > -Nate
>
> --
> 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: Reviews on Github

[Katherine Cox-Buday]

Seems like a good thing to do would be to ensure the tech board doesn't have 
any objections and then put it to a vote since it's more a property of the team 
and not the codebase.

I just want some consistency until a decision is made. E.g. "we will be trying 
out GitHub reviews for the next two weeks; all reviews should be done on there".

-- 
Katherine

Nate Finch  writes:

> Can we try reviews on github for a couple weeks? Seems like we'll
> never know if it's sufficient if we don't try it. And there's no setup
> cost, which is nice.
>
> On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday
>  wrote:
>
> I see quite a few PRs that are being reviewed in GitHub and not
> ReviewBoard. I really don't care where we do them, but can we
> please pick a direction and move forward? And until then, can we
> stick to our previous decision and use RB? With people using both
> it's much more difficult to tell what's been reviewed and what
> hasn't.
> 
> --
> Katherine
> 
> Nate Finch  writes:
> 
> > In case you missed it, Github rolled out a new review process.
> It
> > basically works just like reviewboard does, where you start a
> review,
> > batch up comments, then post the review as a whole, so you don't
> just
> > write a bunch of disconnected comments (and get one email per
> review,
> > not per comment). The only features reviewboard has is the edge
> case
> > stuff that we rarely use: like using rbt to post a review from a
> > random diff that is not connected directly to a github PR. I
> think
> > that is easy enough to give up in order to get the benefit of
> not
> > needing an entirely separate system to handle reviews.
> >
> > I made a little test review on one PR here, and the UX was
> almost
> > exactly like working in reviewboard:
> > https://github.com/juju/juju/pull/6234
> >
> > There may be important edge cases I'm missing, but I think it's
> worth
> > looking into.
> >
> > -Nate

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

How to offer debugging help for stuck controller

[Tom Barber]

Hi folks

I have a controller on CDP thats stuck with 4 running units and 8 pending.

I can't destroy it or kill it, which strikes me as a bug but I don't know
what I can provide to help you guys fathom it out.

Obviously its still running as I can't kill it, so let me know what I can
offer up to help you resolve it.

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Reviews on Github

[Nate Finch]

Can we try reviews on github for a couple weeks?  Seems like we'll never
know if it's sufficient if we don't try it.  And there's no setup cost,
which is nice.

On Tue, Sep 20, 2016 at 12:44 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> I see quite a few PRs that are being reviewed in GitHub and not
> ReviewBoard. I really don't care where we do them, but can we please pick a
> direction and move forward? And until then, can we stick to our previous
> decision and use RB? With people using both it's much more difficult to
> tell what's been reviewed and what hasn't.
>
> --
> Katherine
>
> Nate Finch  writes:
>
> > In case you missed it, Github rolled out a new review process. It
> > basically works just like reviewboard does, where you start a review,
> > batch up comments, then post the review as a whole, so you don't just
> > write a bunch of disconnected comments (and get one email per review,
> > not per comment). The only features reviewboard has is the edge case
> > stuff that we rarely use: like using rbt to post a review from a
> > random diff that is not connected directly to a github PR. I think
> > that is easy enough to give up in order to get the benefit of not
> > needing an entirely separate system to handle reviews.
> >
> > I made a little test review on one PR here, and the UX was almost
> > exactly like working in reviewboard:
> > https://github.com/juju/juju/pull/6234
> >
> > There may be important edge cases I'm missing, but I think it's worth
> > looking into.
> >
> > -Nate
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reviews on Github

[Katherine Cox-Buday]

I see quite a few PRs that are being reviewed in GitHub and not ReviewBoard. I 
really don't care where we do them, but can we please pick a direction and move 
forward? And until then, can we stick to our previous decision and use RB? With 
people using both it's much more difficult to tell what's been reviewed and 
what hasn't.

-- 
Katherine

Nate Finch  writes:

> In case you missed it, Github rolled out a new review process. It
> basically works just like reviewboard does, where you start a review,
> batch up comments, then post the review as a whole, so you don't just
> write a bunch of disconnected comments (and get one email per review,
> not per comment). The only features reviewboard has is the edge case
> stuff that we rarely use: like using rbt to post a review from a
> random diff that is not connected directly to a github PR. I think
> that is easy enough to give up in order to get the benefit of not
> needing an entirely separate system to handle reviews. 
>
> I made a little test review on one PR here, and the UX was almost
> exactly like working in reviewboard:
> https://github.com/juju/juju/pull/6234
>
> There may be important edge cases I'm missing, but I think it's worth
> looking into.
>
> -Nate

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

Re: Increasing the size of VERSION in tabular status output

[Jay Wren]

With an accepted minimum value, it seems like $COLUMNS or `stty size` could
be used for variable width status output based on the current terminal
window.

Does the interest in this thread warrant that complexity?

On Mon, Sep 19, 2016 at 10:21 PM, Rick Harding 
wrote:

> 15 seems a bit large. James, it'd be interesting to get a screenshot of a
> full openstack with the messages/etc in place to see how it's sizing up in
> a large complex deploy utilizing the feature fully when rc1 cuts with the
> change.
>
> Thanks
>
> On Mon, Sep 19, 2016 at 7:23 PM Tim Penhey 
> wrote:
>
>> Yesterday we changed the limit to 15 from 7.
>>
>> Tim
>>
>> On 20/09/16 04:41, Rick Harding wrote:
>> > The primary trouble is that we really want to enforce a limit so that
>> > there's room for the arbitrary text at the end of the same line. I think
>> > we could try 10. I do think we need that hard cutoff. If you need to see
>> > the full value going to the json/yaml format output should display the
>> > full value.
>> >
>> > Thanks for the feedback. As it's new it's great to see folks trying it
>> > and bringing up the issues that get hit.
>> >
>> > Rick
>> >
>> > On Mon, Sep 19, 2016 at 12:04 PM John Meinel > > > wrote:
>> >
>> > I'm not sure if the unicode ellipsis would cause table alignment
>> > issues depending on your terminal and font. We could consider it as
>> > it does give quite a few characters back. The longest I can come up
>> > with that doesn't feel just gratuitous is 15
>> > 10.10.10alpha10
>> > But that might be going to far. I do believe the goal was to funnel
>> > people to not giving "postgresql-9.8.0-ia32-icc" sort of version
>> > strings. But it should be useful. 10 characters does seem pretty
>> > good and doesn't cause us to wrap too often.
>> > 1.2.3beta4
>> > Fits in 10, but anything that has 2 digits anywhere would end up
>> > wrapping. It feels a bit odd to force people into 1.2.3b4 though it
>> > does convey the same information it makes you use a string that may
>> > not match the actual upstream nomenclature.
>> >
>> > I guess I could be convinced up to 15 characters but 11 might be an
>> > alternate if we really want people to share the line width but still
>> > allow matching upstream version strings.
>> >
>> > John
>> > =:->
>> >
>> >
>> > On Sep 19, 2016 19:13, "Gregory Lutostanski"
>> > > > > wrote:
>> >
>> > Perhaps also using the utf-8 ellipsis (…) would save some
>> > characters as well.
>> >
>> > --Greg
>> >
>> > On Mon, Sep 19, 2016 at 10:09 AM, James Page
>> > > wrote:
>> >
>> > Hi All
>> >
>> > We've been experimenting with the new
>> > application-version-set feature in Juju 2.0 in the OpenStack
>> > charms team; it provides a much needed way for a charm to
>> > indicate which version of an OpenStack component is deployed
>> > at any given point in time.
>> >
>> > We've come up with an approach that either use the upstream
>> > version of the principle component being deployed, falling
>> > back to the codename for an OpenStack release - for
>> > deployment from source or prior to the packages being
>> > installed for example.
>> >
>> > However, we're finding that 7 chars is a bit limiting in the
>> > default tabular status output - for example:
>> >
>> >   9.0.0~b3 (truncates to 9.0)
>> >   icehouse (truncates to iceh...)
>> >
>> > Could this field be expandable on demand? I think our
>> > longest example would currently be:
>> >
>> >   13.0.0~rc1 (10 chars)
>> >
>> > Cheers
>> >
>> > James
>> >
>> > --
>> > 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
>> >
>> > --
>> > 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings 

Re: Upcoming Azure auth changes

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 9:56 AM Andrew Wilkins 
wrote:

> On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> Hi folks,
>>
>> Just a heads up, where will be some changes to authentication in the
>> Azure provider. When https://github.com/juju/juju/pull/6247 lands (if
>> you're working off master), or otherwise when rc1 is out, you will need to
>> remove "tenant-id" from your credentials.yaml.
>>
>
> Slight change of plans. I'm going to deprecate the "userpass"
> authentication type, but keep it working until rc1 is out.
>
> There will be two new auth-types: "service-principal-secret", and
> "interactive". The former is a replacement for userpass, and has exactly
> the same attributes as today, minus the tenant-id. "Interactive" is a work
> in progress. I'll write back about it once the work is progressed enough
> that I can explain how to use it.
>

The "interactive" auth-type for Azure has just landed on master, so it
should be in 2.0 RC1. This is now the default auth-type when using "juju
add-credential azure".

To add a credential for Azure, you now do the following:
 - run "juju add-credential azure"
 - enter credential name of your choosing
 - select the "interactive" auth-type
 - enter your subscription ID [0]
 - you will now be prompted to open a URL and enter a code, then proceed to
authenticate with Azure and authorise Juju to create credentials on your
behalf. Once you have given your consent, Juju will do the rest.

Cheers,
Andrew

[0] your subscription ID can be found in the Azure Portal, under the
Subscriptions blade:
https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Bootstraping Rackspace

[James Beedy]

Thanks, Mark! By interactive bootstrap, do you mean interactive 
add-credentials? If so, I think it already exists for RAX, but isn't quite spot 
on yet. It looks like I should be able to get bootstrapped with the information 
contained in the bug link in Rick's response.

~James

> On Sep 19, 2016, at 7:25 PM, Mark Shuttleworth  wrote:
> 
>> On 19/09/16 16:19, James Beedy wrote:
>> I am trying to bootstrap the rackspace provider and cannot seem to get past 
>> "ERROR failed to bootstrap model: no image metadata found". Do I need to 
>> generate metadata for rackspace provider? I feel like I need to get some 
>> images in rackspace and generate the image metadata using the image ids for 
>> said images. Is there any difference between the way this is done for 
>> openstack and the way it should be done here?
>> 
>> Could someone who has successfully bootstrapped rackspace shed some light 
>> here?
> 
> There are official Ubuntu images in Rackspace, so bootstrap should work fine, 
> it's a bug if it doesn't. Not sure about Windows and CentOS charms unless 
> there are official images of those too.
> 
> Would be nice to get an interactive bootstrap in RAX too :)
> 
> Mark

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

Re: Bootstraping Rackspace

[James Beedy]

Awesome! Thanks! 

> On Sep 19, 2016, at 7:18 PM, Rick Harding  wrote:
> 
> James, what good timing. The streams with image info is just going through 
> getting setup. 
> 
> https://bugs.launchpad.net/juju/+bug/1625243
> 
> It took a bit for the images for trusty/xenial to get setup and the team's 
> working to make it all work out of the box. 
> 
> We had demo streams up for testing and it's in the rackspace documentation:
> https://jujucharms.com/docs/master/help-rackspace
> 
> Unfortunately, the metadata-url is 404'ing so looks like they've been moved 
> and the documentation needs to be updated. I'll see what I can find out as to 
> a new location. You might also track the bug to watch the progress of the 
> official path going forward. 
> 
> Apologies for the trouble getting it going as we ramp things up. 
> 
>> On Mon, Sep 19, 2016 at 7:26 PM James Beedy  wrote:
>> I am trying to bootstrap the rackspace provider and cannot seem to get past 
>> "ERROR failed to bootstrap model: no image metadata found". Do I need to 
>> generate metadata for rackspace provider? I feel like I need to get some 
>> images in rackspace and generate the image metadata using the image ids for 
>> said images. Is there any difference between the way this is done for 
>> openstack and the way it should be done here?
>> 
>> Could someone who has successfully bootstrapped rackspace shed some light 
>> here?
>> 
>> thx
>> --
>> 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: Bootstraping Rackspace

[James Beedy]

Awesome! Thanks! 

> On Sep 19, 2016, at 7:18 PM, Rick Harding  wrote:
> 
> James, what good timing. The streams with image info is just going through 
> getting setup. 
> 
> https://bugs.launchpad.net/juju/+bug/1625243
> 
> It took a bit for the images for trusty/xenial to get setup and the team's 
> working to make it all work out of the box. 
> 
> We had demo streams up for testing and it's in the rackspace documentation:
> https://jujucharms.com/docs/master/help-rackspace
> 
> Unfortunately, the metadata-url is 404'ing so looks like they've been moved 
> and the documentation needs to be updated. I'll see what I can find out as to 
> a new location. You might also track the bug to watch the progress of the 
> official path going forward. 
> 
> Apologies for the trouble getting it going as we ramp things up. 
> 
>> On Mon, Sep 19, 2016 at 7:26 PM James Beedy  wrote:
>> I am trying to bootstrap the rackspace provider and cannot seem to get past 
>> "ERROR failed to bootstrap model: no image metadata found". Do I need to 
>> generate metadata for rackspace provider? I feel like I need to get some 
>> images in rackspace and generate the image metadata using the image ids for 
>> said images. Is there any difference between the way this is done for 
>> openstack and the way it should be done here?
>> 
>> Could someone who has successfully bootstrapped rackspace shed some light 
>> here?
>> 
>> thx
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/juju
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev