Create a few sample custom sizing configmaps without parameterizing

[morningspace]

We shall create a set of sample custom sizing configmaps that do not allow users to modify the detailed resource settings within these configmaps. This means all the resources settings in these configmaps are fixed value or OOTB.

The reason for this is that, user will use some tooling to input load factors such as number of transactions per second which will gear the tooling to generate such configmaps. Once these configmaps submitted to git repo, the GitOps process will consume and sync onto target system.

As example, we could have:

.
└── config
    └── cp4waiops                 (cp4waiops gitops configuration)
        └── custom-sizing         (cp4waiops custom sizing sample configuration)
            ├── templates
            │   ├──custom-sizing-configmap.yaml       (configmap for arbitrary user input)
            │   ├──custom-sizing-resource-lockers.yaml(custom sizing not covered by configmap for arbitrary user input)
            │   ├──x-small-configmap.yaml             (configmap for general x-small)
            │   ├──x-small-idle-configmap.yaml        (configmap specific for idle workload using x-small)
            │   ├──x-small-lad-configmap.yaml         (configmap specific for lad use case using x-small)
            │   ├──x-small-mad-configmap.yaml         (configmap specific for mad use case using x-small)
            │   ├──x-small-resource-lockers.yaml      (custom sizing not covered by configmap for general x-small)
            │   ├──x-small-idle-resource-lockers.yaml (custom sizing not covered by configmap for idle workload using x-small)
            │   ├──x-small-lad-resource-lockers.yaml  (custom sizing not covered by configmap for lad using x-small)
            │   ├──x-small-mad-resource-lockers.yaml  (custom sizing not covered by configmap for mad using x-small)
            │   ├──small-lad-configmap.yaml           (configmap specific for lad use case using small)
            │   ├──small-mad-configmap.yaml           (configmap specific for mad use case using small)
            │   ├──small-lad-resource-lockers.yaml    (custom sizing not covered by configmap for lad using small)
            │   └──small-mad-resource-lockers.yaml    (custom sizing not covered by configmap for mad using small)
            └── values.yaml       (values for arbitrary user input, and the profile, e.g.: x-small, x-small-idle, x-small-lad, small-mad, etc.)

[gyliu513]

@morningspace does the custom sizing depend on resource locker? We may not able to GA this feature if it depends on resource locker as it is another open source component.

[morningspace]

@gyliu513 The reason it still has resource locker after switch to configmap is that the current configmap does not cover all cases which are originally covered by the resource locker, i.e.: configmap only addressed a subset of the custom sizing needs addressed by resource locker.

While I believe the configmap approach should be improved to cove all cases in the coming releases, for now in this release, I think we have a couple of options:

• To indicate in docs (previously I put it in tech-preview folder before the final version of the repo layout) that the custom sizing gitops configuration is just a sample configuration which will not be officially supported and subject to change comparing w/ other gitops configuration in this repo. So, we split it out and let customer know that's not part of GA feature.

• To remove resource locker from the current x-small gitops configuration and make this as part of GA feature as well. This will loose some custom-sizing capabilities which are originally supported when using resource locker.

• To keep the resource locker configuration along w/ the custom sizing configmap but provide a switch (turned off by default) in values.yaml w/ clear note that only the configmap is officially supported, while the resource locker configuration is just a sample to extend the custom sizing capability to cover more cases which will not be officially supported and subject to change. Customers should be aware of this before they turn it on.

[morningspace]

@lihongbj