What were you trying to do that didn't work?  When removing a location constraint and reducing clone-max for a clone set, it's expected that a STOP action to be triggered only for the host.   However, Pacemaker would issue a MOVE of the resource from one host to another and STOP the resource on another host.  This was observed in the pacemaker.log file:

Initially the clone resource db2_mount_db2fs_sharedDb has 2 location constrains on 2 hosts kmbok-srv-3 and kmbok-srv-4 and clone-max set to 2.

1. First the location constrain for host kmbok-srv-3 was deleted:

Dec 04 13:05:16.842 kmbok-srv-1 pacemaker-based     [2250947] (cib_process_request)     info: Completed cib_delete operation for section //rsc_location[@id='pref-db2_mount_db2fs_sharedDb-runsOn-kmbok-srv-3']: OK (rc=0, origin=kmbok-srv-3/cibadmin/2, version=0.1785.0)

2. Then the clone-max value for the clone resource reduced (from 2) to 1:

Dec 04 13:05:16.902 kmbok-srv-1 pacemaker-based     [2250947] (log_info)        info: +  /cib/configuration/resources/clone[@id='db2_mount_db2fs_sharedDb-clone']/meta_attributes[@id='db2_mount_db2fs_sharedDb-meta_attributes']/nvpair[@id='db2_mount_db2fs_sharedDb-meta_attributes-clone-max']:  @value=1

3. Initially Pacemaker decided to only issue the STOP action only kmbok-srv-3:
Dec 04 13:05:16.932 kmbok-srv-1 pacemaker-schedulerd[2250951] (log_list_item)   notice: Actions: Stop       db2_mount_db2fs_sharedDb:0            (                kmbok-srv-3 )  due to node availability

3. But then Pacemaker decided to do something unexpected: Move the clone resource from kmbok-srv-3 to kmbok-srv-4, and issue a stop on kmbok-srv-4:

Dec 04 13:05:16.973 kmbok-srv-1 pacemaker-schedulerd[2250951] (log_list_item)   notice: Actions: Move       db2_mount_db2fs_sharedDb:0            ( kmbok-srv-3 -> kmbok-srv-4 )

Dec 04 13:05:16.973 kmbok-srv-1 pacemaker-schedulerd[2250951] (log_list_item)   notice: Actions: Stop       db2_mount_db2fs_sharedDb:1            (                kmbok-srv-4 )  due to node availability

What is the impact of this issue to you?  The unexpected STOP and START for the other host caused issues with Db2 application since it attempted to unmount the filesystem unexpectedly.

Please provide the package NVR for which the bug is seen:  2.1.6-4

How reproducible is this bug?:  Easy to reproduce

Steps to reproduce

1. Create a cluster with 4 nodes
2. Create a clone set with location constraint defined on 2 hosts, and clone-max set to 2.  This is to control the location of the resource where it can be active on.
3. Remove location constraint on one host and reduce clone-max to 1.

Expected results: Expect that the STOP action to be issued for the host that the location constraint is removed.

Actual results: Pacemaker issued a MOVE of the resource from the removing host, and STOP action on the remaining host.