Open AmitKumarDas opened 4 years ago
Thinking more on this, GenericController
configs can be loaded dynamically from kubernetes ConfigMap
instead of the solution proposed above.
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.