Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow annotations for operands in OperandConfig #742

Open
kaczyns opened this issue Sep 7, 2021 · 3 comments
Open

Allow annotations for operands in OperandConfig #742

kaczyns opened this issue Sep 7, 2021 · 3 comments

Comments

@kaczyns
Copy link
Member

kaczyns commented Sep 7, 2021

/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
@horis233
Copy link
Contributor

horis233 commented Sep 7, 2021

@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?

@Daniel-Fan
Copy link
Contributor

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.

@kaczyns
Copy link
Member Author

kaczyns commented Sep 9, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants