Temporary project set provisioning

[mtspn]

Describe the issue Implement a new type of temporary project set in the registry that exists for a short time period before being automatically deleted. I suggest 30 days. We could consider allowing users to choose their own time span for their temporary project sets.

Additional context This could enable:

• Self-serve training environments. Participants in our OpenShift 201 training could create their own training project sets. This would eliminate some of the manual work described in #1010, and replaces that ticket. Currently OpenShift 201 reserves 26 project sets full time, and these are reallocated to students as needed. Given that the current 201 training runs on alternating months, switching to temporary namespaces with a 30 day expiry before deletion could reserve less resources overall.
• Future training - we could design training with this self-serve option in mind. This could allow students interested in asynchronous OpenShift 101 to register for their own project sets as needed.
• General sandboxing benefits. Sometimes users request project sets for sandboxing/testing. Rather than creating permanent project sets for this purpose, time limited project sets may use less resource overall.

Additional considerations/decisions:

• Should temporary project sets come with all the same licenses as a regular project set? Are there are any licensing considerations when introducing short-term project sets?
• Does this need to be available on all clusters? Silver would be adequate for training needs, but maybe there is a benefit to having this feature available on other clusters too?

How does this benefit the users of our platform?

• Better and more flexible training and sandboxing capacity, self service
• Less resource waste due to 30 day cleanup

Definition of done

• Temporary project set request option added to product registry interface
• Create automation that can associate an end/cleanup date with a project set, test automated cleanup
• Enable this feature, promote this sandboxing functionality and adopt for OpenShift 201 training
• An email notification is sent to a user 10 days/5 days/1 day before the deletion to let them know that a namespace will be deleted

[Amritpal-Nijjar]

1 problem I foresee is that creating new products and deleting these products is that it would count towards the statistics that is currently being generated. The analytics page currently keeps track of all products past and present, so with this change we would see bumps in the charts of training products being created and deleted in timely waves. I am unsure if this is something we want to separate out from real products vs training products. We can combat this issue by flagging each training product as a "training set" so that it can be separated from non training sets. This could also open the opportunity of tracking statistics regarding training...

[Amritpal-Nijjar]

e.g

[mtspn]

Thanks @Amritpal-Nijjar, the image link is broken there but I see what you're saying. I think it would be good if we could separate out training and sandbox projects - as I understand these are all also counted as 'products' in analytics too?

[Amritpal-Nijjar]

That is correct, the analytics page counts everything, but because training namespaces are being reused for every training cohort, we do not currently see this wave of create/delete on the analytics page. Separating out training and sandbox projects will make our analytics much more accurate/representative overall.