Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Implementation Request: WaitForFirstConsumer #405

Closed
ChrisPiece opened this issue May 20, 2020 · 5 comments
Closed

Feature Implementation Request: WaitForFirstConsumer #405

ChrisPiece opened this issue May 20, 2020 · 5 comments

Comments

@ChrisPiece
Copy link

Our customer thinks that everyone would benefit from this feature WaitForFirstConsumer that help in having the compute aligned with the storage. This feature would be useful for almost anything that pulls from a DB (mongo, cassandra, elastic ...), which are generally managed by StateFulSets.

Currently, StateFulSets allows us to share computation across distributed AZs, however its PVCs always fall on the same AZ. Therefore, if that particular AZ needs maintenance or experiences an issue, the application would go down.

With WaitForFirstConsumer, the StorageClassName would be assigned based on the topology, selectors, anti-affinity policies, etc. etc. and would allow a more flexible management.
This feature is available on AWS, GCP and Azure that heavily use multi-AZs, but it would be useful for our customer environment too (and many others).

@gnarl
Copy link
Contributor

gnarl commented May 20, 2020

Does your customer have multiple on-prem NetApp backends in different AZs?

Also, from the document you linked, the volumeBindingMode is a field in the StorageClass configuration. It doesn't appear that theStorageClassName can be assigned by Trident based on topology.

@ChrisPiece
Copy link
Author

Customer is trying to move to a Multi-AZ infrastructure with multiple NetApp backends, correct.
That document lists some plugins that support WaitForFirstConsumer and they would like to implement that functionality.
Currently they use code like this:

    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: sc-dev-az1           <----- here goes the AZ, it is hardcoded.
          accessModes: ["ReadWriteMany"]
          resources:
            requests:
              storage: 40Gi

The goal would be to have a dynamic storageClassName option so that if that AZ fails, automatically the storage class could automatically switch.
They are using OpenShift 4.3 and wonder if this functionality could be integrated with Trident.

@gnarl
Copy link
Contributor

gnarl commented May 20, 2020

@ChrisPiece thanks for the additional information!

netapp-ci pushed a commit that referenced this issue Oct 7, 2020
@adkerr
Copy link
Contributor

adkerr commented Oct 23, 2020

Added in df73a8d

@adkerr adkerr closed this as completed Oct 23, 2020
@gnarl
Copy link
Contributor

gnarl commented Oct 23, 2020

This feature will be available in the Trident 20.10.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants