Closed samof76 closed 2 years ago
Given the example in the issue, I lean to change the behavior for the proposal. I think it's what a user could expect when they are trying to simply add more options to security-context so they can maintain the default values provided by the operator. I just wondering if we should do this with other fields like affinities.
I think it's what a user could expect when they are trying to simply add more options to security-context so they can maintain the default values provided by the operator.
@ese But my only concern would be that they would need to really know what the defaults were. It would be going against the kubenetes philosophy of "what you see is what you get". What do you think?
@ese But my only concern would be that they would need to really know what the defaults were. It would be going against the Kubernetes philosophy of "what you see is what you get". What do you think?
Make sense. Taking into account that if you are gonna define your own security context you probably are an advanced user who has deep experience with Kubernetes.
@ese I agree... i will close this.
Fixes #469 .
@ese what do you think? I am ok either ways.