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
Copy file name to clipboardExpand all lines: cmd/clusterctl/client/tree/doc.go
+17-17
Original file line number
Diff line number
Diff line change
@@ -21,29 +21,29 @@ understanding if there are problems and where.
21
21
The "at glance" view is based on the idea that we should avoid to overload the user with information, but instead
22
22
surface problems, if any; in practice:
23
23
24
-
- The view assumes we are processing objects conforming with https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20200506-conditions.md.
25
-
As a consequence each object should have a Ready condition summarizing the object state.
24
+
- The view assumes we are processing objects conforming with https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20200506-conditions.md.
25
+
As a consequence each object should have a Ready condition summarizing the object state.
26
26
27
-
- The view organizes objects in a hierarchical tree, however it is not required that the
28
-
tree reflects the ownerReference tree so it is possible to skip objects not relevant for triaging the cluster status
29
-
e.g. secrets or templates.
27
+
- The view organizes objects in a hierarchical tree, however it is not required that the
28
+
tree reflects the ownerReference tree so it is possible to skip objects not relevant for triaging the cluster status
29
+
e.g. secrets or templates.
30
30
31
-
- It is possible to add "meta names" to object, thus making hierarchical tree more consistent for the users,
32
-
e.g. use MachineInfrastructure instead of using all the different infrastructure machine kinds (AWSMachine, VSphereMachine etc.).
31
+
- It is possible to add "meta names" to object, thus making hierarchical tree more consistent for the users,
32
+
e.g. use MachineInfrastructure instead of using all the different infrastructure machine kinds (AWSMachine, VSphereMachine etc.).
33
33
34
-
- It is possible to add "virtual nodes", thus allowing to make the hierarchical tree more meaningful for the users,
35
-
e.g. adding a Workers object to group all the MachineDeployments.
34
+
- It is possible to add "virtual nodes", thus allowing to make the hierarchical tree more meaningful for the users,
35
+
e.g. adding a Workers object to group all the MachineDeployments.
36
36
37
-
- It is possible to "group" siblings objects by ready condition e.g. group all the machines with Ready=true
38
-
in a single node instead of listing each one of them.
37
+
- It is possible to "group" siblings objects by ready condition e.g. group all the machines with Ready=true
38
+
in a single node instead of listing each one of them.
39
39
40
-
- Given that the ready condition of the child object bubbles up to the parents, it is possible to avoid the "echo"
41
-
(reporting the same condition at the parent/child) e.g. if a machine's Ready condition is already
42
-
surface an error from the infrastructure machine, let's avoid to show the InfrastructureMachine
43
-
given that representing its state is redundant in this case.
40
+
- Given that the ready condition of the child object bubbles up to the parents, it is possible to avoid the "echo"
41
+
(reporting the same condition at the parent/child) e.g. if a machine's Ready condition is already
42
+
surface an error from the infrastructure machine, let's avoid to show the InfrastructureMachine
43
+
given that representing its state is redundant in this case.
44
44
45
-
- In order to avoid long list of objects (think e.g. a cluster with 50 worker machines), sibling objects with the
46
-
same value for the ready condition can be grouped together into a virtual node, e.g. 10 Machines ready
45
+
- In order to avoid long list of objects (think e.g. a cluster with 50 worker machines), sibling objects with the
46
+
same value for the ready condition can be grouped together into a virtual node, e.g. 10 Machines ready
47
47
48
48
The ObjectTree object defined implements all the above behaviors of the "at glance" visualization, by generating
49
49
a tree of Kubernetes objects; each object gets a set of annotation, reflecting its own visualization specific attributes,
Copy file name to clipboardExpand all lines: internal/controllers/machinedeployment/machinedeployment_sync.go
+4-4
Original file line number
Diff line number
Diff line change
@@ -68,10 +68,10 @@ func (r *Reconciler) sync(ctx context.Context, d *clusterv1.MachineDeployment, m
68
68
// msList should come from getMachineSetsForDeployment(d).
69
69
// machineMap should come from getMachineMapForDeployment(d, msList).
70
70
//
71
-
// 1. Get all old MSes this deployment targets, and calculate the max revision number among them (maxOldV).
72
-
// 2. Get new MS this deployment targets (whose machine template matches deployment's), and update new MS's revision number to (maxOldV + 1),
73
-
// only if its revision number is smaller than (maxOldV + 1). If this step failed, we'll update it in the next deployment sync loop.
74
-
// 3. Copy new MS's revision number to deployment (update deployment's revision). If this step failed, we'll update it in the next deployment sync loop.
71
+
// 1. Get all old MSes this deployment targets, and calculate the max revision number among them (maxOldV).
72
+
// 2. Get new MS this deployment targets (whose machine template matches deployment's), and update new MS's revision number to (maxOldV + 1),
73
+
// only if its revision number is smaller than (maxOldV + 1). If this step failed, we'll update it in the next deployment sync loop.
74
+
// 3. Copy new MS's revision number to deployment (update deployment's revision). If this step failed, we'll update it in the next deployment sync loop.
75
75
//
76
76
// Note that currently the deployment controller is using caches to avoid querying the server for reads.
77
77
// This may lead to stale reads of machine sets, thus incorrect deployment status.
0 commit comments