Open Stack

Evgeniy,

I am not suggesting to go to Nailgun DB directly. There obviously should be
some layer between a serializier and DB.

On Thu, Jan 29, 2015 at 9:07 PM, Evgeniy L <eli at mirantis.com> wrote:

> Vladimir,
>
> >> 1) Nailgun DB
>
> Just a small note, we should not provide access to the database, this
> approach
> has serious issues, what we can do is to provide this information for
> example
> via REST API.
>
> What you are saying is already implemented in any deployment tool for
> example
> lets take a look at Ansible [1].
>
> What you can do there is to create a task which stores the result of
> executed
> shell command in some variable.
> And you can reuse it in any other task. I think we should use this
> approach.
>
> [1] http://docs.ansible.com/playbooks_variables.html#registered-variables
>
> On Thu, Jan 29, 2015 at 2:47 PM, Vladimir Kuklin <vkuklin at mirantis.com>
> wrote:
>
>> Evgeniy
>>
>> This is not about layers - it is about how we get data. And we need to
>> separate data sources from the way we manipulate it. Thus, sources may be:
>> 1) Nailgun DB 2) Users inventory system 3) Opendata like, list of Google
>> DNS Servers. Then all this data is aggregated and transformed somehow.
>> After that it is shipped to the deployment layer. That's how I see it.
>>
>> On Thu, Jan 29, 2015 at 2:18 PM, Evgeniy L <eli at mirantis.com> wrote:
>>
>>> 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 <vkuklin at 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 <
>>>> dshulyak at 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 <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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>> vkuklin at mirantis.com
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>> vkuklin at mirantis.com
>>
>> __________________________________________________________________________
>> 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
>
>


-- 
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
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150130/7242523a/attachment.html>