Description
I have a question on our current implementation that I am not sure about.
Suppose that we want to read sources by labels, when profiles are used too includeProfileSpecificSources=true
. An example will make this far easier to grasp.
In default
namespace we have such configmaps:
- "a" with labels `{color = red, shape = triangle}`
- "a-dev" with labels `{color=blue}`
We say: "I want to get all configmaps with labels {color = red, shape = triangle}
, but also include profile specific sources" (and let's suppose dev
is an active profile).
What we will do currently, is :
- first find configmaps that match labels :
{color = red, shape = triangle}
, as such we will matcha
. - then for all active profiles take all configmaps that "match" previous ones (no matter if they have the needed lables). So, if we found
a
in the previous step, now takea-dev
("a" + "active profile") and take this configmap also.
Notice that we do read a-dev
, though its labels : {color=blue}
do not match the ones we initially requested for {color = red, shape = triangle}
.
This looks like a bug, and we should really be taking only those configmaps that match the labels, no matter if they are plain or profile based labels.
wdyt?
Activity
ryanjbaxter commentedon Sep 10, 2024
I agree with you, all the config maps returned should match the specified labels.
wind57 commentedon Sep 10, 2024
this will go into
3.1.x
?ryanjbaxter commentedon Sep 10, 2024
yes
wind57 commentedon Sep 19, 2024
after further discussion, we came to the conclusion that having
includeProfileSpecificSources
+ labeled search is not correct. As such, this combination will be dropped in the next major and this is the solution going forward.The discussion can be seen here