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 ? Cheers -- Loïc Dachary, Artisan Logiciel Libre All that is necessary for the triumph of evil is that good people do nothing.
signature.asc
Description: OpenPGP digital signature
