Netapp RPO for replicas should be longer than replica schedule

[Maurice Escher]

Hi,

I have an observation related to https://bugs.launchpad.net/manila/+bug/1996750

I noted that the 'hourly' schedule was matched with the one hour check of snapmirror last-transfer-end-timestamp in https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_base.py#L2645-L2650

But on top I think this was flawed, since it does not respect the time that the transfer itself is consuming.

E.g.
Let's assume my hourly scheduled transfer runs at 8:04.
There is not much data to copy, so it runs 1 minute -> finished at 8:05.
Next transfer runs at 9:04.
This time there is a bit more data to transfer, it runs 10 minutes until 9:14.

Manila checking at 9:10 would see the last-transfer-end-timestamp of 8:05 and report out of sync.
The RPO of a hourly schedule is higher than 1 hour.

Looking at what is done at other places I found: https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-introduction#service-level-objectives with giving an RPO of double the time set of the schedule, which makes sense to me. The more often the transfer runs, the less data it has to copy and the faster it completes.

I assume the configurable schedule (fix of bug 1996750) lands, so the RPO can't stay hardcoded anyway.
I suggest to either make the RPO configurable (and document with some hints) or calculate it based on the schedule.

Best,
Maurice

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/manila/+/866883

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/manila 17.0.0.0rc1 release candidate.