Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/2c56693d/attachment.html>