Open horis233 opened 3 years ago
Does this mean that ODLM would have now permission to create/delete arbitrary k8s resources? Perhaps we shall initially restrict the Kind's of resources allowed?
Currently the ODLM has the permission to manipulate all kinds of resources in namespace-scope(including the namespaces that is extended by namespace-scope operator) https://github.com/IBM/operand-deployment-lifecycle-manager/blob/master/bundle/manifests/operand-deployment-lifecycle-manager.clusterserviceversion.yaml#L681
To restrict the kinds of cluster scope resources that ODLM is allowed to create, we should specify them inside ODLM's CSV.
Looks good guys. Would it be worth restricting it in the beginning to a base set of resources that you think would be useful initially and then augment it with other resources as the needs and usecases arise. That might cut down on the number of paths that need to be tried and tested out initially. The ones in my opinion that would probably be most useful and used would be Jobs, Cronjobs, ConfigMaps and perhaps Secrets.
I suggest we start with a one-off Job
for the already identified use-case and then incrementally expand, based on the identified use cases. And, explicitly list Job
resource in the required permissions.
OperandRequest
controller read the entire data of each resource from resources
section for that operator and create/update the k8s object. It follows the same method when we create the CR from OperandRequest
., Also labels are required to indicate that it is created by ODLM.OperandConfig
controller will update the OperandConfig
status by checking whether the resource defined in resources
section could be found in env, this field is used to indicating the k8s resources for current operator has been deployed.
OperandConfig
controller will compare the status and spec section to determine that the k8s resources created by ODLM should be deleted or not.OperandConfig
controller should update the k8s resource status according to the situation(removing status if it is deleted or indicate the failure of deletion and so on).
NOTE: I thought it is not reasonable to delete the k8s resources by OperandRequest
controller, it does not have any information about custom k8s resource. The deletion logic will be more doable if it is in OperandConfig
reconciliation.OperandConfig
to create the resources. The error will happen because of the false configuration in OperandConfig
Please review the above breakdown of the task @horis233 @ZhuoxiLi
/kind feature
Describe the solution you'd like [A clear and concise description of what you want to happen.]
In some cases, a single operator may not be runnable with some additional k8s objects as a prerequisite. For example, image pull secrets or licensing keys.
This feature is for creating some k8s objects by OperandConfig.
1. When the Operator is requested, and
resources
is configured in the OperandConfig, then ODLM will create these resources for the Operator.resources is a list of k8s resources.
Required fields in the individual resource
Optional fields in the individual resource
true
, ODLM will always override existing resource2. ODLM will generate the resource in the cluster with other requested CRs
3. ODLM will update the status of OperandConfig
Then we users delete the field from OperandConfig, ODLM could clean it up according to the status.
4. When the operator is deleted, k8s resources created by ODLM should be clean up as well.
Note: If the resource isn't created by ODLM, ODLM won't update or delete it.
Limitations
cc @ZhuoxiLi @Daniel-Fan