Adding fluent bindings

[silasbw]

This is a summary of the options briefly discussed in #230 (comment).

https://github.com/godaddy/kubernetes-client is a fluent JavaScript language API binding and includes experimental support for using https://github.com/kubernetes-client/javascript as it's backend. It could makes sense to move https://github.com/godaddy/kubernetes-client to https://github.com/kubernetes-client. I summarize three options for doing this below:

Option 1: separate repository, separate npm module

Pros:

• Close to what exists today, easy to orchestrate in the short term.

Cons:

• Separate JavaScript client repositories and modules could be confusing to end users.
• Might be cumbersome for maintainers to make major changes (e.g., breaking ones) across multiple repositories.

Option 2: same repository, same npm module

Move godaddy/kubernetes-client to kubernetes-client/javascript/fluent and expose the godaddy/kubernetes-client bindings via require('@kubernetes/client-node/fluent').

Pros:

• Easy for end users because there's a single repository and module for Kubernetes JavaScript clients.
• Facilitates making larger changes across both client types

Cons:

• Existing users of @kubernetes/client-node will pull in superfluous dependencies from godaddy/kubernetes-client (FWIW, the list is short and will get shorter once @kubernetes/client-node is the backend for `godaddy/kubernetes-client).
• More work for merging (e.g., documentation/README.md, package.json scripts, etc).

Option 3: same repository, separate npm modules

Move godaddy/kubernetes-client to kubernetes-client/javascript/fluent and expose the godaddy/kubernetes-client via the existing npm module, or a new one.

Pros:

• Existing users of @kubernetes/client-node do no pull in dependencies for godaddy/kubernetes-client by default
• Facilitates making larger changes across both client types

Cons:

• Monorepos for JavaScript/npm modules can require special tooling to do it well in some circumstances.
• The same repo, but different npm modules could lead to confusion for end users

[silasbw]

@brendandburns thoughts? Specifically on Option 2 vs Option 3? Have you crossed this bridge with any of the other clients?

[brendandburns]

I don't have a really strong opinion. I don't think that most NPM users are worrying too much about the transitive dependencies :)

If I had to vote, I think I'd vote for #3 as that's closer to what we're doing for Java, but I'd vote for whatever is easiest/happiest to implement more strongly...

(and apologies for the delay, I was on vacation)

[silasbw]

OK. I'm actually heading out on vacation. I'll take a pass at this when I get back.

[brendandburns]

Cool, have a good break!

[brendandburns]

@silasbw are you back? No rush, but it would be fun to get this going.

[silasbw]

Hey @brendanburns -- yes, and planning on spending time on this this week. I haven't thought very carefully about how to actually do this. Do you have a specific process you'd like me to follow?

One strawperson proporsal for how to do Option 3 is to submit a PR to this repository that copies the https://github.com/godaddy/kubernetes-client code into a fluent directory and we discuss issues in that PR (e.g., license updates, npm publishing, etc).

I also found https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-new-client-library-procedure.md and could define stages and support for "fluent". I can do that before or after moving the code. Do you have a preference?

[brendandburns]

I like the strawperson proposal. Let's treat this as an experiment to learn what fluent might mean, and then do a KEP to change the library procedure in general using our learnings?

(sorry for the delay in responding....)

Looking forward to it!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

Details

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.