Identify Volumes (rootVolumes and additional block devices) with Metadata

[EmilienM]

/kind feature

Describe the solution you'd like

• When we create a volume, we put the Kubernetes UUIDs of the OpenStackCluster and the OpenStackMachine in the volume metadata
  • openstack.infrastructure.cluster.x-k8s.io/cluster-uuid
  • openstack.infrastructure.cluster.x-k8s.io/machine-uuid
• When we search for a volume by name and find one, we then check if the UUIDs in the metadata match the cluster/machine being reconciled
• If they do, we own the volume and that is the volume we return
• If they don't, we don't own the volume and we error out

Anything else you would like to add: Context: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/1668#discussion_r1337423351

[EmilienM]

/assign EmilienM

[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

[dulek]

/remove-lifecycle stale

[mdbooth]

I wonder if we still need this.

We discovered that using kubernetes uid would break this when doing a CAPI pivot from a management to self-hosted cluster, and other related data moves. This was previously our preferred method of achieving this. With it not being possible we don't have a good solution.

Additionally, while cluster names may conflict, machine resources should generally include the machine name, which contains a generated component. This should make name conflicts for machine resources unlikely in practise, even when using clusters with the same name.

[lentzi90]

Regarding the UID issue, what about using the provider ID instead? Would that work?

[mdbooth]

Regarding the UID issue, what about using the provider ID instead? Would that work?

Unfortunately I don't think it would because it's only available once the server is created, and the resources we're trying to protect (volumes in this case, but also ports) are created before the server.

We could generate our own uuid and store it in the object status, which I think we've discussed before.

[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

[EmilienM]

/remove-lifecycle stale

[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

[EmilienM]

/remove-lifecycle stale