On 14/10/2013 08:31, Dan Bode wrote:> > > > On Sun, Oct 13, 2013 at 4:34 PM, Loic Dachary <loic@xxxxxxxxxxx <mailto:loic@xxxxxxxxxxx>> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
