Description of problem: rdomanager-oscplugin always sets the GlanceBackend variable directly, overriding the default or anything set by environment files. It only supports two options, either 'rbd' or 'swift', which it automatically selects depending on CephStorageCount variable. This prevents customization of the GlanceBackend variable. Effects include: * Not being able to deploy Glance with NFS backend (not being able to set 'file' for GlanceBackend). * Not being able to deploy Glance with Swift backend when the deployment contains some Ceph nodes (e.g. Glance on Swift and Cinder on Ceph is an impossible combination if i understand correctly). Expected results: It shouldn't be assumed that only valid choices for GlanceBackend are 'rbd' and 'swift' and customization of the variable should be allowed. (This problem is probably not be specific to the GlanceBackend variable, there might be other cases when the default selection made by rdomanager-oscplugin might not be suitable for particular uses). A solution for keeping the current rdomanager-oscplugin default behavior while allowing users to customize things would be to implement a parameter passthrough to heat stack-create (a "-P" passtrhough, similarly like oscplugin already supports a "-e" passthrough for environment files).
A possible workaround could be to deploy using "heat stack-create" instead. The main disadvantage of this is that the deployer would have to set *all* the parameters that the CLI sets automatically, but on the other hand we could provide an environment file with most of those parameters set.
I managed to do a POC deploy without the deploy command. My rough writeup is here: https://gist.github.com/d0ugal/2221370c5e1acb8a8aef This could be written up in such a way that it is relatively easy to work with.
Copy-pasting example deployment commands. To deploy with defaults -- Cinder on LVM (aka iscsi backend) and Glance on Swift: openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 To deploy Cinder and Glance and Nova ephemeral on Ceph: openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 --ceph-storage-scale 1 -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml To deploy other configurations, users would copy and customize the storage-environment.yaml file mentioned above. See [6] for an example NFS backend configuration (note that you need to have the NFS exports prepared, they're not managed by OSP-d). Then this would be the command to deploy: openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 -e storage-environment-nfs.yaml
The way to deploy such storage configuration with `--plan` option (Tuskar instead of directly using tripleo-heat-templates) is to update those values in tuskar's plan directly instead of using the storage-environment.yaml file. So for deploying Ceph, that would be: openstack management plan list # to find out the plan UUID openstack management plan set <PLAN UUID FROM ABOVE> \ -P Controller-1::CinderEnableIscsiBackend=false \ -P Controller-1::CinderEnableRbdBackend=true \ -P Controller-1::GlanceBackend=rbd \ -P Compute-1::NovaEnableRbdBackend=true and then: openstack overcloud deploy --plan overcloud --control-scale 1 --compute-scale 1 --ceph-storage-scale 1
(In reply to Jiri Stransky from comment #6) > Copy-pasting example deployment commands. > > > To deploy with defaults -- Cinder on LVM (aka iscsi backend) and Glance on > Swift: > > openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 > > > To deploy Cinder and Glance and Nova ephemeral on Ceph: > > openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 > --ceph-storage-scale 1 -e > /usr/share/openstack-tripleo-heat-templates/environments/storage-environment. > yaml > > > To deploy other configurations, users would copy and customize the > storage-environment.yaml file mentioned above. See [6] for an example NFS > backend configuration (note that you need to have the NFS exports prepared, > they're not managed by OSP-d). Then this would be the command to deploy: > > openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 > -e storage-environment-nfs.yaml Jiri -- can you give a link to instructions for using an NFS backend as a reply to this comment?
(In reply to jliberma from comment #8) > Jiri -- can you give a link to instructions for using an NFS backend as a > reply to this comment? Here's an example storage-environment-nfs.yaml i meant to link from comment #6: https://gist.github.com/jistr/b2c921e1e02cc8405a92 To summarize, the deployment command is: openstack overcloud deploy --templates --control-scale 1 --compute-scale 1 -e storage-environment-nfs.yaml and in storage-environment-nfs.yaml there would be: parameters: CinderEnableIscsiBackend: false CinderEnableNfsBackend: true GlanceBackend: file CinderNfsMountOptions: 'retry=1' CinderNfsServers: 192.168.122.1:/export/cinder GlanceFilePcmkManage: true GlanceFilePcmkDevice: 192.168.122.1:/export/glance GlanceFilePcmkOptions: 'context=system_u:object_r:glance_var_lib_t:s0' (The NFS mount point locations and mount options may vary depending on the deployment.)
verified in version openstack-tuskar-ui-0.3.0-15.el7ost.noarch openstack-tripleo-heat-templates-0.8.6-46.el7ost.noarch openstack-tripleo-puppet-elements-0.0.1-4.el7ost.noarch openstack-tripleo-0.0.7-0.1.1664e566.el7ost.noarch openstack-tuskar-ui-extras-0.0.4-1.el7ost.noarch openstack-tripleo-common-0.0.1.dev6-1.git49b57eb.el7ost.noarch python-tuskarclient-0.1.18-3.el7ost.noarch openstack-tripleo-image-elements-0.9.6-6.el7ost.noarch openstack-tuskar-0.4.18-3.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1624