On Thu, Oct 10, 2013 at 11:43 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > > > On 09/10/2013 22:46, Loic Dachary wrote: >> >> >> On 08/10/2013 16:20, Don Talton (dotalton) wrote:> Hi Loic, >>> >> >>> We utilize stackforge's puppet modules to do our heavy lifting, including p-openstack, p-cinder, p-glance. There are dependency chains so that services will be restarted after configuration changes are made. Since many of our customers don't allow their baremetal nodes Internet access, we've added the packages to our APT repo to avoid the version issues with using either stock or public packages. >>> >>> You can probably find some other useful code the https://github.com/CiscoSystems/ repo, including what is needed to cohabitate MON/OSD nodes with OpenStack service nodes (https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph) and more. The primary orchestration is in grizzly-manifests. You can see HOWTOs for different deployment scenarios here: http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation. >>> >>> Hope this helps some! >> >> It does and it's great that all this is documented :-) Although there are a few modules around, re-using ceph-deploy seems to be the preferred method. I wonder what Alfredo would suggest. From a previous discussion we had I think he will suggest to use ceph-disk directly + cli / rest call instead. Looking at >> >> https://github.com/ceph/ceph-deploy/blob/master/ceph_deploy/new.py >> https://github.com/ceph/ceph-deploy/blob/master/ceph_deploy/mon.py >> etc. >> >> the layer provided by ceph-deploy is indeed thin. But is it something that needs to be duplicated in a puppet module ? >> > > I took a look at ceph-deploy and it won't rely on sudo if run from root > > ceph_deploy/sudo_pushy.py > def needs_sudo(): > if getpass.getuser() == 'root': > return False > return True > > and that it won't rely on ssh if the target host is localhost: > > ceph_deploy/lib/remoto/connection.py > def needs_ssh(hostname, _socket=None): > """ > Obtains remote hostname of the socket and cuts off the domain part > of its FQDN. > """ > _socket = _socket or socket > local_hostname = _socket.gethostname() > local_short_hostname = local_hostname.split('.')[0] > if local_hostname == hostname or local_short_hostname == hostname: > return False > return True > > Since puppet-cephdeploy runs on the target host as root, it means that > > puppet-cephdeploy/manifests/init.pp > file {"/home/$user/.ssh/authorized_keys": > ... > etc. > > could probably be avoided since puppet-cephdeploy/manifests/mon.pp runs > > command => "/usr/local/bin/ceph-deploy mon create $::hostname", > > runs as root, on the target host. Loic is spot on here. Yes, ceph-deploy will avoid all of those things described if they are not necessary. The one possible caveat is when there is an ~/.ssh/config that changes the login of a remote user to something else which ceph-deploy would not be able to tell. So say you have a `node1` defined in the ssh config with user `foo` but you are executing ceph-deploy as `root`, then that would mean that ceph-deploy would not run `sudo` commands in the remote host because it assumes the ssh is happening with root. If the manifest is doing all of this work locally, then this is not a problem, but something to be aware of. > > I'm not sure if the distribution of the keys would work though as it relies on files collected by "gatherkeys" which is still a little mysterious for me :-) gatherkeys will just go to standard locations and look for the generated keys and copy them back to where ceph-deploy is executing from. Really nothing complex is happening there. > > Cheers > > -- > Loïc Dachary, Artisan Logiciel Libre > All that is necessary for the triumph of evil is that good people do nothing. > > > > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
