Preparing for adding kubevirt samples

[nirs]

Preparing for adding kubevirt samples, clean up the current samples, and change the directory layout to make it easy to add new applications and allow automated testing on all cluster and storage types.

Status:

• Tested using basic-test with Support testing any application on any k8s/ocp cluster ramen#1133
• Manual deployment on ocp

Fixes #43

[ShyamsundarR]

A few questions:

• Why is there a core subdirectory within dr and subscription directories?
• My understanding of core under root, and deployment under the same is to have another higher level directory like kubevirt with its variants within. This reduces some clutter (so that we avoid deployment/sts/daemonset within core). The issue I see is with the name core or just stashing away 3 workload types from the clutter (we will still need kubevirt at the root with it's sub-directories in there). It would be preferable to be more explicit and have deployment at the root. We can add a workloads or similar directory at the root and move all workloads within it (avoid clutter at root of the repo).

The second is more key than the first, as it impacts product documentation.

[nirs]

A few questions:

• Why is there a core subdirectory within dr and subscription directories?

We need different drpc for busybox and kubevirt, mainly because we use different pvc selector, based on appname label. We use the same drpc if we use the same appname for all samples, maybe appname: sample

For subscription I assumed we will have few differences between core and kubvrit, but I managed to share the same files in #45.

If we remove core and use the layout bellow, we have something like:

subscripiton/deployment-...
subscription/kubevirt-vm-pvc-...

And same for dr/

• My understanding of core under root, and deployment under the same is to have another higher level directory like kubevirt with its variants within. This reduces some clutter (so that we avoid deployment/sts/daemonset within core). The issue I see is with the name core or just stashing away 3 workload types from the clutter (we will still need kubevirt at the root with it's sub-directories in there). It would be preferable to be more explicit and have deployment at the root. We can add a workloads or similar directory at the root and move all workloads within it (avoid clutter at root of the repo).

The second is more key than the first, as it impacts product documentation.

We already discussed this structure last week - grouping the standard resources (deployment, statefulset, daemonset under core, and 3 vm samples under kubevirt. For kubvirt grouping the VMs makes sense since we want to have a kubvirt specific README.md. For core samples, I don't think we need any specific README.md.

Do you prefer this layout?

workloads/
  deployment/
  statefulset/
  daemonset/
  kubevirt/
  kafka/
  mongodb/

From OpenShift console, adding user will need to choose paths like:

• workloads/deployemnt/odr-regional-rbd
• workloads/kubevirt/vm-pvc/odr-regional-rbd

[ShyamsundarR]

A few questions:

• Why is there a core subdirectory within dr and subscription directories?

We need different drpc for busybox and kubevirt, mainly because we use different pvc selector, based on appname label. We use the same drpc if we use the same appname for all samples, maybe appname: sample

Ack, looks related to the pvcSelector comment that I made, if not possible yet we can look at this later.

For subscription I assumed we will have few differences between core and kubvrit, but I managed to share the same files in #45.

Ack!

If we remove core and use the layout bellow, we have something like:

subscripiton/deployment-...
subscription/kubevirt-vm-pvc-...

And same for dr/

• My understanding of core under root, and deployment under the same is to have another higher level directory like kubevirt with its variants within. This reduces some clutter (so that we avoid deployment/sts/daemonset within core). The issue I see is with the name core or just stashing away 3 workload types from the clutter (we will still need kubevirt at the root with it's sub-directories in there). It would be preferable to be more explicit and have deployment at the root. We can add a workloads or similar directory at the root and move all workloads within it (avoid clutter at root of the repo).

The second is more key than the first, as it impacts product documentation.

We already discussed this structure last week - grouping the standard resources (deployment, statefulset, daemonset under core, and 3 vm samples under kubevirt. For kubvirt grouping the VMs makes sense since we want to have a kubvirt specific README.md. For core samples, I don't think we need any specific README.md.

Do you prefer this layout?

workloads/
  deployment/
  statefulset/
  daemonset/
  kubevirt/
  kafka/
  mongodb/

2 things I see here, looks cleaner so that at the higher level we do not have more directories, also core is misleading a bit. In an attempt to find a better name I could only come up with something like k8s-builtins from here

From OpenShift console, adding user will need to choose paths like:

* workloads/deployemnt/odr-regional-rbd

* workloads/kubevirt/vm-pvc/odr-regional-rbd

[nirs]

Conclusions after discussion:

• Go with workloads{deployment,kubevirt} layout, removing core
• Otherwise current layout is fine