Description of problem: With OSP12, cinder volume is tech preview. We had deployed a custom cinder volume container with vnx backend, Cinder was running as a container AND as a service in the controller node. he attachment request was intercepted and processed by the openstack-cinder-volume service on the controller host. I shutdown the service and voila everything worked. The attachment request was intercepted and processed by the openstack-cinder-volume service on the controller host. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1422699 [details] containerized cinder
Created attachment 1422700 [details] deploy
Created attachment 1422701 [details] env
Rajini, can you explain how this is related to openstack-tripleo-validations? Thanks!
May be not. It is a deployment issue with the director or tipleo may be. I'm not able to change the component, can alan or you change it to the right one
I confirmed this is an issue that affects all containerized Cinder deployments that use a Cinder backend template in puppet/services, and recommend this be treated as an OSP-13 blocker. I already have a fix to submit upstream.
Doc text coming soon.
This is the systemctl output : [root@controller-0 ~]# systemctl status openstack-cinder-volume.service ● openstack-cinder-volume.service - OpenStack Cinder Volume Server Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-volume.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@controller-0 ~]# [root@controller-0 ~]# [root@controller-0 ~]# systemctl status openstack-cinder-scheduler.service ● openstack-cinder-scheduler.service - OpenStack Cinder Scheduler Server Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-scheduler.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@controller-0 ~]# [root@controller-0 ~]# [root@controller-0 ~]# systemctl status openstack-cinder-api.service ● openstack-cinder-api.service - OpenStack Cinder API Server Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-api.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@controller-0 ~]# [root@controller-0 ~]# [root@controller-0 ~]# systemctl status openstack-cinder-backup.service ● openstack-cinder-backup.service - OpenStack Cinder Backup Server Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-backup.service; disabled; vendor preset: disabled) Active: inactive (dead) But while running ps -ef I still see the following processes : [root@controller-0 ~]# docker ps |grep cinder d85d44d8e98a 192.168.24.1:8787/rhosp13/openstack-cinder-backup:pcmklatest "/bin/bash /usr/lo..." 21 minutes ago Up 21 minutes openstack-cinder-backup-docker-0 38afad810209 192.168.24.1:8787/rhosp13/openstack-cinder-volume:pcmklatest "/bin/bash /usr/lo..." 22 minutes ago Up 22 minutes openstack-cinder-volume-docker-0 7618316fd8a7 192.168.24.1:8787/rhosp13/openstack-cinder-api:2018-05-01.6 "kolla_start" 24 minutes ago Up 24 minutes cinder_api_cron cc31ede996d0 192.168.24.1:8787/rhosp13/openstack-cinder-scheduler:2018-05-01.6 "kolla_start" 24 minutes ago Up 24 minutes (healthy) cinder_scheduler d3bb6b6c55b4 192.168.24.1:8787/rhosp13/openstack-cinder-api:2018-05-01.6 "kolla_start" 25 minutes ago Up 25 minutes cinder_api is it OK ?
This setup was configured with VNX backend enabled
Yes, this looks good! But as we just discussed, it would be great if you could repeat the test on a previous puddle, just to confirm your test methods confirm the problem is visible in a version that doesn't contain the fix.
verified RPM package version openstack-cinder-12.0.1-0.20180418194613.c476898.el7ost.noarch after installation using VNX backend template No duplicated Cinder services was enabled and run on the controller The non relevant parameters in the configuration of cinder.conf have not been added to.
Do we need analog BZ for manila and neutron? These are the other 2 components in OSP12 that were left as service.
Alan says - he checked the other storage back ends (namely manila) and they are OK. I do not know about non-storage services. This does not affect Ceph deployments.
The issue with the cinder backend templates was they "activated" (via puppet-tripleo) the cinder-volume service, and the fix was to remove the lines that did that. My audit of the manila templates don't indicate a problem. The manila backend templates only contain hiera configuration data, and do not activate any services. I am less familiar with the neutron templates. It might be appropriate to file a BZ to spur further investigation.
Looking further, I see there are a number of "dockerized" variations of some neutron templates in docker/services (e.g. docker/services/neutron-plugin-ml2-cisco-vts.yaml). This suggests the neutron team is already aware of the situation.
OK. Sean M. can you check on neutron one?
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-2018:2086