Bug 1568120
| Summary: | Cinder volume incorrectly deployed as both service and container | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Rajini Karthik <rajini.karthik> | ||||||||
| Component: | openstack-tripleo-heat-templates | Assignee: | Alan Bishop <abishop> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Tzach Shefi <tshefi> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 12.0 (Pike) | CC: | aavraham, abishop, arkady_kanevsky, audra_cooper, cdevine, christopher_dearborn, cschwede, david_paterson, dcain, flfuchs, jjoyce, jschluet, knylande, kurt_hey, mburns, morazi, rajini.karthik, randy_perryman, scohen, slinaber, smerrow, sreichar, sumedh_sathaye, tshefi, tvignaud | ||||||||
| Target Milestone: | beta | Keywords: | Triaged | ||||||||
| Target Release: | 13.0 (Queens) | Flags: | abishop:
needinfo-
|
||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | openstack-tripleo-heat-templates-8.0.2-9.el7ost | Doc Type: | Bug Fix | ||||||||
| Doc Text: |
The Heat templates for Cinder backend services were triggering Puppet to deploy the cinder-volume service on the overcloud host, regardless of whether the service is meant to be deployed in a container. This caused the cinder-volume service to be deployed twice: in a container as well as on the host.
Because of this, the OpenStack volume operations (such as creating and attaching a volume) would occasionally fail when the operation was handled by the rogue cinder-volume service running on the host.
As a result, the Cinder backend heat templates have been updated to not deploy a second instance of the cinder-volume service.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2018-06-27 13:51:11 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1419948, 1458798 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Rajini Karthik
2018-04-16 19:10:53 UTC
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 |