Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConfigMap labels are ignored when using mock KubernetesServer #1125

Closed
wheleph opened this issue Jul 6, 2018 · 2 comments · Fixed by #1158
Closed

ConfigMap labels are ignored when using mock KubernetesServer #1125

wheleph opened this issue Jul 6, 2018 · 2 comments · Fixed by #1158

Comments

@wheleph
Copy link

wheleph commented Jul 6, 2018

Here's the simple method that fetches list of configmaps with a particular label value:

public List<ConfigMap> fetchConfigMaps(KubernetesClient client, String namespace, String labelKey, String labelValue) {
    ConfigMapList configMapList = client
            .configMaps()
            .inNamespace(namespace)
            .withLabel(labelKey, labelValue)
            .list();

    return configMapList.getItems();
}

In the unit test below one configmap has proper label and the other one has not. So I expect that the method returns 1:

    @Rule
    public KubernetesServer kubernetesServerSbx = new KubernetesServer(true, true);

    @Test
    public void testFetchConfigMaps() {
        KubernetesClient client = kubernetesServerSbx.getClient();

        createNamespace(client, "ns1");
        createCM(client, "ns1", "cm1", Map.of("label1", "value"));
        createCM(client, "ns1", "cm2", Map.of("label2", "value"));

        ConfigMapFetcher fetcher = new ConfigMapFetcher();

        List<ConfigMap> configMaps = fetcher.fetchConfigMaps(client, "ns1","label1", "value");

        assertEquals(1, configMaps.size());
    }

    private static void createNamespace(KubernetesClient client, String namespace) {
        client.namespaces().create(
                new NamespaceBuilder()
                        .withNewMetadata()
                        .withName(namespace)
                        .endMetadata()
                        .build());
    }

    private static void createCM(KubernetesClient client,
                                 String namespace,
                                 String cmName,
                                 Map<String, String> labels) {

        client.configMaps().inNamespace(namespace).create(
                new ConfigMapBuilder()
                        .withNewMetadata()
                        .withName(cmName)
                        .withLabels(labels)
                        .endMetadata()
                        .build());
    }

However the unit test fails because the method return 2 instead of 1.

I'm using kubernetes-client and kubernetes-server-mock version 3.2.0

Here's the complete source code: my-app.zip

drigz added a commit to drigz/kubernetes-client that referenced this issue Jul 27, 2018
This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label executor. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix fabric8io#1125, although I haven't tested that code directly.
drigz added a commit to drigz/kubernetes-client that referenced this issue Jul 27, 2018
This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label selector. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix fabric8io#1125, although I haven't tested that code directly.
drigz added a commit to drigz/kubernetes-client that referenced this issue Jul 27, 2018
This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label selector. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix fabric8io#1125, although I haven't tested that code directly.
rohanKanojia pushed a commit that referenced this issue Jul 31, 2018
* Support label selectors in mock server

This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label selector. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix #1125, although I haven't tested that code directly.

* Fix PodCrudTest's use of label selector

It was only passing before because the label selector was ignored.

* Improve flexibility of URL parsing

As recommended by @lordofthejars. I renamed PROTOCOL to SCHEME to match
the convention of HttpUrl.
@rohanKanojia
Copy link
Member

Closed via #1158

@wheleph
Copy link
Author

wheleph commented Aug 2, 2018

The fix is scheduled for version 4.0.4

rohanKanojia pushed a commit to rohanKanojia/kubernetes-client that referenced this issue Aug 28, 2018
* Support label selectors in mock server

This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label selector. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix fabric8io#1125, although I haven't tested that code directly.

* Fix PodCrudTest's use of label selector

It was only passing before because the label selector was ignored.

* Improve flexibility of URL parsing

As recommended by @lordofthejars. I renamed PROTOCOL to SCHEME to match
the convention of HttpUrl.
rohanKanojia pushed a commit to rohanKanojia/kubernetes-client that referenced this issue Aug 28, 2018
* Support label selectors in mock server

This supports simple label selectors (eg foo=bar). The != operator would
go beyond the limits of the AttributeSet-based matching in
CrudDispatcher.

There was a test using labels in ConfigMapCrudTest, but it was only
passing because, at the point of execution, all resources match the
label selector. This change moves changes the order of assertions so
that the effect of the label selector is observable.

This should fix fabric8io#1125, although I haven't tested that code directly.

* Fix PodCrudTest's use of label selector

It was only passing before because the label selector was ignored.

* Improve flexibility of URL parsing

As recommended by @lordofthejars. I renamed PROTOCOL to SCHEME to match
the convention of HttpUrl.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants