Activity log for bug #2000253

Date Who What changed Old value New value Message
2022-12-21 14:37:01 Maurice Escher bug added bug
2022-12-21 14:40:23 Maurice Escher 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_access_map for the active replica shows state 'active' share_instance_access_map for the non-active replica shows state 'queued_to_apply' get_aggregated_access_rules_state() of manila/db/sqlalchemy/models.py is always looking at all rules, even in the replication type DR case, where the rules are not in use, yet. 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_access_rules_state() method conditionally check? Or should the rules be active right at replica create time? Best, Maurice 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_access_map for the active replica shows state 'active' share_instance_access_map for the non-active replica shows state 'queued_to_apply' get_aggregated_access_rules_state() of manila/db/sqlalchemy/models.py is always looking at all rules, even in the replication type DR case, where the rules are not in use, yet. 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_access_rules_state() method conditionally check? Or should the rules be active right at replica create time? 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.
2022-12-23 11:30:24 OpenStack Infra manila: status New In Progress
2022-12-23 18:11:18 Carlos Eduardo manila: assignee Maurice Escher (maurice-escher)
2022-12-23 18:11:24 Carlos Eduardo manila: importance Undecided Low
2022-12-23 18:11:31 Carlos Eduardo manila: importance Low Medium
2023-02-24 18:45:47 Carlos Eduardo manila: milestone antelope-rc1
2023-04-13 18:37:04 Goutham Pacha Ravi manila: milestone antelope-rc1 bobcat-1
2023-06-21 19:41:42 Carlos Eduardo manila: milestone bobcat-1 bobcat-2
2023-07-27 04:56:45 Goutham Pacha Ravi manila: milestone bobcat-2 bobcat-3
2023-09-13 08:15:47 Maurice Escher manila: status In Progress Fix Committed
2023-09-21 12:28:59 Carlos Eduardo manila: status Fix Committed Fix Released