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