Mechanism to allow the driver to ensure shares, as invoked from the API layer.

Ceph Mon address is never re-validated other than when we call the ensure shares mechanism, currently only in the driver startup. The idea consists of providing an API to allow administrators to invoke ensure shares, which would mean that the mon address would be re-validated.

This issue was discussed during the Caracal PTG and we mentioned we are willing to propose a specification to document the behavior of such API. This is request also has an upstream tracker [1].

[1] https://bugs.launchpad.net/manila/+bug/1996793

 

What are the use cases this RFE is solving?

Ensure shares is a functionality in the manila share manager that will make drivers update the shares' data in case there are configuration updates that should be reflected in the shares and their access rules.This functionality is currently only invoked when we restart the manila-share service.

 

This RFE focuses on allowing administrators to have their share configuration updated without having the need to restart the manila-share service, which can be a costly and disruptive operation by providing a new API. 

 

High Level view on how the feature works

Administrators will be able to send an API request or issue a CLI command to run the ensure shares routine for a specific share backend. The backend will then start to look through its shares and apply any possible new configuration (i.e. update shares export locations in case an IP has changed after the configuration was initially performed).

 

Is this feature driver dependent or driver related?

No, this feature will be added to the Manila API, and all drivers that implement the ensure_shares routine will be able to benefit from it.

 

Are there any known limitations? (e.g multi attach + encryption)

No.

 

Is a CLI change required, does the openstack cmd support it?

Yes.

 

Does this RFE impact / need to be included into the control plane podification?

No.

 

Does this RFE benefit/impact DCN?

No.

 

Does this RFE benefit/impact shift on stack?

No.

 

Can this feature be turned on or used in an existing environment?

 

Does this feature affect another DFG or product?

No.

 

Does this feature depend on another RFE?

No.

 

How will the feature affect Upgrades?

This feature can help upgrades to run smoothly, as the ensure shares can be issued manually.

 

How will the feature affect performance or scaling?

No.

 

What are the test cases for this RFE?

Issuing ensure shares and ensuring that the most recent configuration is updated after the task ends, and ensuring that the operation can't be issued more than once.

 

Are there CI implications?

Ensure share tests could fail if running concurrently with other tests.

 

Does it have documentation impact and require early planning with the doc team?

Yes

 

Are there known packaging challenges?

No.

 

Are there any security considerations?

This is going to be an administrator-only feature, so we need to ensure we have RBAC policies in place.

 

How much upstream resistance might there be to this feature?

Some parts of this implementation as is currently proposed could cause issues, for example if we intend to change the status of all shares when we issue the ensure shares. There might be resistance to technical details like this in the implementation and we might need to think about alternative approaches for avoiding operations running concurrently.

 

Will this feature require new or different support skills?

Yes.

 

Will this be required for knowledge transfer to GSS?

Yes.

 

Will this feature impact existing partners or certification programs?

Partners would need to run the tests we implement in manila-tempest-plugin and ensure that when the API is issued, their backends are responding to the operation and performing the config updates if necessary.

 

API Deprecation/Compatibility?

No.

 

Are any GUI impact/changes required (Horizon)?

Yes.