spec.Bastion.serverMetadata field in OpenStackCluster v1beta1 is not functioning

[namgon-kim]

/kind bug

What steps did you take and what happened:
I was trying to set metadata for the Bastion server using the spec.Bastion.serverMetadata field in the OpenStackCluster Custom Resource Definition (CRD) version v1beta1. Here are the steps I took:

1. I created an OpenStackCluster resource with the serverMetadata field specified:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: OpenStackCluster
metadata:
  name: bastion-test
spec:
  bastion:
    enabled: true
    serverMetadata:
      - key: "test"
         value: "somedata"
    ...

2. I applied the resource and waited for the cluster to reconcile.
3. After the Bastion server was created, I checked the instance in OpenStack.
4. I noticed that the metadata specified in serverMetadata was not applied to the Bastion server instance.

What did you expect to happen:
I expected the Bastion server instance to have the metadata from spec.Bastion.serverMetadata applied upon creation. Specifically, I expected to see test: somedata in the instance’s metadata.

Anything else you would like to add:
To analyze the issue, you examined the bastionToInstanceSpec function in the openstackcluster_controller.go file in version v0.10.5.

Relevant code snippet:

func bastionToInstanceSpec(openStackCluster *infrav1.OpenStackCluster, cluster *clusterv1.Cluster) (*compute.InstanceSpec, error) {
    bastion := openStackCluster.Spec.Bastion

    // Code to resolve image, flavor, etc.

    instanceSpec := &compute.InstanceSpec{
        Name:          bastionName(cluster.Name),
        Flavor:        machineSpec.Flavor,
        SSHKeyName:    machineSpec.SSHKeyName,
        ImageID:       resolved.ImageID,
        RootVolume:    machineSpec.RootVolume,
        ServerGroupID: resolved.ServerGroupID,
        Tags:          compute.InstanceTags(machineSpec, openStackCluster),
        // Metadata field is missing here
    }

    // Rest of the function...
}

It appears that the serverMetadata from the CRD isn’t being passed to the instanceSpec, so it’s not applied to the Bastion server during creation.

Environment:
• Cluster API Provider OpenStack version (or git rev-parse HEAD if manually built): v0.10.5
• Cluster-API version: v1.6.5
• OpenStack version: 2023.1
• Minikube/KIND version: Not applicable
• Kubernetes version (use kubectl version): v1.28.10
• OS (e.g., from /etc/os-release):

NAME="Ubuntu"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 22.04.1 LTS"
VERSION_ID="22.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy

[EmilienM]

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: OpenStackCluster
metadata:
  name: bastion-test
spec:
  bastion:
    enabled: true
    spec:
      serverMetadata:
        - key: "test"
           value: "somedata"

Try with this instead, the serverMetadata key must be in the bastion.Spec.

[EmilienM]

I'm surprised how you could manage to create a cluster with this, the webhook should have complained about the wrong OpenStackCluster spec.

[EmilienM]

i'll close the bug now as I suspect this was a user error but if I was wrong and something is not working as you expect to work, please re-open and I'll take a look again.

[namgon-kim]

@EmilienM
Oh! I apologize for the confusion earlier. While removing internal company information, I accidentally deleted some parts of the YAML.

Here is the corrected YAML:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: OpenStackCluster
metadata:
  name: bastion-test
spec:
  bastion:
    enabled: true
    ...
    spec:
      serverMetadata:
        - key: "test"
          value: "somedata"
  ...

The CRD validation succeeded, and the OpenStackCluster resource was successfully stored in etcd. We are actually using a modified image so that this configuration can be applied.

Please kindly reconsider the issue.

[EmilienM]

If you have a fix please consider sending a PR.
Thanks

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale