Flatten instance type directories

[lyarwood]

/kind enhancement

The current structure is pretty nested and could be simplified, for example:

$ tree common-instancetypes/instancetypes/hyperscale/n/
common-instancetypes/instancetypes/hyperscale/n/
├── 1
│   ├── 2xlarge
│   │   └── kustomization.yaml
│   ├── 4xlarge
│   │   └── kustomization.yaml
│   ├── 8xlarge
│   │   └── kustomization.yaml
│   ├── base
│   │   ├── kustomization.yaml
│   │   └── n1.yaml
│   ├── kustomization.yaml
│   ├── large
│   │   └── kustomization.yaml
│   ├── medium
│   │   └── kustomization.yaml
│   └── xlarge
│       └── kustomization.yaml
├── base
│   ├── kustomization.yaml
│   └── n.yaml
├── kustomization.yaml
└── sizes
    ├── 2xlarge
    │   ├── 2xlarge.yaml
    │   └── kustomization.yaml
    ├── 4xlarge
    │   ├── 4xlarge.yaml
    │   └── kustomization.yaml
    ├── 8xlarge
    │   ├── 8xlarge.yaml
    │   └── kustomization.yaml
    ├── large
    │   ├── kustomization.yaml
    │   └── large.yaml
    ├── medium
    │   ├── kustomization.yaml
    │   └── medium.yaml
    └── xlarge
        ├── kustomization.yaml
        └── xlarge.yaml

17 directories, 24 files

As compared to https://github.com/fabiand/instanceTypes/tree/main/series/n1

[fabiand]

10x! :)

I'd really like to see that people can easily identify the series they know, and get a headstart on modifying them in a self contained way. Speak to make it easy to grok, and modify -> empowerment of users.

The price we'd be paying is to have a little less normalization.

A pretty intuitive target could be:

$ find instanceTypes/ -type d
instanceTypes/
instanceTypes/cx1
instanceTypes/gn1
instanceTypes/m1
instanceTypes/n1
instanceTypes/u1
instanceTypes/uo1

[lyarwood]

https://github.com/kubevirt/common-instancetypes/pull/73 starts by squashing the size components into the individual classes. Squashing any further is made pretty complex by our current support of both the cluster wide and namespaced types from the same tree, for example cx1 generates the following resources:

$ tree common-instancetypes/instancetypes/hyperscale/cx
common-instancetypes/instancetypes/hyperscale/cx
├── 1
│   ├── 2xlarge
│   │   ├── 2xlarge.yaml
│   │   └── kustomization.yaml
│   ├── 4xlarge
│   │   ├── 4xlarge.yaml
│   │   └── kustomization.yaml
│   ├── 8xlarge
│   │   ├── 8xlarge.yaml
│   │   └── kustomization.yaml
│   ├── base
│   │   ├── cx1.yaml
│   │   └── kustomization.yaml
│   ├── kustomization.yaml
│   ├── large
│   │   ├── kustomization.yaml
│   │   └── large.yaml
│   ├── medium
│   │   ├── kustomization.yaml
│   │   └── medium.yaml
│   └── xlarge
│       ├── kustomization.yaml
│       └── xlarge.yaml
├── base
│   ├── cx.yaml
│   └── kustomization.yaml
└── kustomization.yaml

10 directories, 18 files

$ kustomize build common-instancetypes/instancetypes/hyperscale/cx | yq '.kind,.metadata.name'#

VirtualMachineClusterInstancetype
cx1.2xlarge
---
VirtualMachineClusterInstancetype
cx1.4xlarge
---
VirtualMachineClusterInstancetype
cx1.8xlarge
---
VirtualMachineClusterInstancetype
cx1.large
---
VirtualMachineClusterInstancetype
cx1.medium
---
VirtualMachineClusterInstancetype
cx1.xlarge
---
VirtualMachineInstancetype
cx1.2xlarge
---
VirtualMachineInstancetype
cx1.4xlarge
---
VirtualMachineInstancetype
cx1.8xlarge
---
VirtualMachineInstancetype
cx1.large
---
VirtualMachineInstancetype
cx1.medium
---
VirtualMachineInstancetype
cx1.xlarge

For example this is achieved by the following chain of resources for the 2xlarge size:

• common-instancetypes/instancetypes/hyperscale/cx/1/2xlarge
  • 2xlarge.yaml (Just the resource sizing)
• common-instancetypes/instancetypes/hyperscale/cx/1/base
  • cx1.yaml (At present this is just a version label, in the future this might be more changes from the base)
• common-instancetypes/instancetypes/hyperscale/cx/base
  • cx.yaml (Bulk of the CX class defined here)
• common-instancetypes/instancetypes/base
  • VirtualMachineInstancetype.yaml
  • VirtualMachineClusterInstancetype.yaml

The suggestion of having sizes in a single file doesn't work if we have multiple types and IMHO having both types supported is an important feature of this project.

Most users will not have the ability to apply cluster wide resources to an environment and will need namespaced variants while we already have a consumer of the cluster wide resources through the SSP operator.

[lyarwood]

@fabiand I slept on it (as much as one can with a 9 week old) and I've updated https://github.com/kubevirt/common-instancetypes/pull/73 this morning with the following layout:

$ tree common-instancetypes/instancetypes/hyperscale/cx
common-instancetypes/instancetypes/hyperscale/cx
├── 1
│   ├── cx1.yaml
│   ├── kustomization.yaml
│   └── sizes.yaml
├── kustomization.yaml
├── VirtualMachineClusterInstancetype
│   └── kustomization.yaml
└── VirtualMachineInstancetype
    └── kustomization.yaml

4 directories, 6 files

$ kustomize build common-instancetypes/instancetypes/hyperscale/cx | yq '.kind,.metadata.name'
VirtualMachineClusterInstancetype
cx1.2xlarge
---
VirtualMachineClusterInstancetype
cx1.4xlarge
---
VirtualMachineClusterInstancetype
cx1.8xlarge
---
VirtualMachineClusterInstancetype
cx1.large
---
VirtualMachineClusterInstancetype
cx1.medium
---
VirtualMachineClusterInstancetype
cx1.xlarge
---
VirtualMachineInstancetype
cx1.2xlarge
---
VirtualMachineInstancetype
cx1.4xlarge
---
VirtualMachineInstancetype
cx1.8xlarge
---
VirtualMachineInstancetype
cx1.large
---
VirtualMachineInstancetype
cx1.medium
---
VirtualMachineInstancetype
cx1.xlarge

This no longer uses the global base definitions so everything has to be in cx1.yaml for now, I might change this with components for universal things like vendor later but for now I think this meets both of our requirements.