operand-deployment-lifecycle-manager

operand-deployment-lifecycle-manager copied to clipboard

/kind feature

Describe the solution you'd like I can specify a spec for an operand in the OperandConfig, over-riding what is in the alm-example for that operand in its operator's CSV. However I can't over-ride or add annotations in that operand's metadata. Sometimes an operator looks at the annotations for its operand and performs some extra or different processing which may not be appropriate in my configuration.

I'd like to be able to:

1. change the value for an annotation in the alm-example
2. add an annotation to those already specified in the alm-example

Anything else you would like to add: I am thinking something like this in the OperandConfig would be nice:

apiVersion: operator.ibm.com/v1alpha1
kind: OperandConfig
metadata:
  name: my-operandconfig
  namespace: default
spec:
  services:
  - name: my-operator
    spec:
      my-operand:
        some-spec-field: myvalue
    metadata:
      my-operand:
        annotations:
          my-annotation: myannotationvalue

@kaczyns

Thanks for your proposal. I believe it is a good one since it doesn't break compatibility and we don't need to bump operandconfig API version.

I am good with add/updated some annotations instead of overriding the whole annotation fields.

I believe we can use it to update labels as well.

Also, we may be able to use the same way to change the default name, but we should be cautious about it since that will cause the CR to be deleted and recreated.

@Daniel-Fan @ZhuoxiLi Any thought on this?

Yes, the add/updated annotations and labels are really great features, overriding the entire annotation fields looks too brutal here.

But I don't think it is a good idea to change the default name. We should consider what if the there are multiple CRs created, which CR's name should be changed in this case? Also the name of CR does not really effect the functionality of a operator/operand.

WRT the name - I think the annotations / labels are more important. There is already a way we can affect the name using the OperandRequest directly. However I will say that some operands have default names like "example-xxx" which might not be appropriate for lets say the supported release of a product. So I agree that it does not affect the functionality but it might affect the customer's perception of the product using it.