Vladimir,

It's no clear how it's going to help. You can generate keys with one
tasks and then upload them with another task, why do we need
another layer/entity here?

Thanks,

On Thu, Jan 29, 2015 at 11:54 AM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> Dmitry, Evgeniy
>
> This is exactly what I was talking about when I mentioned serializers for
> tasks - taking data from 3rd party sources if user wants. In this case user
> will be able to generate some data somewhere and fetch it using this code
> that we import.
>
> On Thu, Jan 29, 2015 at 12:08 AM, Dmitriy Shulyak <dshul...@mirantis.com>
> wrote:
>
>> 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 <e...@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 <
>>> adide...@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 <
>>>> sbogat...@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 <
>>>>> dshul...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to