Problem

When modifying an R2 (replicated) volume, the operation was blocked by the Authorization service.

The root cause: The R2 volume was created directly by PowerMax (via a replication policy on R1’s storage group) and not by the CSI driver.

As a result, the Authorization database (Redis) did not have ownership information about the R2 volume.

When the CSI driver later detected the R1 was replicated, it located the R2 and tried to give it the same volume label as R1. This label update failed because Authorization denied the request due to the missing Redis entry.

Fix

We introduced two key changes:

1. Bypass the premature Authorization check

• The driver now updates the R2 volume label only after it is added to its default storage group.

• This ensures that the SRP and storage group context are already established, allowing the volume to be recognized properly.

2. Resequencing the workflow

• Previously: Volume rename (label update) happened too early → Authorization denied it.

Before Fix:

Step 1: Powermax creates and adds R2 to its replication storage group.
Step 2: Rename R2 to match R1’s identifier. ==> Fails, as Auth has no R2 entry in redis.
Step 3: Add R2 to its default SRP storage group. == Step fails
Step 3: Seed the Redis database with R2’s details (name, capacity, etc.). ==> Step missed

After Fix:

Step 1: Powermax creates and adds R2 to its replication storage group.
Step 2: Add R2 to its default SRP storage group.
Step 3: Rename R2 to match R1’s identifier.
Step 3: Seed the Redis database with R2’s details (name, capacity, etc.).

This guarantees Redis has the necessary information before any further operations run.

Outcome

1. With this fix, volume modifications on R2 succeed without Authorization blocking.
2. Redis is properly seeded with R2’s details.

We validated the end-to-end workflows (replication, snapshot, and expansion). All tests passed successfully.

Merging this branch will not change overall coverage