OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

Peer-pods is intended as a dev preview in OCP4.12 and later on to move to tech preview and GA. 

Today OpenShift Sandboxed Containers (OSCs) based on nested virtualization or bare metal (similar to CNV) for spinning up VMs (via QEMU). OSC using nested virtualization is only for poc/test/dev and not for production deployments. OSC on bare metal is officially supported for production deployments (from OCP4.10). Bare metal deployments in practice are a fraction of the total OCP clusters that RH customers deploy.

This makes it harder for the OSC solution to target potential customers who require support for public cloud/VMware

Challenges with running OSC on public cloud (or 3rd party hypervisors)

• Can be run on bare metal cloud instances however costly
• AWS (the major OCP public cloud) doesn’t support nested virtualization 
• RH doesn’t support nested virtualization over a non RHEL host (Azure and GCP for example) 

So how can we run OSC on a public cloud (or VMware) without nested?

• By invoking the cloud provider APIs directly to create VMs on their hypervisor
• Connecting those VMs to the OpenShift cluster (worker) VMs in a seamless way 
• This is the essence of the peer pods project, ** a joint effort from RH and the IBM-Z team who plan to use it in the IBM cloud

The following diagram shows the peer pods solution in comparison to the bare metal and nested solutions: 

Why is this important?

Peer pods will make the OSC solution accessible for customers who have OSC deployed on cloud. Creating sandboxed containers by using the peer-pods approach will have no dependencies on baremetal or nested virtualization in public cloud or VMware.

User Stories

1. As a cluster admin I should be able to configure the peer-pods approach for creating sandboxed containers using OSC operator
2. As a cluster admin I should be able to limit the number of peer-pods that can be created.
3. As a cluster admin I should be able to create the POD VM image (AWS AMI or VMware image) with required dependencies and able to configure the same for usage
4. As a cluster admin I should be able to specify the POD VM instance size
5. As a user I should be able to create sandboxed containers on AWS using peer-pods capability
6. As a user I should be able to create sandboxed containers on VMware using peer-pods capability
7. As a user I should be able to run my container image builds on a sandboxed container created using the peer-pods approach
8. As a user I should be able to deploy privileged PODs using the peer-pods approach
9. As a user I should be able to deploy multiple container PODs using the peer-pods approach
10.  

Acceptance Criteria

• Successful creation and deletion of Kubernetes Deployment, Job and Service (ingress, load-balancer) objects using peer-pods approach on AWS and VMware
• Proper cloud resource cleanup on removal of the CRD and K8s objects
• Configured resource limits enforced successfully
•  

Dependencies (internal and external)

External Dependencies

1. Kata remote hypersivor support merged upstream
2. Any CRIO fixes required for peer-pods merged upstream and available with the targeted version for OCP 4.12

Internal Dependencies

1. Creating kata rpm package with remote hypervisor support
2. CPaaS/dowstream build setup for the peer-pod components 

Limitations

• No hotplug support for any resources
• Support for only single instance size for all PODs
• No persistent volume support
• POD metric will not show accurate resource utilisation
• No support for horizontal and vertical autoscaling based on metrics
•  

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>