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