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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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: >>>>>> [email protected]?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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 > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
