You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[improvement] Implement owner refs for linode resources (#746)
* Update CONTROLLER_GEN path to use CACHE_BIN in Makefile
* Implement owner reference setting for Linode resources
* Add comprehensive tests for setting owner references in LinodeCluster
This commit introduces a new test function, TestSetOwnerReferenceToLinodeCluster, which validates the functionality of setting owner references for LinodeCluster resources. The tests cover various scenarios, including successful cases and error handling.
Additionally, the import statements in helpers.go have been reorganized to fix lint error
* Add Resource Ownership documentation
This commit introduces a new document on Resource Ownership in Kubernetes, detailing the use of `ownerReferences` within the Cluster API Provider Linode (CAPL). It explains the implications of ownership for resource lifecycle management, including automatic garbage collection of dependent resources when a `LinodeCluster` is deleted. Additionally, the SUMMARY.md file is updated to include a link to this new documentation.
* Refactor TestSetOwnerReferenceToLinodeCluster to initialize mock controller and client within the test function
* Enhance error handling in Linode controllers to manage cluster retrieval failures
This commit updates the Linode controllers to improve error handling when fetching clusters from metadata. If a cluster is not found, the controllers now log an informational message and continue with the deletion process instead of returning an error. This change ensures smoother resource management during deletion scenarios. Additionally, comments have been added to clarify the handling of cases where the cluster may not be found.
In Kubernetes, `ownerReferences` are a mechanism to specify the relationship between objects, where one object (the owner) owns another object (the dependent). This is crucial for managing the lifecycle of related resources.
4
+
5
+
## Owner References in Cluster API Provider Linode (CAPL)
6
+
7
+
Cluster API Provider Linode (CAPL) utilizes `ownerReferences` to link various Linode-specific resources to their parent `LinodeCluster`. This means that the `LinodeCluster` acts as the owner for resources such as:
8
+
9
+
*`LinodeFirewall`
10
+
*`LinodeObjectStorageBucket`
11
+
*`LinodeObjectStorageKey`
12
+
*`LinodePlacementGroup`
13
+
*`LinodeVPC`
14
+
15
+
When a `LinodeCluster` is created, and these associated resources are also created as part of the cluster definition or by controllers, CAPL automatically sets an `ownerReference` on these dependent resources, pointing back to the `LinodeCluster`.
16
+
17
+
## Implications of Ownership
18
+
19
+
The primary implication of this ownership model is **garbage collection**. When the `LinodeCluster` object is deleted, the Kubernetes garbage collector will automatically delete all the resources that are owned by it. This simplifies cluster teardown and helps prevent orphaned resources in your Linode account.
20
+
21
+
For example, if you delete a `LinodeCluster`:
22
+
* Any `LinodeVPC` created for that cluster will be deleted.
23
+
* Any `LinodeFirewall` associated with that cluster will be deleted.
24
+
* Any `LinodeObjectStorageBucket` used by that cluster (and owned by it) will be deleted.
25
+
* And so on for other owned resources.
26
+
27
+
This ensures that the lifecycle of these infrastructure components is tightly coupled with the lifecycle of the Kubernetes cluster itself, as managed by Cluster API.
28
+
29
+
## Verifying Ownership
30
+
31
+
You can inspect the `ownerReferences` of a resource using `kubectl describe` or `kubectl get <resource> <name> -o yaml`. Look for the `metadata.ownerReferences` field.
0 commit comments