Reload operation isn't executed for pacemaker cluster resource agents supporting the reload op.

Bug #1448160 reported by Sergey Kolekonov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Released
High
Sergey Kolekonov
5.1.x
Won't Fix
Medium
Denis Meltsaykin
6.0.x
Won't Fix
Medium
Denis Meltsaykin

Bug Description

release: "6.1"
openstack_version: "2014.2-6.1"
api: "1.0"
build_number: "310"
build_id: "2015-04-13_22-54-31"
nailgun_sha: "d22c074dec091e5ddd8ea3003c37665058303cd5"
python-fuelclient_sha: "9208ff4a08dcb674ce2df132399a5aa3ddfac21c"
astute_sha: "d96a80b63198a578b2c159edbd76048819039eb0"
fuellib_sha: "8b80657e9ceed8d59c2dff1c11e1481c7e69380e"
ostf_sha: "c2a76a60ec4ebbd78e508216c2e12787bf25e423"
fuelmain_sha: "335d3ed09ed79bd37e1f7a90442c4831c8845582"

HAProxy resource supports reload operation, however this operation doesn't work.

How to reproduce:
- deploy a cluster
- add a simple check to the haproxy OCF script (ns_haproxy), e.g.
  touch /root/check_haproxy
  to haproxy_reload() function
- change any parameter marked as "unique=0":
  pcs resource update p_haproxy debug=true

Pacemaker should call haproxy_reload() function, but it won't.
I've found out that Pacemaker doesn't use reload operation for resources which don't have at least one option marked as "unique=1".

summary: - Reload operation is broken for HAProxy cluster resource
+ Reload operation isn't executed for HAProxy cluster resource
Changed in fuel:
assignee: nobody → Sergey Kolekonov (skolekonov)
Changed in fuel:
status: New → Confirmed
importance: Undecided → High
milestone: none → 6.1
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-library (master)

Fix proposed to branch: master
Review: https://review.openstack.org/177304

Changed in fuel:
status: Confirmed → In Progress
Revision history for this message
Bogdan Dobrelya (bogdando) wrote : Re: Reload operation isn't executed for pacemaker cluster resources

This applies as well for the rest of RA Fuel configures, such as RabbitMQ OCF. Good point to address, thank you!

summary: - Reload operation isn't executed for HAProxy cluster resource
+ Reload operation isn't executed for pacemaker cluster resources
Revision history for this message
Bogdan Dobrelya (bogdando) wrote :

Please elaborate, why the reload op is required and what is the impact if we don't have it?

Revision history for this message
Bogdan Dobrelya (bogdando) wrote :

IIUC, this is an issue only for ns_haproxy agents RA? I guess this issue should not be fixed for other RA as they do not support reload op...

summary: - Reload operation isn't executed for pacemaker cluster resources
+ Reload operation isn't executed for pacemaker cluster resource agents
+ supporting the reload op.
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :

The reload operation is optional, it just allows to apply updated parameters to resource if it supports it.
For HAProxy, for example, it would be possible to enable or disable debug mode on-the-fly.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to fuel-library (master)

Reviewed: https://review.openstack.org/177304
Committed: https://git.openstack.org/cgit/stackforge/fuel-library/commit/?id=c1fbb3b9b2771142b8015415e76567c5e0235922
Submitter: Jenkins
Branch: master

commit c1fbb3b9b2771142b8015415e76567c5e0235922
Author: Sergey Kolekonov <email address hidden>
Date: Fri Apr 24 18:07:03 2015 +0300

    Add a dummy parameter for HAProxy resource

    HAProxy resource supports reload operation but currently Pacemaker doesn't use
    it if one of the unique parameters is changed. It was discovered that
    a resource needs at least one parameter marked as unique=1.
    Adding such dummy parameter to keep all current parameters unchanged and solve
    the problem.

    Change-Id: I54b7f838c9592736e61d997d30a15497e5c31604
    Closes-bug: #1448160

Changed in fuel:
status: In Progress → Fix Committed
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :

Bogdan, you're right, this issue is valid only for RAs which already support reload operation.

Revision history for this message
Kristina Berezovskaia (kkuznetsova) wrote :

Verify:

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "6.1"
  openstack_version: "2014.2.2-6.1"
  api: "1.0"
  build_number: "432"
  build_id: "2015-05-18_03-43-53"
  nailgun_sha: "076566b5df37f681c3fd5b139c966d680d81e0a5"
  python-fuelclient_sha: "38765563e1a7f14f45201fd47cf507393ff5d673"
  astute_sha: "cb655a9a9ad26848bcd9d9ace91857b6f4a0ec15"
  fuel-library_sha: "1621cb350af744f497c35f2b3bb889c2041465d8"
  fuel-ostf_sha: "9ce1800749081780b8b2a4a7eab6586583ffaf33"
  fuelmain_sha: "0e970647a83d9a7d336c4cc253606d4dd0d59a60"
neutron+vlan+centos, 3 controllers, 1 compute

Steps:
1) deploy a cluster
2) add in /usr/lib/ocf/resource.d/fuel/ns_haproxy to haproxy_reload() function "touch /root/check_haproxy"
3) pcs resource update p_haproxy debug=true

Changed in fuel:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-library (stable/5.1)

Fix proposed to branch: stable/5.1
Review: https://review.openstack.org/239457

Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

Marking as Won't Fix for 5.1.1-updates as we have no way to deliver fuel-library updates in the scope of MU for 5.1.1.
Also lowering the importance to medium: it's not a "customer-found" bug and barely affects already deployed clouds in a significant way.

Revision history for this message
Vitaly Sedelnik (vsedelnik) wrote :

Won't Fix for 6.0-updates as well for the same reason as 5.1.1

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on fuel-library (stable/5.1)

Change abandoned by Denis V. Meltsaykin (<email address hidden>) on branch: stable/5.1
Review: https://review.openstack.org/239457
Reason: There is no delivery channel for fuel-library fixes in 5.1/5.1.1

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.