On Thu, Oct 10, 2013 at 11:43 AM, Loic Dachary <l...@dachary.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
