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

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

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

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