add option to specify additional managed types #225
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Additional managed types
By its nature, component-operator-runtime tries to handle extension types (such as CRDs or API groups added through APIService federation), and instances of these types, in a smart way.
That is, if the component contains extension types, and also instances of these types, it tries to process things in the right order; that means, during apply the instances will be applied as late as possible (to ensure that controllers and webhooks are up); and during delete, the instances will be deleted as early as possible (to ensure that controllers and webhooks are still there). Furthermore, during deletion, foreign instances (that is, instances of these types that are not part of the component) block the deletion of the whole component.
Sometimes, components are implicitly adding extension types to the cluster; in the sense that the extension types are not explicitly part of the manifests, but added in the dark through controllers, once running. A typical example are crossplane providers.
This PR tries to add some relief in this situation. Components can now list 'additional managed types', by implementing the
TypeConfigurationinterface; these 'additional managed types' will be treated in the same way as extension types which are explicitly mentioned in the manifest.Improved APIService handling
Up to now,
APIServiceobjects were deployed along with the other regular (that was: unmanaged) objects of the current apply wave. As a consequence, if the federated API server was not yet ready,stale group versionerrors were returned by the discovery API of the main API server. To overcome this problem,APIServiceobjects receive a special handling now, in the sense that they are reconciled (in the apply wave) after all other regular objects, and before all managed instances. That means: within each apply order, objects are deployed to readiness in three sub stagesAPIServiceobjects)APIService)Within each of these sub groups, the static ordering defined in
sortObjectsForApply()is effective.