Bug 1292555
Summary: | Quickstack pacemaker puppet modules for nova causing deployment failures with rhel-osp-installer | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Dave Cain <dcain> |
Component: | openstack-foreman-installer | Assignee: | Jason Guiditta <jguiditt> |
Status: | CLOSED ERRATA | QA Contact: | yeylon <yeylon> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 6.0 (Juno) | CC: | ctatman, dcain, emacchi, markd, mburns, morazi, muafzal, rhos-maint, scohen, sreichar, srevivo, tkatarki, yeylon |
Target Milestone: | --- | Keywords: | OtherQA, Triaged, ZStream |
Target Release: | Installer | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openstack-foreman-installer-3.0.27-1.el7ost | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-02-22 12:32:38 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: | 1290684 | ||
Bug Blocks: |
Description
Dave Cain
2015-12-17 18:57:33 UTC
The suggested change seems likely harmless enough with the one caveat potentially being neutron. This installer implemented the reference architecture found here [1], and I woudl have some concern that since this neutron timeout setting would get dropped, there could be other issues if it is slow to start [1] https://github.com/beekhof/osp-ha-deploy/blob/Juno-RDO6/pcmk/neutron-server.scenario#L176 For what it's worth, we did get a successful deployment using the rhel-osp-installer after implementing the above change. However, that deployment was contingent on Bugzilla 1290684 being resolved as well. @Jason -- if there is a different change you can recommend that would not affect Neutron, please let me know and I will try it. In our environment at least, Neutron came up fine. David, Any chance you could submit a patch to the kilo branch for astapor? I just hit this on my system on Centos7 The latest pacemaker has a new error message "When using 'op' you must specify an operation name and at least one option" which was not reported before. I checked the command that was running: /usr/sbin/pcs resource create httpd systemd:httpd clone interleave=true op monitor start-delay=10s which looked ok, so I then checked how pcs was parsing this. As soon as pcs sees the clone argument, it thinks everything is a clone arg. So previously the above command was not setting up the operation correctly (start-delay was added as a clone param). Changing the command to /usr/sbin/pcs resource create httpd systemd:httpd op monitor start-delay=10s clone interleave=true Works correctly. (or fix pcs argument parsing) Pull request to fix this bug here: https://github.com/redhat-openstack/astapor/pull/567 David, If we are able to produce an updated rpm would you be able to help verify? Hi Mike, Sure can, and would be happy to kick off a new build to verify, assuming 1290684 is patched too. That bug and this one prevent deployments from occurring. Merged The patch above that removes the 'op' word means that any options passed that should be 'op' actions and parameters are now clone parameters. It will allow the install, but the pacemaker resource setup will be wrong You need to move the 'op' setup before the 'clone' setup (because pcs has some issues parsing its input) The version of astapor I am using also sometimes sends the clone parameter via the resource_params, so I stopped using operation_opts and added 'op xxx xxx=yy' into the resource_params where every I was calling generic.pp I was able to test this with the assistance of a colleague of mine and can say that builds are successful now with the rhel-osp-installer. Builds no longer fail. We even did a clean install of the database, as I seem to remember that it was required when updating the openstack-foreman-installer package. Not sure about Comment #12 from Mark though, which has merit. Will leave that analysis to others though. Marking bug VERIFIED. Hope that's the right state. 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://rhn.redhat.com/errata/RHBA-2016-0284.html |