Manila allows the creation of unlimited share replicas

[Carlos Eduardo]

Currently, Manila allows the user to create an unlimited number of share replicas of a given share. It can have a negative impact in the backend.

Steps to reproduce the issue:
  - Create a share
  - Create lots of share replicas of the created share

Expected behavior:
Manila should not allow the creation of unlimited share replicas. It can deplete storage resources.

[Jason Grosso (jgrosso)]

Carlos so do you think we need to limit the number of share replicas based on the storage resources or a flat limit per share?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/696136

[Carlos Eduardo (silvacarlose)]

Hi, Jason. Sorry for the delay to answer your question. I think we should add a limit of replicas that a given share can have, and we can achieve this by implementing a new share type extra spec called 'max_replica_per_share'. So in this way, we will have the possibility to set the max limit of replicas that shares created under that share type can have and we will prevent the creation of unlimited replicas per share.

[Maurice Escher (maurice-escher)]

Hi Carlos, I would prefer to have a solution based on the quota system. To me as an administrator this would be more flexible especially with regards to capacity planning

[Carlos Eduardo (silvacarlose)]

Hi, Maurice! Thanks for you suggestion. We have had some discussions regarding this bug. It was also a topic in our virtual PTG. We have talked about a solution to this using both quota system and the aforementioned [1] solution. The results of the discussion are available in [2], where we have added the pros and cons of each implementation. It would be great if you take a look and share you toughts.

[1] https://bugs.launchpad.net/manila/+bug/1850545/comments/3
[2] https://etherpad.openstack.org/p/shanghai-ptg-manila-virtual

[Maurice Escher (maurice-escher)]

Hi Carlos, thanks for providing the details about the discussion.

Thinking again I come to the conclusion that both options are not mutually exclusive. I would like to have both.
A). max_replica_per_share as an extra spec of the share type would be good to reflect the backend limitation with proper transparency to end users and error messages.

Quotas alone could not do this (only by having a replicas_per_share quota with some extra system preventing the share admin to give out a higher quota - doable, but this flexibility per project is not needed imho).

B). But a quota of share replicas per *project* would be useful for planning - as an admin I need to know, how much capacity do I have to reserve for replicas in my backends. And I would have the possibility to bill the demand of an end-user on his replica quota reservation (better than apportion costs to all end-users who may or may not use this feature and also better than billing only the usage of existing replicas)

A) would be mandatory to solve the problem, B) would be very useful for production readiness

[Carlos Eduardo (silvacarlose)]

Great, Maurice! Thanks for your suggestions.
We intend to discuss more about this in the tomorrow's (1/30/2020) weekly meeting, and it would be nice to have you there.

[Goutham Pacha Ravi (gouthamr)]

Share replicas were added to quota control in the Ussuri release. You may use API version 2.53 to view/manipulate "share_replicas" and "replica_gigabytes" quotas for a given project, or a project user or a share type. Default values for these quotas can be configured in manila.conf.

While this allows some amount of control to cloud administrators, it may not suffice to complete the user experience, because the number of replicas is usually constrained by the kind of backend used, or the configuration of the deployment's replication_domain. So, this enforcement needs to be further done through share types and tenant visible extra specs.

The design for that feature is here: https://blueprints.launchpad.net/manila/+spec/limit-share-replicas-per-share

I'll mark this bug closed, because the premise of this bug is no longer true, as of Ussuri:

Manila: https://review.opendev.org/712675/
Python-manilclient: https://review.opendev.org/712677/