Re: bootstrap failed

[Chris MacNaughton]

SSH will refuse to use a key that is not protected, if you run ‘chmod 0600 
/home/fengxia/.local/share/juju/ssh/juju_id_rsa’, that error should go away.

Chris

> On Dec 21, 2017, at 04:49, fengxia  wrote:
> 
> /home/fengxia/.local/share/juju/ssh/juju_id_rsa

-- 
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 <si...@vedams.com> 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 
>> <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-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]

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

Storage Subordinate / Interface

[Chris MacNaughton]

Hey Juju folks,

I'm considering a new Juju subordinate charm / interface that would 
provide storage with pluggable backends. In essence, this subordinate 
would provide the storage interface, which would expose a mount point to 
the associated charm. In the other end, it would require the interfaces 
for ceph-client, gluster, and potentially other backing stores.


An example charm use would be:

The PostgresQL charm would no longer need the ceph-client relation, it 
would merely need to to require the storage interface.


Any interest in something like this?

Chris


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

Re: hub github helper

[Chris MacNaughton]

That is interesting, I use the same configuration: origin is me, 
upstream is the parent fork. I didn't realize this was uncommon.


According to Github, this is the normal, expected practice: 
https://help.github.com/articles/fork-a-repo/#keep-your-fork-synced
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Charmers membership

[Chris MacNaughton]

I would like to request that I become a member of ~charmers.

I participate in the review queue as a community member already as well as 
assisting new users in #juju on freenode. I am responsible for changes to the 
storage related Open Stack charms already and have fixed critical bugs in 
charms.

Thanks!
Chris MacnNaughton


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju