Open Stack

Thank you guys for quick response.
Than, if there is no better option we will follow with second approach.

On Wed, Jan 28, 2015 at 7:08 PM, Evgeniy L <eli at mirantis.com> wrote:

> Hi Dmitry,
>
> I'm not sure if we should user approach when task executor reads
> some data from the file system, ideally Nailgun should push
> all of the required data to Astute.
> But it can be tricky to implement, so I vote for 2nd approach.
>
> Thanks,
>
> On Wed, Jan 28, 2015 at 7:08 PM, Aleksandr Didenko <adidenko at mirantis.com>
> wrote:
>
>> 3rd option is about using rsyncd that we run under xinetd on primary
>> controller. And yes, the main concern here is security.
>>
>> On Wed, Jan 28, 2015 at 6:04 PM, Stanislaw Bogatkin <
>> sbogatkin at mirantis.com> wrote:
>>
>>> Hi.
>>> I'm vote for second option, cause if we will want to implement some
>>> unified hierarchy (like Fuel as CA for keys on controllers for different
>>> env's) then it will fit better than other options. If we implement 3rd
>>> option then we will reinvent the wheel with SSL in future. Bare rsync as
>>> storage for private keys sounds pretty uncomfortable for me.
>>>
>>> On Wed, Jan 28, 2015 at 6:44 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I want to discuss the way we are working with generated keys for
>>>> nova/ceph/mongo and something else.
>>>>
>>>> Right now we are generating keys on master itself, and then
>>>> distributing them by mcollective
>>>> transport to all nodes. As you may know we are in the process of making
>>>> this process described as
>>>> task.
>>>>
>>>> There is a couple of options:
>>>> 1. Expose keys in rsync server on master, in folder /etc/fuel/keys, and
>>>> then copy them with rsync task (but it feels not very secure)
>>>> 2. Copy keys from /etc/fuel/keys on master, to /var/lib/astute on
>>>> target nodes. It will require additional
>>>> hook in astute, smth like copy_file, which will copy data from file on
>>>> master and put it on the node.
>>>>
>>>> Also there is 3rd option to generate keys right on primary-controller
>>>> and then distribute them on all other nodes, and i guess it will be
>>>> responsibility of controller to store current keys that are valid for
>>>> cluster. Alex please provide more details about 3rd approach.
>>>>
>>>> Maybe there is more options?
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/f36dd2ec/attachment.html>