-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
how to get apiGroupList use kubernetes-client? #3294
Comments
Do you mean try (KubernetesClient client = new DefaultKubernetesClient()) {
client.apiServices().list().getItems().stream()
.map(APIService::getMetadata)
.map(ObjectMeta::getName)
.forEach(System.out::println);
} |
io.fabric8.kubernetes.api.model.APIGroupList,this model |
I want to get preferred version, but I don't how to get APIGroupList use this client |
@gewei2000 : ohk, we're missing support for this. We don't have DSL support for it yet. We'll provide it's support before upcoming release. Internally we're using APIGroup by manually hitting using okhttp: Lines 70 to 76 in 8932e4d
|
This would be really useful to get the cluster available API groups and API resources: $ kubectl proxy --port=8081
$ curl localhost:8081/apis
# For any of the available groups
$ curl localhost:8081/apis/apps/v1 The response for the Relates to #2929 |
I could take this for 5.8. ApiGroup is now annotated appropriately, so it will just take a couple of other changes to expose it via the dsl. |
Take into account that this is not really a resource, just an additional HTTP endpoint exposed by Kubernetes. So not the same operations that apply to the rest of resources apply for this. It makes sense in the scope of an API group (e.g. client.apps() or client.network()). So if API groups and versions could be interfaced appropriately should be easy. |
But maybe as a first approach, something to be able to request information for a specific group, version is what we really want here. |
Sure, I was initially thinking that it would be something like getting a handler for the ApiGroup / ApiGroupList and exposing only the list operation. But looking at it more, that doesn't work so well with the expectations in base operation. It would be simpler to move the isAdaptable logic into a |
Yes, so basically we are looking at what was exposed in my comment, get a list of the available groups and then for each group, be able to retrieve the available resources with their required info (plural, scope, etc.) These new methods can be then used by the GenericResource loader to perform operations on any available resource (as discussed #3392 (comment) & #3392 (comment)). Some pseudo-logic:
|
also trying to consolidate existing logic about openshift adapting
also trying to consolidate existing logic about openshift adapting
also trying to consolidate existing logic about openshift adapting
also trying to consolidate existing logic about openshift adapting
also trying to consolidate existing logic about openshift adapting
how to get apiGroupList use kubernetes-client?
The text was updated successfully, but these errors were encountered: