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
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:
change the value for an annotation in the alm-example
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:
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.
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.
/kind feature
Describe the solution you'd like
I can specify a
spec
for an operand in the OperandConfig, over-riding what is in thealm-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:
Anything else you would like to add:
I am thinking something like this in the OperandConfig would be nice:
The text was updated successfully, but these errors were encountered: