On 14/10/2013 08:31, Dan Bode wrote:> > > > On Sun, Oct 13, 2013 at 4:34 PM, Loic Dachary <[email protected] > <mailto:[email protected]>> wrote: > > Hi Dan, > > I'm looking for the path of least resistance to add rbd support to > https://github.com/CiscoSystems/openstack-installer/ Being unfamiliar with > the data oriented approach it would be great to get your advice on the > following. > > > * assume ceph has already been installed without cephx which simplifies > configuration. From the point of view of integration tests it means > installing when vagrant is setup ( which I currently rely on ) or via > https://github.com/CiscoSystems/openstack-installer/tree/master/stack-builder. > Not sure if the post_config is where it > > should be installed for test purposes. Not sure how to let it know what > IP to use. > > > I would really prefer not to use post_config for this purpose. I would much > rather encode this logic into Puppet so that it's more consistent with the > overall framework. It would be ok, even if the Puppet class simply wrapped > your provided script, and long as the script arguments are provided as class > parameters. I've copied Don on this thread to see if perhaps he already had > Puppet content in mind for the configuration your script is performing: > > This is a bit more work, but provides the following advantages: > - all data related to the ceph configuration being done by your script can be > provided as a regular part of the data hierarchy (this answers your question > related to where you set the ip) > - the data framework can be used to configure whether or not this > configuration is applied to a node. (from a testing perspective, I want > whether or not to run tests for the ceph deployment to be a configuration > setting for the deployment process, so that we can choose to deploy the > 2_role configuration, and select ceph or some other backend for testing)
I better understand the approach and it makes sense. > > I could add this to cinder + nova because it's needed by both. > > > do you mean add it to the stackforge modules? Yes. At the moment they assume /etc/ceph/ceph.conf already exists. It implies either that ceph is deployed with a puppet module or that the ceph deployment tool has access to cinder and nova hosts to write the /etc/ceph/ceph.conf. It looks like it would make sense to add a list of monitors # [*rbd_mon_host*] # (optional) The list of mons IPs # and if set https://github.com/stackforge/puppet-cinder/blob/master/manifests/volume/rbd.pp would create /etc/ceph/ceph.conf. The same could be done for nova. > I suppose it's what should be done since openstack-installer has no > template at the moment. > > [global] > mon host = 192.168.242.100 > > * setting the default parameters > > diff --git a/data/hiera_data/user.common.yaml > b/data/hiera_data/user.common.yaml > index 349eb1a..c38a0a4 100644 > --- a/data/hiera_data/user.common.yaml > +++ b/data/hiera_data/user.common.yaml > @@ -48,3 +48,7 @@ swift_service_password: swift_pass > swift_hash: super_secret_swift_hash > glance::backend::swift::swift_store_key: secret_key > glance::backend::swift::swift_store_auth_address: '127.0.0.1' > + > +cinder::volume::rbd::rbd_pool: 'rbd' > +cinder::volume::rbd::glance_api_version: '2' > +cinder::volume::rbd::rbd_user: 'no cephx' > > > > I would rather this not be applied to the user common configuration. In > general, I intended for things in the user*.yaml files to be things that a > user provides (as opposed to things that need to be set by default for a > certain deployment model) > > I was discussing where this configuration goes with Don on Friday. There are > two possible options: > > 1. The following lines > (https://github.com/CiscoSystems/openstack-installer/blob/master/manifests/setup.pp#L72-L73) > can already be used to specify default configuration that should be applied > when you select ceph as either the backend for glance or swift. In that case, > it should be provided in: > > data/hiera_data/cinder_backend/rbd.yaml > and > data/hiera_data/glance_backend/rbd.yaml > > This way, that data is set when you select ceph as the backend for either of > these services. > > The disadvantage is that you would have to duplicate the same data in both > files (b/c a user could select ceph as the backend for glance or cinder or > both). > > 2. The other alternative, is to create a new global_hiera_param that can be > used to enable ceph, then set ceph specific data based on that variable: > > data/hiera_data/ceph_enabled/true.yaml > > Out of those two options, I prefer #1 (b/c we don't have to add anything new > to our hierarchy) I created a pull request to support this thread with actual diffs. https://github.com/CiscoSystems/openstack-installer/pull/150/files The glance parameters are not exactly the same as the cinder parameters. How should hiera_data/glance_backend/rbd.yaml be referenced when specifying the glance backend ? The logic is in place for cinder bus/t I'm not sure how this should be done for glance. 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
