Add OpenStack standalone control plane Helm chart and templates

[bnallapeta]

Resolves #592.

This PR introduces a Helm chart and associated templates to facilitate the deployment of standalone control plane on OpenStack within the Hybrid Multi-Cloud (HMC) platform.

[a13x5]

Parameter names, some syntax questions.

[a13x5]

These make no sense with secret.create: false

[bnallapeta]

Like I mentioned in the other comment, I wanted to remove this entire block but docs says that these two fields are required. It does make sense that it won't look at this block if we are using an existing secret.

But let me test it by removing them and make sure it works.

[a13x5]

Too clogged with comments. Please move them to a proper docs, they will rot here at some point.

[bnallapeta]

The whole point of putting the comments which other files do not have is so that a user does not have to refer docs to fill in the values.yaml :)

for detailed info, they can refer the docs which I will update too. But just a short explanation would help imo. The benefit of this outweighs the "clogged feel" of the page.

[bnallapeta]

https://helm.sh/docs/chart_best_practices/values/#document-valuesyaml

[a13x5]

Ok, let me elaborate:

What you showing is make sense when you're writing a standalone chart and the only documentation is a README.md in the same directory which gets generated from comments in the values.yaml. So you have one source of docs.

In our case user will not use charts directly, but rather create ManagedCluster object and we have separate documentation, so now we have 2 places where we should document values - this means rot at some point.

Ans lastly I should mention consistency:

• All other charts' values aren't documented (should we document all of them then?)
• Not all options are documented in this chart
• Documentation strings style is mostly incorrect and inconsistent:

Yours:

bastion:
  enabled: false # Enable bastion server for SSH access
  spec:
    providerID: "" # Provider ID of the bastion server
    flavor: "" # Flavor of the bastion server
    image: # Image of the bastion server
      filter:
        name: "" # Name of the image

Correct (it's even mentioned in the docs you've shared):

bastion:
  # Enable bastion server for SSH access
  enabled: false
  # Bastion instance spec
  # Accepts arbitrary parameters for OpenStackMachineSpec 
  spec:
    # Provider ID of the bastion server
    providerID: ""
    # Flavor of the bastion server
    flavor: "" 
    # Image of the bastion server
    image:
      # ImageFilter parameters for the image
      filter:
        # Name of the image
        name: ""
        # Optional tags which associated with an image
        # tags: []        

[a13x5]

This check looks extra and you probably can just use with keyword here to be more consistent. Applicable to other if gt checks.

[bnallapeta]

if you use with, and let's say portOpts is defined like this:

portOpts: []

then in the rendered template, we get empty portOpts yaml. Using a gt keyword prevents this. Same for other vars - maps or list.

[a13x5]

1. Is the portOpts: [] causing any issues?
2. For securityGroups you have values defined, so it will never be empty (unless user explicitly delete defaults)