Re: Upcoming Azure auth changes

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins 
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.


> There is more work underway to improve the bootstrap/credentials
> experience for Azure.
>
> Cheers,
> Andrew
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Upcoming Azure auth changes

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins 
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.


> There is more work underway to improve the bootstrap/credentials
> experience for Azure.
>
> Cheers,
> Andrew
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming Azure auth changes

[Andrew Wilkins]

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.

There is more work underway to improve the bootstrap/credentials experience
for Azure.

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

Upcoming Azure auth changes

[Andrew Wilkins]

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.

There is more work underway to improve the bootstrap/credentials experience
for Azure.

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

Re: Reviews on Github

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 6:22 AM Rick Harding 
wrote:

> I think that the issue is that someone has to maintain the RB and the
> cost/time spent on that does not seem commensurate with the bonus features
> in my experience.
>

Agreed and +1. I propose we all try it for a couple of weeks, and see how
we feel about it then. RB isn't going to go anywhere soon - it's just a
matter of whether we keep our instance alive.

In case anyone's wondering about pipelines: it looks like you can review on
individual commits, so that's covered.

On Wed, Sep 14, 2016 at 6:13 PM Ian Booth  wrote:
>
>> One thing review board does better is use gutter indicators so as not to
>> interrupt the flow of reading the code with huge comment blocks. It also
>> seems
>> much better at allowing previous commits with comments to be viewed in
>> their
>> entirety. And it allows the reviewer to differentiate between issues and
>> comments (ie fix this vs take note of this), plus it allows the notion of
>> marking stuff as fixed vs dropped, with a reason for dropping if needed.
>> So the
>> github improvements are nice but there's still a large and significant
>> gap that
>> is yet to be filled. I for one would miss all the features reviewboard
>> offers.
>> Unless there's a way of doing the same thing in github that I'm not aware
>> of.
>>
>> On 15/09/16 07:22, Tim Penhey wrote:
>> > I'm +1 if we can remove the extra tools and we don't get email per
>> comment.
>> >
>> > On 15/09/16 08:03, Nate Finch wrote:
>> >> 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

[Anastasia Macmood]

+1 on moving away from RB \o/

Currently contributors need to allow RB to run against their github
fork, if they don't then we do not see their contributions on RB and PRs
go un-reviewed and seem ignored.

Communication between github and RB is not optimal: we had plenty of
instances where RB would close a review but github PR is still active;
as well as the other way around.

RB is also not configured on some of our "external" libraries under
github/juju. So we are not reviewing these proposals either...

Not to mention that we still need to fall back to github to confirm that
there are no conflicts on PRs as RB does not report that.


On 15/09/16 08:22, Rick Harding wrote:
> I think that the issue is that someone has to maintain the RB and the
> cost/time spent on that does not seem commensurate with the bonus
> features in my experience. 
>
> On Wed, Sep 14, 2016 at 6:13 PM Ian Booth  > wrote:
>
> One thing review board does better is use gutter indicators so as
> not to
> interrupt the flow of reading the code with huge comment blocks.
> It also seems
> much better at allowing previous commits with comments to be
> viewed in their
> entirety. And it allows the reviewer to differentiate between
> issues and
> comments (ie fix this vs take note of this), plus it allows the
> notion of
> marking stuff as fixed vs dropped, with a reason for dropping if
> needed. So the
> github improvements are nice but there's still a large and
> significant gap that
> is yet to be filled. I for one would miss all the features
> reviewboard offers.
> Unless there's a way of doing the same thing in github that I'm
> not aware of.
>
> On 15/09/16 07:22, Tim Penhey wrote:
> > I'm +1 if we can remove the extra tools and we don't get email
> per comment.
> >
> > On 15/09/16 08:03, Nate Finch wrote:
> >> 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

[Rick Harding]

I think that the issue is that someone has to maintain the RB and the
cost/time spent on that does not seem commensurate with the bonus features
in my experience.

On Wed, Sep 14, 2016 at 6:13 PM Ian Booth  wrote:

> One thing review board does better is use gutter indicators so as not to
> interrupt the flow of reading the code with huge comment blocks. It also
> seems
> much better at allowing previous commits with comments to be viewed in
> their
> entirety. And it allows the reviewer to differentiate between issues and
> comments (ie fix this vs take note of this), plus it allows the notion of
> marking stuff as fixed vs dropped, with a reason for dropping if needed.
> So the
> github improvements are nice but there's still a large and significant gap
> that
> is yet to be filled. I for one would miss all the features reviewboard
> offers.
> Unless there's a way of doing the same thing in github that I'm not aware
> of.
>
> On 15/09/16 07:22, Tim Penhey wrote:
> > I'm +1 if we can remove the extra tools and we don't get email per
> comment.
> >
> > On 15/09/16 08:03, Nate Finch wrote:
> >> 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

[Ian Booth]

One thing review board does better is use gutter indicators so as not to
interrupt the flow of reading the code with huge comment blocks. It also seems
much better at allowing previous commits with comments to be viewed in their
entirety. And it allows the reviewer to differentiate between issues and
comments (ie fix this vs take note of this), plus it allows the notion of
marking stuff as fixed vs dropped, with a reason for dropping if needed. So the
github improvements are nice but there's still a large and significant gap that
is yet to be filled. I for one would miss all the features reviewboard offers.
Unless there's a way of doing the same thing in github that I'm not aware of.

On 15/09/16 07:22, Tim Penhey wrote:
> I'm +1 if we can remove the extra tools and we don't get email per comment.
> 
> On 15/09/16 08:03, Nate Finch wrote:
>> 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: Feedback wanted: Changes to the Ubuntu Charm

[Tim Penhey]

Marco,

This is awesome. I use the ubuntu charm all the time for testing, and 
seeing the workload version and workload status being set is pretty cool.


I had hoped that seeing the "unknown" status would apply gentle pressure 
to get people to set a workload status.


Winning!!!

Tim

On 15/09/16 08:39, Marco Ceppi wrote:

Hi Ryan,

I have granted everyone access to the candidate channel. Could you try
again?

Thanks,
Marco Ceppi

On Wed, Sep 14, 2016 at 3:26 PM Ryan Beisner > wrote:

Is there a merge proposal or pull request for the changes?  I'd like
to validate with 1.25.6 as the current stable release, but --channel
isn't a thing there.

I tried to `charm pull ubuntu --channel candidate` but received:
 ERROR cannot get archive: unauthorized: access denied.

Thanks,

Ryan


On Wed, Sep 14, 2016 at 8:57 AM, Marco Ceppi
> wrote:

Hey everyone,

Normally, I wouldn't bother with an update like this, but it's
slightly larger than I'd care to just push out. Today, the
Ubuntu charm is a no-op, which is largely the goal of the charm.
However, as juju becomes more rich this no-op charm starts to
look incomplete. I know a few people depend on the Ubuntu charm
for setup purposes and testing. I'd hate to be the source of
breakage for that charm so I'm announcing an update here.

Screenshot from 2016-09-14 09-48-31.png

Other than the obvious changes to status, this also implements
workload version.

If you depend on the Ubuntu charm for anything I urge you to
test the latest version with

`juju deploy ubuntu --channel candidate`

If I don't receive any negative feedback by the end of this week
I'll move what's in candidate to stable.

Thanks,
Marco Ceppi

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

[Tim Penhey]

I'm +1 if we can remove the extra tools and we don't get email per comment.

On 15/09/16 08:03, Nate Finch wrote:

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: Feedback wanted: Changes to the Ubuntu Charm

[Marco Ceppi]

Hi Ryan,

I have granted everyone access to the candidate channel. Could you try
again?

Thanks,
Marco Ceppi

On Wed, Sep 14, 2016 at 3:26 PM Ryan Beisner 
wrote:

> Is there a merge proposal or pull request for the changes?  I'd like to
> validate with 1.25.6 as the current stable release, but --channel isn't a
> thing there.
>
> I tried to `charm pull ubuntu --channel candidate` but received:  ERROR
> cannot get archive: unauthorized: access denied.
>
> Thanks,
>
> Ryan
>
>
> On Wed, Sep 14, 2016 at 8:57 AM, Marco Ceppi 
> wrote:
>
>> Hey everyone,
>>
>> Normally, I wouldn't bother with an update like this, but it's slightly
>> larger than I'd care to just push out. Today, the Ubuntu charm is a no-op,
>> which is largely the goal of the charm. However, as juju becomes more rich
>> this no-op charm starts to look incomplete. I know a few people depend on
>> the Ubuntu charm for setup purposes and testing. I'd hate to be the source
>> of breakage for that charm so I'm announcing an update here.
>>
>> [image: Screenshot from 2016-09-14 09-48-31.png]
>>
>> Other than the obvious changes to status, this also implements workload
>> version.
>>
>> If you depend on the Ubuntu charm for anything I urge you to test the
>> latest version with
>>
>> `juju deploy ubuntu --channel candidate`
>>
>> If I don't receive any negative feedback by the end of this week I'll
>> move what's in candidate to stable.
>>
>> Thanks,
>> Marco Ceppi
>>
>> --
>> 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

[Dimiter Naydenov]

As long as we can have draft reviews like on RB and not
email-spam-per-comment, totally +1

On 09/14/2016 01:25 PM, Horacio Duran wrote:
> Also +1 for that source not being review board
> 
> On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien  > wrote:
> 
> Also +1 for a single source of truth.
> 
> On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding
> > wrote:
> 
> /me is always +1 on reducing the number of things we have to
> maintain and keeping things simpler. 
> 
> On Wed, Sep 14, 2016 at 4:04 PM Nate Finch
> > wrote:
> 
> 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
> 
> 
> 
> 
> 
> -- 
> 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
> 
> 
> 
> 
> 


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

[Casey Marshall]

I'm halfway through my first Github review (different project though) on
the new system, and so far I'm loving it. Also consider the issues we've
had with rbt being unable to handle diffs with files
added/removed/relocated. +1 from me!

-Casey

On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien 
wrote:

> Also +1 for a single source of truth.
>
> On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding 
> wrote:
>
>> /me is always +1 on reducing the number of things we have to maintain and
>> keeping things simpler.
>>
>> On Wed, Sep 14, 2016 at 4:04 PM Nate Finch 
>> wrote:
>>
>>> 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.co
>>> m/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
>>
>>
>
>
> --
> 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
>
>
-- 
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

[Horacio Duran]

Also +1 for that source not being review board

On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien 
wrote:

> Also +1 for a single source of truth.
>
> On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding 
> wrote:
>
>> /me is always +1 on reducing the number of things we have to maintain and
>> keeping things simpler.
>>
>> On Wed, Sep 14, 2016 at 4:04 PM Nate Finch 
>> wrote:
>>
>>> 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.co
>>> m/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
>>
>>
>
>
> --
> 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
>
>
-- 
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

[Rick Harding]

/me is always +1 on reducing the number of things we have to maintain and
keeping things simpler.

On Wed, Sep 14, 2016 at 4:04 PM Nate Finch  wrote:

> 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: LXD instances fail to start

[Ryan Beisner]

In one case yesterday, with a full openstack-on-lxd deployed and in use, I
quickly hit the too-many-open-files issue.

I raised fs.inotify.max_user_instances on the host to 50 which
unblocked me for a while.  I ended up raising both to 99 and have had
smooth sailing since.  Currently, the host shows 676063 files open.  That
is way above the default values of 128, respectively.  Bear in mind that
these are workarounds/observations to make-it-work(tm) and might not be the
best thing to do.  Also curious if there is more official input to this
issue.

Cheers,

Ryan



On Wed, Sep 14, 2016 at 12:15 AM, James Beedy  wrote:

> For those who have been following the lxd issue that we've been digressing
> on at the charmer summit, see https://bugs.launchpad.net/
> juju-core/+bug/1602192
>
> 7/22-now no activity
>
> It looks like the bug already has eyes on it, but has been idle for a
> while now. It would be nice to get this thing fixed/resolved to some
> extent. Can we get some heat on this?!?
>
> Thanks
> --
> 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: LXD instances fail to start

[Ryan Beisner]

In one case yesterday, with a full openstack-on-lxd deployed and in use, I
quickly hit the too-many-open-files issue.

I raised fs.inotify.max_user_instances on the host to 50 which
unblocked me for a while.  I ended up raising both to 99 and have had
smooth sailing since.  Currently, the host shows 676063 files open.  That
is way above the default values of 128, respectively.  Bear in mind that
these are workarounds/observations to make-it-work(tm) and might not be the
best thing to do.  Also curious if there is more official input to this
issue.

Cheers,

Ryan



On Wed, Sep 14, 2016 at 12:15 AM, James Beedy  wrote:

> For those who have been following the lxd issue that we've been digressing
> on at the charmer summit, see https://bugs.launchpad.net/
> juju-core/+bug/1602192
>
> 7/22-now no activity
>
> It looks like the bug already has eyes on it, but has been idle for a
> while now. It would be nice to get this thing fixed/resolved to some
> extent. Can we get some heat on this?!?
>
> Thanks
> --
> 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

Reviews on Github

[Nate Finch]

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: Feedback wanted: Changes to the Ubuntu Charm

[Ryan Beisner]

Is there a merge proposal or pull request for the changes?  I'd like to
validate with 1.25.6 as the current stable release, but --channel isn't a
thing there.

I tried to `charm pull ubuntu --channel candidate` but received:  ERROR
cannot get archive: unauthorized: access denied.

Thanks,

Ryan


On Wed, Sep 14, 2016 at 8:57 AM, Marco Ceppi 
wrote:

> Hey everyone,
>
> Normally, I wouldn't bother with an update like this, but it's slightly
> larger than I'd care to just push out. Today, the Ubuntu charm is a no-op,
> which is largely the goal of the charm. However, as juju becomes more rich
> this no-op charm starts to look incomplete. I know a few people depend on
> the Ubuntu charm for setup purposes and testing. I'd hate to be the source
> of breakage for that charm so I'm announcing an update here.
>
> [image: Screenshot from 2016-09-14 09-48-31.png]
>
> Other than the obvious changes to status, this also implements workload
> version.
>
> If you depend on the Ubuntu charm for anything I urge you to test the
> latest version with
>
> `juju deploy ubuntu --channel candidate`
>
> If I don't receive any negative feedback by the end of this week I'll move
> what's in candidate to stable.
>
> Thanks,
> Marco Ceppi
>
> --
> 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

Feedback wanted: Changes to the Ubuntu Charm

[Marco Ceppi]

Hey everyone,

Normally, I wouldn't bother with an update like this, but it's slightly
larger than I'd care to just push out. Today, the Ubuntu charm is a no-op,
which is largely the goal of the charm. However, as juju becomes more rich
this no-op charm starts to look incomplete. I know a few people depend on
the Ubuntu charm for setup purposes and testing. I'd hate to be the source
of breakage for that charm so I'm announcing an update here.

[image: Screenshot from 2016-09-14 09-48-31.png]

Other than the obvious changes to status, this also implements workload
version.

If you depend on the Ubuntu charm for anything I urge you to test the
latest version with

`juju deploy ubuntu --channel candidate`

If I don't receive any negative feedback by the end of this week I'll move
what's in candidate to stable.

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

Re: Proposal: Make setting bug-url and homepage metadata policy

[Jorge O. Castro]

On Wed, Sep 14, 2016 at 10:05 AM, Uros Jovanovic <
uros.jovano...@canonical.com> wrote:

> I don't think we need to make it mandatory for all charms, as it
> introduces a barrier maybe not everyone wants to cover at the beginning of
> their charming path ...


Agreed, people's namespaces are their own to do as they wish.

-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your application
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: JUJU Charm Certification

[Chris MacNaughton]

> On Sep 13, 2016, at 23:02, SivaRamaPrasad Ravipati  wrote:
> 
> Hi Chris , 
> 
> Thank you very much. I got a very good information. 
> 
> Sorry.  I didn't understand one thing  Clearly.
> 
> For the Question, 
> 
> At a time, can I deploy two storages arrays to same cinder node?
> 
> Can we add two storage arrays to cinder node using the single charm?
> 
> description
> =
> Question
> --
> 
> For example, We  have different storage arrays of same type with unique 
> config parameter values.[Like San IP, SAN password, San user].  
> Assume that our charm has been deployed with some configuration values and we 
> added relation to cinder. Our charm will modify cinder.cong with the storage 
> array driver. Next time we want to redeploy our charm to append only the new 
> configuration changes. But we don't want to destroy already existing changes.
> 
> Upto which extension,  "juju set-config" and "juju upgrade-charm" will be 
> used here. Please give me a simple example if it possible.
> 
> For this Scenario, Which use-case will be generally used. Please let me know 
> that in a detailed manner.
> 
> 
> Answer [by Marcoceppi]
> --
> In Juju, and especially with Cinder plugins, you can deploy multiple copies 
> of the Juju charm and relate them. Each application deployed is equivalent to 
> the scope of a SAN cluster:
> 
> juju deploy cinder
> juju deploy your-charm san1
> juju deploy your-charm san2
> 
> juju add-relation cinder san1
> juju add-relation cinder san2
> 
> Now, you can configure each of the new applications, which are the same copy 
> of the charm deployed multiple times. This will add a unique backend per 
> charm copy which seems to be your intended use case
> 
> -> This use case worked for us.
> 
> But here we are deploying 
> 
> But what I am asking here is,
> 
> Can I do like, Instead of deploying san1 application and san2 application 
> separately and adding relations separately
> 
> juju deploy cinder
> juju deploy my-charm san1 san2
> juju add-relation cinder san1 san1
No, you can not deploy things like this with Juju.

> 
> Thanks,
> Siva.
> 
> 
>> On Wed, Sep 14, 2016 at 2:17 AM, Chris MacNaughton 
>>  wrote:
>> Hey Siva,
>>  
>>> But I want to know about "How can we Scale Cinder nodes
>> 
>>  To scale up Cinder, you should just have to deploy the Hacluster[1] charm 
>> and relate it to the Cinder charm. Additionally, you will need a VIP to 
>> assign to the hacluster charm.
>>> as well as adding multiple storage arrays to the each  scaled cinder unit 
>>> horizontally".
>> 
>> Assuming that you have a Cinder driver for your storage array, you should be 
>> able to associate it as a subordinate charm multiple times with different 
>> configs. For example:
>> $ juju deploy cinder
>> $ juju deploy cinder_backend_array  replicated --config=replicated.yaml
>> $ juju deploy cinder_backend_array non-replicated 
>> --config=non-replicated.yaml
>> $ juju deploy cinder_backend_array dedup --config=dedup.yaml
>> $ juju add-relation cinder replicated
>> $ juju add-relation cinder non-replicated
>> $ juju add-relation dedup
>> 
>> This will deploy the charm 'cinder_backend_array' with different names and 
>> configurations, and then will add them as subordinates to the Cinder charm. 
>> The Cinder charm merges backends in the configuration file by using 
>> configuration provided through the relation with the various drivers' 
>> subordinate relations.
>>> 
>>> Sub Question 
>>> 
>>> At a time, can I deploy two storages arrays to same cinder node .
>> 
>> Yes,  
>>> 
>>> Like,
>>> 
>>> $juju deploy cinder
>>> $juju add-unit cinder -n 3
>>> $juju deploy mystorageCharm san1 san2
>>> $juju add relation cinder san1 san1
>> 
>> but not like this, see the example above.
>> 
>> [1]: https://jujucharms.com/hacluster/
> 
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Proposal: Make setting bug-url and homepage metadata policy

[Uros Jovanovic]

We were thinking of blocking the "recommended" procedure to an entity
without those values set. So, you want to have a recommended charm, make
sure URLs are set and valid.

I don't think we need to make it mandatory for all charms, as it introduces
a barrier maybe not everyone wants to cover at the beginning of their
charming path ...



On Wed, Sep 14, 2016 at 4:00 PM, Jorge O. Castro  wrote:

> Good morning,
>
> I'd like to propose a policy change as a for incoming new charms. The
> homepage and bugs-url fields are used to point users to where they can file
> bugs, and where they can find the source code to the charm. The store uses
> these fields to generate the page for each charm on jujucharms.com.
>
> Some promulgated charms are missing this (kubernetes and keystone for
> example), so I'd like to encourage charm authors to set these two fields
> with charm set:
>
> charm set wordpress bugs-url=https://bugspageforwordpress.none
> charm set wordpress homepage=https://homepageforwordpress.none
>
> You can also tack a --channel on there, see:
> https://jujucharms.com/docs/2.0/tools-charm-tools
>
> I'd like to propose a new policy to submission to the charm store metadata
> guidelines: https://jujucharms.com/docs/stable/
> authors-charm-policy#metadata-guidelines
>
> MUST include bug reporting URL and homepage URL link to the source
> code in metadata.
>
> While a bunch of charms written before this feature do put this sort of
> information in the bottom of the readme I would like to get us filling out
> the metadata for programmatic reasons and visibility on the charm's page in
> the store.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your application
>
> --
> 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

Proposal: Make setting bug-url and homepage metadata policy

[Jorge O. Castro]

Good morning,

I'd like to propose a policy change as a for incoming new charms. The
homepage and bugs-url fields are used to point users to where they can file
bugs, and where they can find the source code to the charm. The store uses
these fields to generate the page for each charm on jujucharms.com.

Some promulgated charms are missing this (kubernetes and keystone for
example), so I'd like to encourage charm authors to set these two fields
with charm set:

charm set wordpress bugs-url=https://bugspageforwordpress.none
charm set wordpress homepage=https://homepageforwordpress.none

You can also tack a --channel on there, see:
https://jujucharms.com/docs/2.0/tools-charm-tools

I'd like to propose a new policy to submission to the charm store metadata
guidelines:
https://jujucharms.com/docs/stable/authors-charm-policy#metadata-guidelines

MUST include bug reporting URL and homepage URL link to the source code
in metadata.

While a bunch of charms written before this feature do put this sort of
information in the bottom of the readme I would like to get us filling out
the metadata for programmatic reasons and visibility on the charm's page in
the store.

-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your application
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Getting Error while installing juju-local for juju 1.25 : juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going to be installed....

[Anita Nayak1]

Hi All,

I am trying to install juju 1.25 and getting error while performing the
below step:

sudo apt-get install juju-local
[sudo] password for charm:
no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going
to be installed
  Depends: lxc-templates but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


Please suggest how to remove this.

Thanks & Regards,
Anita.

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

LXD instances fail to start

[James Beedy]

For those who have been following the lxd issue that we've been digressing on 
at the charmer summit, see https://bugs.launchpad.net/juju-core/+bug/1602192 

7/22-now no activity

It looks like the bug already has eyes on it, but has been idle for a while 
now. It would be nice to get this thing fixed/resolved to some extent. Can we 
get some heat on this?!?

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

LXD instances fail to start

[James Beedy]

For those who have been following the lxd issue that we've been digressing on 
at the charmer summit, see https://bugs.launchpad.net/juju-core/+bug/1602192 

7/22-now no activity

It looks like the bug already has eyes on it, but has been idle for a while 
now. It would be nice to get this thing fixed/resolved to some extent. Can we 
get some heat on this?!?

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

Re: JUJU Charm Certification

[SivaRamaPrasad Ravipati]

Hi Chris ,

Thank you very much. I got a very good information.

Sorry.  I didn't understand one thing  Clearly.

For the Question,

At a time, can I deploy two storages arrays to same cinder node?

Can we add two storage arrays to cinder node using the single charm?

description
=
Question
--

For example, We  have different storage arrays of same type with unique
config parameter values.[Like San IP, SAN password, San user].
Assume that our charm has been deployed with some configuration values and
we added relation to cinder. Our charm will modify cinder.cong with the
storage array driver. Next time we want to redeploy our charm to append
only the new configuration changes. But we don't want to destroy already
existing changes.

Upto which extension,  "juju set-config" and "juju upgrade-charm" will be
used here. Please give me a simple example if it possible.

For this Scenario, Which use-case will be generally used. Please let me
know that in a detailed manner.


Answer [by Marcoceppi]
--
In Juju, and especially with Cinder plugins, you can deploy multiple copies
of the Juju charm and relate them. Each application deployed is equivalent
to the scope of a SAN cluster:

juju deploy cinder
juju deploy your-charm san1
juju deploy your-charm san2

juju add-relation cinder san1
juju add-relation cinder san2

Now, you can configure each of the new applications, which are the same
copy of the charm deployed multiple times. This will add a unique backend
per charm copy which seems to be your intended use case

-> This use case worked for us.

But here we are deploying

But what I am asking here is,

Can I do like, Instead of deploying san1 application and san2 application
separately and adding relations separately

juju deploy cinder
juju deploy my-charm san1 san2
juju add-relation cinder san1 san1


Thanks,
Siva.


On Wed, Sep 14, 2016 at 2:17 AM, Chris MacNaughton <
chris.macnaugh...@canonical.com> wrote:

> Hey Siva,
>
>
>> But I want to know about "How can we Scale Cinder nodes
>>
>  To scale up Cinder, you should just have to deploy the Hacluster[1] charm
> and relate it to the Cinder charm. Additionally, you will need a VIP to
> assign to the hacluster charm.
>
>> as well as adding multiple storage arrays to the each  scaled cinder unit
>> horizontally".
>>
> Assuming that you have a Cinder driver for your storage array, you should
> be able to associate it as a subordinate charm multiple times with
> different configs. For example:
> $ juju deploy cinder
> $ juju deploy cinder_backend_array  replicated --config=replicated.yaml
> $ juju deploy cinder_backend_array non-replicated
> --config=non-replicated.yaml
> $ juju deploy cinder_backend_array dedup --config=dedup.yaml
> $ juju add-relation cinder replicated
> $ juju add-relation cinder non-replicated
> $ juju add-relation dedup
>
> This will deploy the charm 'cinder_backend_array' with different names and
> configurations, and then will add them as subordinates to the Cinder charm.
> The Cinder charm merges backends in the configuration file by using
> configuration provided through the relation with the various drivers'
> subordinate relations.
>
>>
>> Sub Question
>>
>> 
>>
>> At a time, can I deploy two storages arrays to same cinder node .
>>
> Yes,
>
>>
>> Like,
>>
>> $juju deploy cinder
>>
>> $juju add-unit cinder -n 3
>>
>> $juju deploy mystorageCharm san1 san2
>>
>> $juju add relation cinder san1 san1
>>
> but not like this, see the example above.
>
> [1]: https://jujucharms.com/hacluster/
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju