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

Is it possible to use this client with rancher v2.6.0? #22

Open
abhi1693 opened this issue Sep 4, 2021 · 4 comments
Open

Is it possible to use this client with rancher v2.6.0? #22

abhi1693 opened this issue Sep 4, 2021 · 4 comments

Comments

@abhi1693
Copy link

abhi1693 commented Sep 4, 2021

I trying to add a cluster repo, but I found it at the v1 endpoint and I cannot figure out how to use the client to add the repo

@vincent99
Copy link

vincent99 commented Sep 4, 2021

Cluster Repos are a CRD in the "downstream" cluster. You should use the regular Kubernetes API or a client for it to interact with resources in downstream clusters.

@abhi1693
Copy link
Author

abhi1693 commented Sep 4, 2021

@vincent99 Does that mean that this library is going to be deprecated in the near future? Because if I have to use native tools, I don't understand what good is this client for then? I have spent 2 years creating an application stack using this library as the base for deploying and interacting with downstream clusters and I would hate to replace all of that hard work

PS: I apologize if I sound rude.

@vincent99
Copy link

This library hasn't really changed in years, because it does everything by reading schemas from the endpoint and knows absolutely nothing about Rancher or Kubernetes. It contains no code specific to them, and exists basically unchanged since before Rancher or Kubernetes existed (we open-sourced the implementations at a previous company). So that part isn't going anywhere.

Nor is what exists in /v3 today for the foreseeable future. That is still the right place to manage Rancher-specific global-level resources and things that "live" in the management/"local" resources.

But we are no longer creating new public APIs for downstream clusters that present k8s resources in the format this client uses (exposed in /v3).

For downstream has always been primarily for the UI to consume, supported only a small subset of the hundreds of types you might have in the cluster (the ones the UI shows), required using projects and only namespaces in one, etc.

The newer explorer UI does not use that for showing you the resources in the selected cluster. It supports all resource types, any namespace regardless of whether it's in a project, etc. So we're not adding newer features to the older API.

The K8s API is not really _that _ different and there are lots of clients, so you'll probably find it wouldn't be that much work to start using for new types.

Or if you REALLY want there is actually a new API (at /k8s/clusters/(id)/v1) that the new UI uses and that does still use the spec this client implements, and you could find clusterrepos in there. It is a mostly mechanical translation of k8s to that format, with a few features that makes building the UI easier/faster/possible. But we consider this an internal implementation detail and it is explicitly not documented and could have breaking changes in any release.

@abhi1693
Copy link
Author

abhi1693 commented Sep 4, 2021

@vincent99 Well, thanks for the info. I have made all the changes I needed already with this library to make it all work with v2.6.0. The test case deploying monitoring v2 at https://github.com/rancher/rancher/blob/f7516246e8f75178c8e2a4827eb0cd25a600dcd8/tests/validation/tests/v1_api/test_monitoring_v2.py#L21 helped me to understand how it works.

We will migrate our codebase away from this library in the future for the downstream clusters.

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

No branches or pull requests

2 participants