Ignore .spec.state of ControlPlaneMachineSet

[DebakelOrakel]

Checklist

• The PR has a meaningful title. It will be used to auto-generate the
  changelog.
  The PR has a meaningful description that sums up the change. It will be
  linked in the changelog.
• PR contains a single logical change (to build a better changelog).
• Update the documentation.
• Categorize the PR by adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog.
• Link this PR to related issues or PRs.

[simu]

Why ignore this instead of configuring it properly via hierarchy?

[DebakelOrakel]

Yeah It might makes sense to just set it to Active, sadly it can't be changed bc it is immutable :D
#82 (comment)

On the other hand it might make sense to leave it as Inactive as most of the fields are immutable as long as it is set to Active.
Otherwise it might be very hard to manage the machineset, pausing ArgoCD etc.

[simu]

The following config (e.g. in a cluster file in a tenant repo) seems to set spec.state=Active just fine in the catalog repo:

  openshift4_nodes:
    nodeGroups:
      master:
        replicas: 3
        spec:
          state: Active

As far as I'm aware the field in the resource isn't immutable, so I don't see a real reason to ignore diffs for it.

[DebakelOrakel]

I tested it and:

  openshift4_nodes:
    nodeGroups:
      master:
        replicas: 3
        state: 'Active'

does not change a thing, but thats probably due to incompetence on my side 🤦‍♂️

[DebakelOrakel]

As far as I'm aware the field in the resource isn't immutable, so I don't see a real reason to ignore diffs for it.

You are right, this only applies to vSphere specific parameters

[simu]

I tested it and:

  openshift4_nodes:
    nodeGroups:
      master:
        replicas: 3
        state: 'Active'

does not change a thing, but thats probably due to incompetence on my side 🤦‍♂️

Looks like you're missing a spec in there if you compare it to the snippet I posted