access rules hanging in queued_to_apply after replica create
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Shared File Systems Service (Manila) |
Fix Released
|
Medium
|
Maurice Escher |
Bug Description
Hi,
I'm running xena with dhss=true and the netapp driver.
I have a share with an active access rule.
Now I create a replica of type DR.
Expected result: access rule stays active
Actual result: access rule is queued_to_apply
The only way to get out of this is to create any dummy access rule (and delete it).
I had a look into the database:
share_instance_
share_instance_
get_aggregated_
Not even the startup ensure loop is correcting this situation since the access_rule_state of the non-active share instance is set to 'active' (and not 'syncing')
I'm unsure about the way out: should the get_aggregated_
Best,
Maurice
P.S.: the state is only 'cosmetically' wrong, that means the rules stay correctly applied on the backend. But any client relying on the state will be misled.
description: | updated |
Changed in manila: | |
assignee: | nobody → Maurice Escher (maurice-escher) |
importance: | Undecided → Low |
importance: | Low → Medium |
Changed in manila: | |
milestone: | none → antelope-rc1 |
Changed in manila: | |
milestone: | antelope-rc1 → bobcat-1 |
Changed in manila: | |
milestone: | bobcat-1 → bobcat-2 |
Changed in manila: | |
milestone: | bobcat-2 → bobcat-3 |
Changed in manila: | |
status: | In Progress → Fix Committed |
Changed in manila: | |
status: | Fix Committed → Fix Released |
Additional thoughts: even promoting a non-active replica does not help