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.

Sign up for GitHub

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

Jump to bottom

Support custom resources #69

Open
paralin opened this issue Dec 19, 2017 · 7 comments
Open

Support custom resources #69

paralin opened this issue Dec 19, 2017 · 7 comments
Labels
blocked Denotes issue blocked by 1+ other issue(s). enhancement User-facing functionality.
Milestone
Support custom re...

Comments

@paralin
Copy link

paralin commented Dec 19, 2017

It's now possible to build a Kubernetes client that learns of all possible resource types from the API, and also is able to access arbitrary resource types by name without a pre-compiled model for the types.

Would it be possible to do the same in kubernetes-el? I'd like to be able to list custom resources.
@chrisbarrett chrisbarrett added the enhancement User-facing functionality. label Dec 20, 2017
@jinnovation
Copy link
Collaborator

+1, the ability to list custom resources would be excellent and expand the use cases for this package significantly.

@noorul
Copy link
Collaborator

noorul commented May 9, 2021

@jinnovation I agree! I thought of using a shared informer to achieve this. It is a matter of free time.

@noorul noorul mentioned this issue Jun 15, 2021
Closed
@jinnovation
Copy link
Collaborator

It's worth noting here that, at least for the problem of a) listing which resource types are available on a given cluster, and b) retrieving resources of a given resource type, a custom Go backend using the shared informer pattern provided by the Kubernetes client package is arguably unnecessary.

For listing resource types, we have:

kubectl api-resources

For fetching resources of arbitrary type t (sourced presumably from the former's output), we can simply shell out to the following, like we currently do for the "native" resource types:

kubectl get t

There would naturally be necessary preliminary work to do in the package as a whole to genericize our handling of resources such that hardcodes like those here are no longer present or necessary. However, in terms of raw primitives necessary to enable the package to know of, retrieve, and display rudimentary information about CRDs, I believe we have the necessary primitives in kubectl to do so right now.

@jinnovation jinnovation changed the title Dynamic client Ability to retrieve resources of arbitrary/custom type, e.g. CRDs Aug 24, 2021
@jinnovation
Copy link
Collaborator

To that effect, I've taken the liberty of renaming this issue to—in my opinion—more accurately reflect the body of work in question. Continuing to call this issue "Dynamic client" would amount to putting the cart before the horse, i.e. describing a solution without first outlining the problem we're trying to solve.

@noorul
Copy link
Collaborator

noorul commented Aug 25, 2021

@jinnovation Yes, we should make it generic so that we can remove some of the hard codings as you mentioned.

@jinnovation jinnovation mentioned this issue Aug 25, 2021
Merged
jinnovation added a commit that referenced this issue Aug 25, 2021
@jinnovation
Genericize kubectl get operations (#196)
3e6870d 
Relates to #69.

Currently, we define one function for `get`ting all entities of a given resource type, for each of a finite set of resources, e.g. `k8s-kubectl-get-{pods, nodes, ...}`. All of these functions are identical save for the resource type that they retrieve.

As such, we generalize to a single implementation—`k8s-kubectl-get`—that accepts the resource type name and performs the `get` accordingly.

By extension, we rewire all call sites that assume the existence of per-type `get` functions to use the genericized counterpart—most notably the `kubernetes-state-define-refreshers` macro, which currently literally expects functions of those naming pattern to exist.

Similarly, we consolidate unit tests and, finally, remove the granular, per-type `get` functions.
@jinnovation jinnovation mentioned this issue Aug 26, 2021
Merged
jinnovation added a commit that referenced this issue Aug 26, 2021
@jinnovation
Genericize and consolidate kubectl delete operations (#198)
87e6de1 
Relates to #69.

Currently, we define one function for `delete`-ing all entities of a given resource type, for each of a finite set of resources, e.g. `k8s-kubectl-delete-{pods, nodes, ...}`. All of these functions are identical save for the resource type that they retrieve.

As such, we generalize to a single implementation—`k8s-kubectl-delete`—that accepts the resource type name and performs the `delete` accordingly.

We additionally clean up unit tests and, finally, remove the granular, per-type `get` functions. 

In particular, with regards to unit tests, we observe that, once the resource type name is abstracted away, there's no practical reason to have one test case for each resource type. As such, rather than consolidate all per-type test cases into a single test function, we simply keep one case for each of the two scenarios "delete success" and "delete fail," and remove the rest of the test functions as superfluous.
jinnovation added a commit to jinnovation/kubernetes-el that referenced this issue Aug 27, 2021
@jinnovation
State management: Create genericized getter for state attr access
4aebef1 
Relates to kubernetes-el#69.

Currently, retrieval of resource manifests from package state is handled through
resource-specific getters, generated via macro expansion,
e.g. `kubernetes-state-pods` for fetching pods and so on. This design is
extremely cumbersome and impedes genericization of resource type handling across
the package. For instance, consider the scenario where we want to fetch the
state of some resource `r` from package state. Doing so currently requires
interpolation and redirection gymnastics akin to the following:

```emacs-lisp
(funcall (intern (format "kubernetes-state-%s" 'r)) (kubernetes-state))
```

We can see this pattern throughout the package in its current form.

This PR extracts the "backbone" of the generated getters' logic to a genericized
analogue: `(kubernetes-state--get STATE TYPE)`. With this change, in the future,
the behavior demonstrated above can be simplified to:

```emacs-lisp
(kubernetes-state--get (kubernetes-state) 'r)
```

This PR leaves the current behavior intact, meaning that all state access
continues to go through the generated getter functions. However, the fact that
those generated getters now defer to `kubernetes-state--get` paves the way for
us to gradually phase out the generated getters in favor of, at each call site,
simply calling `kubernetes-state--get` directly.
@jinnovation jinnovation mentioned this issue Aug 27, 2021
Merged
jinnovation added a commit that referenced this issue Aug 27, 2021
@jinnovation
State management: Create genericized getter for state attr access (#200)
6d526f2 
Relates to #69.

Currently, retrieval of resource manifests from package state is handled through
resource-specific getters, generated via macro expansion,
e.g. `kubernetes-state-pods` for fetching pods and so on. This design is
extremely cumbersome and impedes genericization of resource type handling across
the package. For instance, consider the scenario where we want to fetch the
state of some resource `r` from package state. Doing so currently requires
interpolation and redirection gymnastics akin to the following:

```emacs-lisp
(funcall (intern (format "kubernetes-state-%s" 'r)) (kubernetes-state))
```

We can see this pattern throughout the package in its current form.

This PR extracts the "backbone" of the generated getters' logic to a genericized
analogue: `(kubernetes-state--get STATE TYPE)`. With this change, in the future,
the behavior demonstrated above can be simplified to:

```emacs-lisp
(kubernetes-state--get (kubernetes-state) 'r)
```

This PR leaves the current behavior intact, meaning that all state access
continues to go through the generated getter functions. However, the fact that
those generated getters now defer to `kubernetes-state--get` paves the way for
us to gradually phase out the generated getters in favor of, at each call site,
simply calling `kubernetes-state--get` directly.
This was referenced Aug 27, 2021
Closed
Merged
Merged
jinnovation added a commit that referenced this issue Aug 28, 2021
@jinnovation
Genericize state-getters for marked resources (#204)
1a9d841 
Relates to #69.

This PR removes the resource-specific getters for "marked" default k8s resources, e.g. pods and deployments, in favor of the generic counterpart introduced in #200.

## Side Note

As we move forward with resource-handling genericization, it might benefit us to likewise look into a more generic handling of marked status for resources, rather than introduce one new field in the state alist for each resource. We can have that discussion elsewhere.
jinnovation added a commit that referenced this issue Aug 28, 2021
@jinnovation
Genericize state-getters for default k8s resources (#203)
e9baa26 
Relates to #69.

This PR removes the resource-specific getters for default k8s resources, e.g. pods and deployments, in favor of the generic counterpart introduced in #200.
jinnovation added a commit to jinnovation/kubernetes-el that referenced this issue Dec 2, 2021
@jinnovation
Extract generic form of resource force-refresh logic
7ba5ebc 
Relates to kubernetes-el#69.

This PR extracts the core of the resource-specific
`kubernetes-<resource>-refresh-now` functions into the resource-generic
`kubernetes-state--refresh-now` function. This function represents the "core" of
the function template used to generate the resource-specific force-refresh
functions.

This PR leaves the resource-specific refresh-now functions in place,
re-implementing them as wrappers around the new resource-generic version. The
resource-specific functions have test coverage, which provides a vote of
confidence as to the safety of this change. We'll leave sunsetting of the
resource-specific functions' use to subsequent PRs.
@jinnovation jinnovation mentioned this issue Dec 2, 2021
Merged
jinnovation added a commit that referenced this issue Dec 2, 2021
@jinnovation
Extract generic form of resource force-refresh logic (#229)
79c5d1e 
Relates to #69.

This PR extracts the core of the resource-specific
`kubernetes-<resource>-refresh-now` functions into the resource-generic
`kubernetes-state--refresh-now` function. This function represents the "core" of
the function template used to generate the resource-specific force-refresh
functions.

This PR leaves the resource-specific refresh-now functions in place,
re-implementing them as wrappers around the new resource-generic version. The
resource-specific functions have test coverage, which provides a vote of
confidence as to the safety of this change. We'll leave sunsetting of the
resource-specific functions' use to subsequent PRs.
@jinnovation jinnovation added this to the Support custom resources milestone Dec 12, 2021
@jinnovation jinnovation mentioned this issue Dec 12, 2021
Closed
5 tasks
@jinnovation jinnovation added the blocked Denotes issue blocked by 1+ other issue(s). label Dec 12, 2021
@jinnovation
Copy link
Collaborator

I've created a milestone to account for all the disparate tasks that need to be taken care of in order to effectively support CRDs.

@jinnovation jinnovation mentioned this issue Dec 12, 2021
Open
@jinnovation
Copy link
Collaborator

We've made some good progress here. See #237, #238, and #239 for details.

@jinnovation jinnovation pinned this issue Aug 26, 2022
@jinnovation jinnovation changed the title Ability to retrieve resources of arbitrary/custom type, e.g. CRDs Support custom resources Aug 26, 2022
jinnovation added a commit to jinnovation/kele.el that referenced this issue Jan 20, 2023
@jinnovation
docs: expand on comparison w/ kubernetes-el
7f48242 
This commit expands our comparison of Kele against `kubernetes-el` to call out
the latter's incomplete support of the core
API (kubernetes-el/kubernetes-el#306) **in addition** to lack of support for
custom resources (kubernetes-el/kubernetes-el#69).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
blocked Denotes issue blocked by 1+ other issue(s). enhancement User-facing functionality.
Projects
None yet
Milestone
Support custom resources
Development

No branches or pull requests
4 participants
@noorul @paralin @chrisbarrett @jinnovation