Define behaviors in OpenShift for ColdFront expired, denied and revoked

[joachimweyl]

Motivation

Currently when an allocation expires in ColdFront OpenShift is still accessible for use. We needed to decide how to communicate externally what expired means and also how we would use the denied and revoked status as well.

Completion Criteria

Document what we think should happen when an OpenShift allocation is expired, denied, or revoked.

Description

• [ ] Discuss the behaviors we want for when an allocation associated with an OpenStack project is expired, denied, or revoked
• [ ] Document desired behaviors
• [ ] Have engineers review document
• [ ] Create a GH Issue to enable these changes

Completion dates

Desired - 2024-05-29 Required - TBD

[joachimweyl]

@Milstein & @jtriley can we set these projects to denied or revoked instead of expired?

[joachimweyl]

@Milstein can you test that revoked or denied removes the whole allocation?

[msdisme]

Notes from May 15 discussion: For OpenShift, OpenStack, Openshift AI

• Define what behaviour we want for each service (expired, denied and revoked as potentially different things.)
• Have Kristi review for what is possible
• Make some decisions based on that
• @joachimweyl and @msdisme discuss how to organize for these three

[Milstein]

I will test the Denied/Revoked functionality and verify.

[msdisme]

Want to be able to turn off resources

• PI makes a change to reduce GPUs, it goes through approval, if approved change should be made on servers. Question: impact if we have to restart pod-will they reenter queue at bottom? We do not need to worry about this for adding GPUs since they will have access and will need to change YAML.

@msd flow chart with current process and proposal