Tag controller created resources in cloud rather than using ControllerCreated status field

[Karthik-K-N]

/kind feature /area provider/ibmcloud

Describe the solution you'd like [A clear and concise description of what you want to happen.]

Currently in Power VS cluster reconciler whenever a resource is created by controller it internally sets controllercreated filed under respective resource to true(For ref) , Which was initially introduces to allow proper cleanup of newly created resource vs the use of existing resources.

Though its working as expected and serving the purpose, we forsee few of the disadvantage of using this field.

1. The filed is set to true during the first reconcilation of resource as the resource is created, during next reconcilation the field is never touched as resource is already exist in cloud, so which makes controller logic not idempotent and if the first reconcilation event is missed controller behavior changes. Its against k8s principle of reconcilation of having level trigger rather than edge triggered.
2. The status is expected to created from spec, considering the scenario of back and recover, If we move the spec to fresh management cluster which setting the status , the controller created will be set as false as the resource already exist in cloud but it was created during its previous concilation.

In order to mitigate these problems, One of the alternatives discussed was tagging the resource in cloud, In general the highlevel idea is

1. Whenever a resource is created in cloud tag the resource with some unique idnetifier with predefined tag, During deletion we will use this tag to idetify whether to delete or preserve the resources.

Limitations

1. Currently all the resources does not support tagging, For example we use DHCP server in Power VS workspace which does not allow us to tag.

Alternatives discussed

1. Using predetermined name for resource for the controller created resources.
   • Idea was to name the resource with specific format for controller created resources and use it identify for deletion ,

Limitation:

• We allow users to specify the name they wish to have it for resources.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

[Karthik-K-N]

We had discussed about deciding name for the tag in slack. As of now we decided to use following format

powervs.cluster.x-k8s.io-resource-owner:<cluster_name>

[mkumatag]

We had discussed about deciding name for the tag in slack. As of now we decided to use following format

powervs.cluster.x-k8s.io-resource-owner:<cluster_name>

LGTM

[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

[mkumatag]

/remove-lifecycle stale

[arshadd-b]

/assign

[Karthik-K-N]

We are almost there in getting enhancement merged, Addressing last few comments regarding handling corner cases. We can't make it into this release.