How to search for resources

[dlaidlaw]

Is there a way to search for resources by label or annotation? For example, to search for all resources that include the label app=my-app. This would return Pods, Deployments, Services, StatefulSets, etc.

Thanks!

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[rohanKanojia]

still looks like a relevant issue to me. It would be nice if we could add something like client.resourceList().inNamespace("default").withLabels().get()

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[mwllgr]

Hi,

I'd need this feature too. Is there any chance that this will get implemented in the future?

[shawkins]

I don't think this will be directly implemented in the near future. The best workaround is to enumerate the resource classes, then apply the same logic, search for a label or whatever, over each:

Arrays.asList(Pod.class, ...).forEach(c -> client.resources(c).withLabel(...).list()...);

[metacosm]

I don't think this will be directly implemented in the near future. The best workaround is to enumerate the resource classes, then apply the same logic, search for a label or whatever, over each:

Arrays.asList(Pod.class, ...).forEach(c -> client.resources(c).withLabel(...).list()...);

This only works if you know what kind of resources to expect beforehand and if it's practical to enumerate them. This feels rather cumbersome for a use case that's quite common, imo.

[manusa]

This only works if you know what kind of resources to expect beforehand and if it's practical to enumerate them

As discussed internally, after the many improvements to the GenericKubernetesResource handling and the addition of the methods to list groups and resources, this should be much easier to implement now. We'll probably give it a spin in the next weeks.

[shawkins]

After #4065 you should be able to walk the APIResources for each APIGroup and "v1", and perform a filtered list operation on those without a '/' in their name and that support the get verb - it appears that not everything that supports list reports supporting the list verb.

[shawkins]

See https://github.com/fabric8io/kubernetes-client/blob/bb524af2542b0da1ed4d91ec272982fba2a57d91/kubernetes-itests/src/test/java/io/fabric8/kubernetes/PluralizeIT.java

Something like this:

    Map<String, APIResourceList> resources = new HashMap<>();
    resources.put("v1", client.getApiResources("v1"));
    client.getApiGroups().getGroups().stream().flatMap(g -> g.getVersions().stream()).forEach(v -> {
      resources.put(v.getGroupVersion(), client.getApiResources(v.getGroupVersion()));
    });

    resources.entrySet().forEach(e -> {
      e.getValue().getResources().stream()
          .filter(ar -> !ar.getName().contains("/"))
          // filtering specific to listing
          .filter(ar -> ar.getVerbs().contains("get") || ar.getVerbs().contains("list"))
          .map(ar -> client.genericKubernetesResources(e.getKey(), ar.getKind()))
          .forEach(o -> o.withLabel("x").list()); // or whatever business logic is needed to filter, then collect
    });

[manusa]

Since this one is extremely expensive, it's also a good candidate for a reactive approach.

[metacosm]

Also, this really isn't straightforward to do either… I think we should provide a top-level operation similar to #887 (comment)
This is getting into query-language territory, though… 😅

[manusa]

I think Steven was proposing the implementation of such method. If I'm not mistaken, I think we all agree to include this operation and no one is against it.

My argumentation was that this might be a very expensive operation in large clusters, so providing a reactive approach that can be stopped/cancelled at any point (e.g. the user retrieves what he/she is looking for), would be a good option for this. However, I'm not sure consumer-side cancellation would be possible with Java8 Streams only.

[shawkins]

Looking at the openshift console the search functionality by label makes you select resource types - there is no option for selecting all. It would be sensible to follow the same approach, which alleviates much of the concern of how expensive the operation could be.

Specifically for filtering / searching it could look like:

client.search(ConfigMap.class).search("foo/v1", "kind")...withLabels(...).resources() - returns a Stream of KubernetesResource

But you could make an argument for composite operations in general:

client.resources(ConfigMap.class).resources("foo/v1", "kind")...withLabels(...).delete()

I'm not sure how easily that could be added to the existing resources entry point, or if a new one would be needed.

[shawkins]

Looked at the above again - it's not really worth the effort vs just using lambdas against a list of types.

A more concrete proposal is https://github.com/fabric8io/kubernetes-client/compare/master...shawkins:search?expand=1 - this just assumes that it will be a while before we have reactive versions of the relevant operations available (we kind of do for list, but submitList is not exposed). This adds a visitor / walking entry point similar to java's file visiting:

kubernetesClient.visitResources((apiResource, operation) -> {
      if (apiResource.getVerbs().contains("get") || apiResource.getVerbs().contains("list")) {
        operation.with... // any MixedOperation method
      }
      return ApiVisitResult.CONTINUE;
    });

There are additional hooks for a visitor to skip / terminate on a given api name, or apiVersion.