Red Hat Bugzilla – Bug 1417645
[RFE] Containerized deployment of Cinder service
Last modified: 2018-02-05 14:04:43 EST
Provide customers more stable, flexible, reliable and faster deployments with more reliable and flexible lifecycle management and possibility to rollback when something goes wrong.
Changing to ON_DEV - work already in progress.
Add OS-brick gerrit, track all the cinder containerization patches here: - cinder API - iscsid - multipathd - cinder volume - cinder scheduler - cinder backup
Moving back to ON_DEV as we've identified 3 patches that are required for the feature to work. [1] and [2] are required for HA, are already on stable/pike, and just need to be pulled down to osp-12. [3] was recently posted to upstream master. This is why ON_DEV and not POST. [1] https://review.openstack.org/518854 [2] https://review.openstack.org/518855 [3] https://review.openstack.org/520787
(In reply to Alan Bishop from comment #11) > Moving back to ON_DEV as we've identified 3 patches that are required for the > feature to work. > > [1] and [2] are required for HA, are already on stable/pike, and just need to > be pulled down to osp-12. > > [3] was recently posted to upstream master. This is why ON_DEV and not POST. > > [1] https://review.openstack.org/518854 > [2] https://review.openstack.org/518855 > [3] https://review.openstack.org/520787 [4] https://review.openstack.org/521102 (this is stable/pike version of [3])
I was asked to summarize a few key points regarding this RFE. - In a stock OSP-12 deployment, most services are containerized but cinder services are not. I do not believe OSP-12 supports a completely non- containerized deployment (everything on baremetal). - You enable the containerized cinder feature by overriding a handful of TripleO Heat resources used to deploy the overcloud. - You do not control the feature by making post-deployment configuration changes. - It's best to use a fresh deployment, and not try to update an existing overcloud deployment. You enable containerized cinder services by including the following lines in an existing THT environment file, or by creating a new file and referencing it in your overcloud deployment command: resource_registry: OS::TripleO::Services::CinderApi: /usr/share/openstack-tripleo-heat-templates/docker/services/cinder-api.yaml OS::TripleO::Services::CinderScheduler: /usr/share/openstack-tripleo-heat-templates/docker/services/cinder-scheduler.yaml OS::TripleO::Services::CinderVolume: /usr/share/openstack-tripleo-heat-templates/docker/services/cinder-volume.yaml OS::TripleO::Services::Iscsid: /usr/share/openstack-tripleo-heat-templates/docker/services/iscsid.yaml The next issue is ensuring the required containers are available for the deployment. TripleO Pike deployments require you supply a file that specifies the docker container image name and registry location for all containerized services. Upstream documentation [1] describes how to create this file, and the file is automatically generated by deployment tools like TripleO Quickstart and Infrared. I do not know what the downstream (OSP) documentation looks like, or how the information should be conveyed to partners who are using this RFE to develop containerized versions of their own cinder drivers. [1] https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/overcloud.html
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/RHEA-2017:3462