-
-
Notifications
You must be signed in to change notification settings - Fork 74
Description
Is your feature request related to a problem? Please describe.
I have a situation that I need to watch the Foo
entity, but with different label selectors to filter out unnecessary watches.
For example, I have two labels called "foo.com/is-managed" and foo.com/autogen-config
. foo.com/autogen-config
requires foo.com/is-managed
so it makes sense to write something like this:
public class FooManagedLabelSelector : IEntityLabelSelector<V1Service>
{
public ValueTask<string?> GetLabelSelectorAsync(CancellationToken cancellationToken) =>
ValueTask.FromResult<string?>(
(
new KubeOps.KubernetesClient.LabelSelectors.LabelSelector[]
{
new EqualsSelector("foo.com/is-managed", "true"),
}
).ToExpression()
);
}
public class FooConfigLabelSelector : IEntityLabelSelector<V1Service>
{
public ValueTask<string?> GetLabelSelectorAsync(CancellationToken cancellationToken) =>
ValueTask.FromResult<string?>(
(
new KubeOps.KubernetesClient.LabelSelectors.LabelSelector[]
{
new EqualsSelector("foo.com/is-managed", "true"),
new EqualsSelector(
"foo.com/autogen-config",
"true"
)
}
).ToExpression()
);
}
builder
.Services
.AddKubernetesOperator()
.AddController<
FooController,
Foo,
FooManagedLabelSelector
>()
.AddController<
FooConfigController,
Foo,
FooConfigLabelSelector
>()
.RegisterComponents();
But in reality, the first one controller in the service injection graph, that got the label matches wins, causing FooConfigController
to never fire and never generate the API key I needed.
Describe the solution you would like
Let us have two different controllers that monitors the same entity, but with different label selectors
Additional Context
I used feature/bug instead because I'm not sure whether this is intended or unexpected. I'm leaning on the fact that it should be obviously good to have multiple controllers to do one thing the best, but right now I can work around it by finding the label set of the path of least resistance, and filter out the labels on application level, rather than on database level.
It's just the problem of consistency trade-off that makes it debatable to classify it as a bug or a feature whatnot.