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 <e...@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 <vkuk...@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 <e...@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 <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 >>> >>> >> >> >> -- >> 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 > > -- 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