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
ProblemStatement: GenericController serves the purpose of being used as a config file to define the watch & attachments required to implement the reconciliation logic for any CustomResource. However, for certain use cases, it seems better to delegate definition of attachments to specific CustomResource specs instead of being defined in GenericController specs. GenericController is thus left with the watch definition only.
The use cases that will need this feature are the ones where the attachment kinds are dynamic & can be defined as well as removed by users of the CustomResource.
This also means individual CustomResource's hooks need to be more involved in the reconciliation process. In other words, these hooks will take up the additional responsibility of managing the desired state themselves instead of the current way of metac handling the desired state.
This issue tracks the possibility of exposing methods in metac that allows these hooks to invoke this desired state handling logic.
The text was updated successfully, but these errors were encountered:
AmitKumarDas
changed the title
feat(generic controller): expose methods to support custom resources that define the attachments
feat(generic controller): expose methods to support custom resources that like to define the attachments
Apr 29, 2020
Thinking more on this, GenericController configs can be loaded dynamically from kubernetes ConfigMap instead of the solution proposed above.
Proposed Solution
Metac will be run on local mode. In this mode, metac reads the generic controller config files mounted at specified location. As an enhancement, metac can additionally read these config files from kubernetes config map. This lets end users make use of config map for cases where generic controller spec needs to be set depending on custom controller's desired state needs. This also avoids the need to manage the desired state logic in controller's hook logic.
ProblemStatement:
GenericController
serves the purpose of being used as a config file to define the watch & attachments required to implement the reconciliation logic for any CustomResource. However, for certain use cases, it seems better to delegate definition of attachments to specific CustomResource specs instead of being defined in GenericController specs. GenericController is thus left with the watch definition only.The use cases that will need this feature are the ones where the attachment kinds are dynamic & can be defined as well as removed by users of the CustomResource.
This also means individual CustomResource's hooks need to be more involved in the reconciliation process. In other words, these hooks will take up the additional responsibility of managing the desired state themselves instead of the current way of metac handling the desired state.
This issue tracks the possibility of exposing methods in metac that allows these hooks to invoke this desired state handling logic.
The text was updated successfully, but these errors were encountered: