Add option to tag Api Server floating IP

[fdobrovolny]

/kind feature

Describe the solution you'd like I want to be able to specify custom tags and/or maybe some part of the description of the floating IP in the OpenStackCluster resource.

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha7
kind: OpenStackCluster
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
spec:
  ...
  apiServerFloatingIPTags:
    - myCustomTag
  apiServerFloatingIPDescription: My own description.

Anything else you would like to add:

• Floating IP Creation: https://github.com/kubernetes/cloud-provider-openstack/blob/f6ca48ee768260444db6762447f1cd071f52b6fd/pkg/openstack/loadbalancer.go#L978-L982
• I want this to improve operator visibility into resource association with individual clusters when multiple clusters run inside a single OpenStack project.
• This feature request is a result of the following issue, which may give a more complete context of our use case: https://github.com/SovereignCloudStack/k8s-cluster-api-provider/issues/495

[jichenjc]

from #495 issue seems you want to tag for all resources created thus the API server floating ip is needed?

given PortOpts has Tags so I think it's ok to add this to floating ip we are going to create or we create the the floating ip with cluster name as tag automatically so we don't need expose that much options

thoughts ? @mdbooth @lentzi90 ?

[lentzi90]

Is there a need to have specific/separate tags for the floating IP? What if we just propagate the OpenStackCluster.spec.tags? The description for that already indicates that the tags should be applied to all resources related to the cluster.

Do we have any other place where it is possible to set a description for a resource? I'm looking for examples that could be useful here.

[fdobrovolny]

from https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/495 issue seems you want to tag for all resources created thus the API server floating ip is needed?

Yes, we want to have a way to quickly associate all resources with their respective CAPOs.

Is there a need to have specific/separate tags for the floating IP? What if we just propagate the OpenStackCluster.spec.tags? The description for that already indicates that the tags should be applied to all resources related to the cluster.

For our use case expending OpenStackCluster.spec.tags to floating IPs would be sufficient there is no need for separate tags.

Do we have any other place where it is possible to set a description for a resource? I'm looking for examples that could be useful here.

https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/utils/names/names.go#L23

This function is used in quite a lot of places.

For our use case, it would be best if it was possible to inject some identifier of the particular CAPO into descriptions of all resources created by CAPO.

[mdbooth]

@fdobrovolny Do you definitely need a custom description? CAPO doesn't really have a concept of other CAPOs, so I'm not sure how we would represent its identity.

Ensuring cluster-wide tags are used everywhere just feels like a bugfix, tbh. We should definitely be doing that.

[fdobrovolny]

@fdobrovolny Do you definitely need a custom description? CAPO doesn't really have a concept of other CAPOs, so I'm not sure how we would represent its identity.

Ensuring cluster-wide tags are used everywhere just feels like a bugfix, tbh. We should definitely be doing that.

Not at all it was more as an option in case the tags would not be possible and also while we are at it.

[mdbooth]

If it meets the use case, lets fix the missing tags and leave the description alone.

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.