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
// TODO: currently, the defaulting of CreateMissingNamespaces and *Policy here is identical to the defaulting in the underlying reconciler.Reconciler;
141
+
// under the assumption that these attributes are not used here, we could skip the defaulting here, and let it happen in the underlying implementation only
// will re-claim (and therefore potentially drop) fields owned by certain field managers, such as kubectl and helm
197
204
// - if the effective update policy is UpdatePolicyRecreate, the object will be deleted and recreated.
198
205
//
199
-
// Redundant objects will be removed; that means, in the regular case, a http DELETE request will be sent to the Kubernetes API; if the object specifies
200
-
// its delete policy as DeletePolicyOrphan, no physcial deletion will be performed, and the object will be left around in the cluster; however it will be no
201
-
// longer be part of the inventory.
202
-
//
203
206
// Objects will be applied and deleted in waves, according to their apply/delete order. Objects which specify a purge order will be deleted from the cluster at the
204
207
// end of the wave specified as purge order; other than redundant objects, a purged object will remain as Completed in the inventory;
205
208
// and it might be re-applied/re-purged in case it runs out of sync. Within a wave, objects are processed following a certain internal order;
206
209
// in particular, instances of types which are part of the wave are processed only if all other objects in that wave have a ready state.
207
210
//
211
+
// Redundant objects will be removed; that means, a http DELETE request will be sent to the Kubernetes API; note that an effective Orphan deletion
212
+
// policy will not prevent deletion here; the deletion policy will only be honored when the component as whole gets deleted.
213
+
//
208
214
// This method will change the passed inventory (add or remove elements, change elements). If Apply() returns true, then all objects are successfully reconciled;
209
215
// otherwise, if it returns false, the caller should recall it timely, until it returns true. In any case, the passed inventory should match the state of the
210
216
// inventory after the previous invocation of Apply(); usually, the caller saves the inventory after calling Apply(), and loads it before calling Apply().
Copy file name to clipboardExpand all lines: website/content/en/docs/_index.md
+3-13Lines changed: 3 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,23 +5,13 @@ weight: 40
5
5
type: "docs"
6
6
---
7
7
8
-
This repository provides a framework supporting the development of opinionated Kubernetes operators
8
+
This repository provides a framework supporting the development of Kubernetes operators
9
9
managing the lifecycle of arbitrary deployment components of Kubernetes clusters, with a special focus
10
10
on such components that are or contain Kubernetes operators themselves.
11
11
12
12
It can therefore serve as a starting point to develop [SAP Kyma module operators](https://github.com/kyma-project/template-operator),
13
-
but can also be used independently of Kyma.
14
-
15
-
Regarding its mission statement, this project can be compared with the [Operator Lifecycle Manager (OLM)](https://olm.operatorframework.io/).
16
-
However, other than OLM, which follows a generic modelling approach, component-operator-runtime encourages the development of opinionated,
17
-
concretely modeled, component-specific operators. This makes the resulting logic much more explicit, and also allows to react better on
18
-
specific lifecycle needs of the managed component.
19
-
20
-
Of course, components might equally be managed by using generic Kustomization or Helm chart deployers (such as provided by [ArgoCD](https://argoproj.github.io/) or [FluxCD](https://fluxcd.io/flux/)).
21
-
However, these tools have certain weaknesses when it is about to deploy other operators, i.e. components which extend the Kubernetes API,
22
-
e.g. by adding custom resource definitions, aggregated API servers, according controllers, or admission webhooks.
23
-
For example these generic solutions tend to produce race conditions or dead locks upon first installation or deletion of the managed components.
24
-
This is where component-operator-runtime tries to act in a smarter and more robust way.
13
+
but can also be used independently of Kyma. While being perfectly suited to develop opiniated operators like Kyma module operators, it can be
14
+
equally used to cover more generic use cases. A prominent example for such a generic operator is the [SAP component operator](https://github.com/sap/component-operator) which can be compared to flux's [kustomize controller](https://github.com/fluxcd/kustomize-controller) and [helm controller](https://github.com/fluxcd/helm-controller).
25
15
26
16
If you want to report bugs, or request new features or enhancements, please [open an issue](https://github.com/sap/component-operator-runtime/issues)
27
17
or [raise a pull request](https://github.com/sap/component-operator-runtime/pulls).
0 commit comments