3. What is the nature and description of the request?
PVC from Snapshot
4. How would the customer like to achieve this? (List the functional requirements here)
This feature request is to support in the scenario: We see that this could be addressed in multiple steps:
1) A cluster admin can, given a snapshot ID of a user, create a PV with this snapshot ID, and assign selector labels (as described here https://docs.openshift.com/container-platform/3.4/install_config/persistent_storage/selector_label_binding.html). Kubernetes then would provision this EBS using the specific snapshot. Users would then be able to claims this PV using the given labels.
2) A user should be able, in self service mode, to create a new PV via a PVC fom a snapshot of the underlying storage technology. The user would claim a new PVC given a snapshot ID.
Here we have to make sure that the system knows to which Namespace certain snapshots belong; e.g. by investigating Cloud Provider specific volume to snapshot relationships and K8S's PV to Namespace relationship.
3) Eventually, we would like for our users to be able to trigger the taking of a snapshot. We could imagine, by setting a new label on a PV e.g. snapshot-state = [requested | ongoing | completed]. By watching this, it could be synched with application logic that ensures that snapshots are consistent. It could then be natural to treat Snapshots as K8S API objects, which policies around their lifecylce. This would allow 2) above not to reference native snapshot IDs, but we could work with K8S labels/selectors
4. Why does the customer need this? (List the business requirements here)
The capability to take snapshots of AWS EBS is a useful and efficient way to back-up application volumes.
In OSCP, we do this regulariy, configured on an AWS level. What is very cumbersome though is to restore such snapshots; in fact, we have not found a proper way to do this.
I would like to add that for 1), that it should be only possible to claim a Persistent Volume from projects for which they were provisioned.
This bug has been identified as a dated (created more than 3 months ago) bug.
This bug has been triaged (has a trello card linked to it), or reviewed by Engineering/PM and has been put into the product backlog,
however this bug has not been slated for a currently planned release (3.9, 3.10 or 3.11), which cover our releases for the rest of the calendar year.
As a result of this bugs age, state on the current roadmap and PM Score (being below 70), this bug is being Closed - Differed,
as it is currently not part of the products immediate priorities.
Please see: https://docs.google.com/document/d/1zdqF4rB3ea8GmVIZ7qWCVYUaQ7-EexUrQEF0MTwdDkw/edit for more details.
With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant.
This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed.
If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new
Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new
As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.