Allow setting also field selectors for non-matching fields #1553
Comments
|
(Started work on a PR to implement exactly this) |
mdonkers
pushed a commit
to mdonkers/kubernetes-client
that referenced
this issue
May 28, 2019
The Kubernetes API allows specifying field selectors where key-value pair match, but also specifying non-matching key-value pairs using the operator `!=`: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Currently the Kubernetes Client allows specifying matching field selectors using the `withField(key, value)` method. And by appending a `!` (exclamation mark) after the key it's possible to 'hack' also the non-matching pairs. But should internals change, this will quickly break. Instead this PR provides the necessary endpoint to specify non-matching key-value pairs in field selectors by providing the method `withFieldNot(key, value)`. Some decisions to further discuss: - Non-matching pairs can be specified multiple times with the same key. Therefore a multi-value map is needed. To keep with the other filters (labels), I used `Map<String, String[]>`. The alternative was to use a list. The downside of this decision is that a new String array needs to be created when multiple values with the same key are added. But the likeliness is quite small this will get called very often. And because of the `merge` function on `Map`, for the first call it will directly use the provided value, so no real overhead. - The API is kept the same as `withField` however, and not like `withLabelIn` which allows varargs. I figured this would be non-intuitive. Downside here is that you cannot 'override' a key-value pair. It would just add more values to the same key. But for me the intuitiveness weighted stronger than being able to override pairs.
mdonkers
pushed a commit
to mdonkers/kubernetes-client
that referenced
this issue
May 28, 2019
The Kubernetes API allows specifying field selectors where key-value pair match, but also specifying non-matching key-value pairs using the operator `!=`: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Currently the Kubernetes Client allows specifying matching field selectors using the `withField(key, value)` method. And by appending a `!` (exclamation mark) after the key it's possible to 'hack' also the non-matching pairs. But should internals change, this will quickly break. Instead this PR provides the necessary endpoint to specify non-matching key-value pairs in field selectors by providing the method `withFieldNot(key, value)`. Some decisions to further discuss: - Non-matching pairs can be specified multiple times with the same key. Therefore a multi-value map is needed. To keep with the other filters (labels), I used `Map<String, String[]>`. The alternative was to use a list. The downside of this decision is that a new String array needs to be created when multiple values with the same key are added. But the likeliness is quite small this will get called very often. And because of the `merge` function on `Map`, for the first call it will directly use the provided value, so no real overhead. - The API is kept the same as `withField` however, and not like `withLabelIn` which allows varargs. I figured this would be non-intuitive. Downside here is that you cannot 'override' a key-value pair. It would just add more values to the same key. But for me the intuitiveness weighted stronger than being able to override pairs.
mdonkers
pushed a commit
to mdonkers/kubernetes-client
that referenced
this issue
Jun 3, 2019
The Kubernetes API allows specifying field selectors where key-value pair match, but also specifying non-matching key-value pairs using the operator `!=`: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Currently the Kubernetes Client allows specifying matching field selectors using the `withField(key, value)` method. And by appending a `!` (exclamation mark) after the key it's possible to 'hack' also the non-matching pairs. But should internals change, this will quickly break. Instead this PR provides the necessary endpoint to specify non-matching key-value pairs in field selectors by providing the method `withFieldNot(key, value)`. Some decisions to further discuss: - Non-matching pairs can be specified multiple times with the same key. Therefore a multi-value map is needed. To keep with the other filters (labels), I used `Map<String, String[]>`. The alternative was to use a list. The downside of this decision is that a new String array needs to be created when multiple values with the same key are added. But the likeliness is quite small this will get called very often. And because of the `merge` function on `Map`, for the first call it will directly use the provided value, so no real overhead. - The API is kept the same as `withField` however, and not like `withLabelIn` which allows varargs. I figured this would be non-intuitive. Downside here is that you cannot 'override' a key-value pair. It would just add more values to the same key. But for me the intuitiveness weighted stronger than being able to override pairs.
mdonkers
pushed a commit
to mdonkers/kubernetes-client
that referenced
this issue
Jun 17, 2019
The Kubernetes API allows specifying field selectors where key-value pair match, but also specifying non-matching key-value pairs using the operator `!=`: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Currently the Kubernetes Client allows specifying matching field selectors using the `withField(key, value)` method. And by appending a `!` (exclamation mark) after the key it's possible to 'hack' also the non-matching pairs. But should internals change, this will quickly break. Instead this PR provides the necessary endpoint to specify non-matching key-value pairs in field selectors by providing the method `withFieldNot(key, value)`. Some decisions to further discuss: - Non-matching pairs can be specified multiple times with the same key. Therefore a multi-value map is needed. To keep with the other filters (labels), I used `Map<String, String[]>`. The alternative was to use a list. The downside of this decision is that a new String array needs to be created when multiple values with the same key are added. But the likeliness is quite small this will get called very often. And because of the `merge` function on `Map`, for the first call it will directly use the provided value, so no real overhead. - The API is kept the same as `withField` however, and not like `withLabelIn` which allows varargs. I figured this would be non-intuitive. Downside here is that you cannot 'override' a key-value pair. It would just add more values to the same key. But for me the intuitiveness weighted stronger than being able to override pairs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Kubernetes API spec mentions for field-selectors they support two operators;
=value!=valuehttps://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/
Currently the Kubernetes client provides only the option to specify matching key-value pairs using
withField(s). And with a hack its possible to dowithField("key!", "value")which would result inkey!=value(notice the exclamation mark after "key!").But this might stop working when internals change.
Hence, to keep aligned with 'label' selectors, it would be nice to have a
withFieldsNotMatchingextension to the API for the Kubernetes client.The text was updated successfully, but these errors were encountered: