From what I can tell in the existing generated code, the Content-Type header in patch requests will always come through as application/json-patch+json without a way to set it to either a merge or strategic merge.

select_header_content_type looks like it will always return the first json type in the passed in array, and it doesn't seem like there's a way to override the header_params:

Would the opts object be the right place to add a way to override this setting, or is that reserved for options configured in the gen repo?

Just like python client here and here, we need to support loading kubeconfig both in cluster and outside of the cluster.

ref: kubernetes/community#1721

This repo is listed in sigs.yaml as belonging to sig-api-machinery, but it lacks an OWNERS file. Can you please add one with the appropriate list of approvers and reviewers? eg:

• robust example: approvers, reviewers, aliases
• simple example: only approvers, no aliases

For more information see the OWNERS docs

/sig api-machinery

/assign @lavalamp @deads2k
sig-api-machinery chairs

/assign @mbohlool
as the person merging PR's recently

See kubernetes/kubernetes#70679

Hey there,

I tried to install this kubernetes client in my ruby on rails application.

I inserted this line in my Gemfile:
gem 'kubernetes', :git => 'https://github.com/kubernetes-client/ruby.git'

...and got the following error:
Could not find gem 'kubernetes' in https://github.com/kubernetes-client/ruby.git (at master@3386109). The source does not contain any versions of 'kubernetes'

Am I doing something wrong here!?

Thank you and best regards - Markus

Watch is a non-standard method that swagger-codegen does not support and we need to add support for it like other clients (e.g. python here)

Kubernetes::V1ServiceSpec.swagger_types indicates that selector is a hash: https://github.com/kubernetes-client/ruby/blob/master/kubernetes/lib/kubernetes/models/v1_service_spec.rb#L89

However, it is only loaded in initialize() if it is_a?(Array):
https://github.com/kubernetes-client/ruby/blob/master/kubernetes/lib/kubernetes/models/v1_service_spec.rb#L147

Based on the kubernetes Service Docs, it should be a hash: https://kubernetes.io/docs/concepts/services-networking/service/

gem install kubernetes
Fetching kubernetes-0.0.2.gem
Successfully installed kubernetes-0.0.2
1 gem installed

It installs version from 2014 https://rubygems.org/gems/kubernetes/versions/0.0.2

assumes a DNS name or ipv4 address... it does not work correctly with an ipv6 address (the ipv6 host must be wrapped in brackets)

Configure and package the client as a Gem.

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

Exec and Attach class are non-standard calls that kubernetes API server uses to connect to a port of a pod/container or execute a command on them. It uses SPDY or WebSockets. Normal calls to these endpoints will result in an upgrade request from API server. We need to support WebSocket for this client (for those endpoints). This is python implementation of the same feature.

Hey there @kubernetes-client/ruby-admins,

One of the github-admins here. -- We have a longstanding issue on cleaning up outside collaborators, and are now actively planning on removing them on December 1st.

At this point, people that are actively contributing to the Kubernetes project should be promoted to org members, and any repo specific permissions should be managed through their associated configuration in kubernetes/org.

With that in mind, the following people are listed as outside collaborators:

• @drubin

@drubin - is a member of the Kubernetes org already, and is implicitly allowed to be added to any of the other Kubernetes orgs 👍

@drubin Feel free to open a PR to kubernetes/org adding yourself to the kubernetes-client org.

Just a general reminder, not having direct permissions does not stop folk from contributing. It just means they'd have less permissions (would need /ok-to-test on PRs etc).

If you have any questions or comments, please don't hesitate to ask in here or feel free to poke me in slack 👍

Thanks!

assigning to ruby-admins
/assign @brendandburns

/sig contributor-experience
/priority important-soon

There are some hand-written codes in lib folder but which is deleted unintentionally on re-generation.

Here is the hand-written codes as far as I know:

kubernetes/lib/kubernetes/config/error.rb
kubernetes/lib/kubernetes/config/incluster_config.rb
kubernetes/lib/kubernetes/config/kube_config.rb
kubernetes/lib/kubernetes/utils.rb

To avoid the side effect of re-generation, I think we need to put those codes into a separate folder from one that auto-generated codes in.

I've read the proposal document about client library structure.
But I can't find core library for ruby.

I'm interested in this repository, so is there anything I can do?

Hi 👋, just wanted to reach out from the existing https://github.com/abonas/kubeclient project to ask how you see the relation between the 2 projects, and whether there are aspects we should work together on?

Taking a quick look, differences in approach that stand out:

1. The API in this gem is close to other official k8s clients. kubeclient tried to evolve a Ruby-esque api from scratch.

2. This gem is generated from specific k8s API, kubeclient uses discovery to define methods dynamically.
   Did you deliberately choose generation for specific benefits, or simply as outgrowth of generation tooling that worked well for other languages?
   Discovery in principle allows same client to talk to future k8s versions, to extra APIs (e.g. openshift), and perhaps most importantly to deal with custom resources (TBH I never tried kubeclient on CRDs myself but I hear it works).
   How would one deal with CRDs in your approach? Use same generator to create a separate gem?

3. This gem feels more "strongly typed". You have tons of classes e.g. V1PersistentVolume constiting of V1PersistentVolumeSpec and others... kubeclient previously dynamically created a class for top-level resources only, but gave up even that in favor of a generic Resource class.

4. Your generated docs are WAY more detailed :-)

5. Communication overhead? kubeclient currently uses rest-client for http, no persistent connections, full TLS setup for each request :( What do you use?

6. I'm interested to learn your approach to API groups, as this is a pain point in kubeclient we're trying to rethink. Currently kubeclient requires a separate client object for each API group, and lacks an easy way to share cluster configuration between those.
   IIUC (#19), you still need an object for each group you talk to but config sharing is trivial for single-global-config case and easy enough by passing ApiClient instance in multi-cluster case?

I have followed the Getting Started guide and every api call throws an exception with Not Found.

I have also tried using the in cluster config with the same error.

Setup:

Kubernetes: Minikube
Ruby: 2.3.3

Steps to reproduce

1. Start minikube
2. Follow steps in Getting Started

Creating or replacing resources calls select_header_content_type with ['*/*']. Currently that method returns '*/*', resulting in a "415 Unsupported Media Type" error from the kubernetes API. kubectl by comparison will send Content-Type: application/json in this situation:

The content type method appears to be significantly different from the version in, for example, the python client library. At least in this case, the python client has an exception to return application/json, while the ruby client does not and lets */* pass through:

https://github.com/kubernetes-incubator/client-python/blob/8665a7621c186fa533c215c42a0e7ed34978b3bf/kubernetes/client/api_client.py#L470-L485

Is there a reference implementation of this method that ruby should follow, or a reason for the differences between languages?

Steps to reproduce

• Regenerate the ruby client codes

$ cd kubernetes-client/gen/openapi
$ ruby.sh path/to/kubernetes-client/ruby/kubernetes/ path/to/kubernetes-client/ruby/settings


...
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.620 s
[INFO] Finished at: 2019-02-17T08:56:27Z
[INFO] ------------------------------------------------------------------------
---Done.
---Done.

• Some diffs exists in the generated codes

$ cd path/to/kubernetes-client/ruby/
$ git status

On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   kubernetes/kubernetes.gemspec
        modified:   kubernetes/lib/kubernetes.rb
        deleted:    kubernetes/lib/kubernetes/api_client.rb
        deleted:    kubernetes/lib/kubernetes/config/error.rb
        deleted:    kubernetes/lib/kubernetes/config/incluster_config.rb
        deleted:    kubernetes/lib/kubernetes/config/kube_config.rb
        deleted:    kubernetes/lib/kubernetes/utils.rb
        deleted:    kubernetes/spec/config/incluster_config_spec.rb
        deleted:    kubernetes/spec/config/kube_config_spec.rb
        deleted:    kubernetes/spec/config/matchers.rb
        deleted:    kubernetes/spec/fixtures/config/kube_config_hash.rb
        deleted:    kubernetes/spec/fixtures/files/certs/ca.crt
        deleted:    kubernetes/spec/fixtures/files/certs/client.crt
        deleted:    kubernetes/spec/fixtures/files/certs/client.key
        deleted:    kubernetes/spec/fixtures/files/config/config
        deleted:    kubernetes/spec/fixtures/files/config/empty
        deleted:    kubernetes/spec/fixtures/files/tokens/token
        deleted:    kubernetes/spec/helpers/file_fixtures.rb
        deleted:    kubernetes/spec/utils_spec.rb

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        kubernetes/swagger.json.unprocessed

deleted: kubernetes/spec/config/incluster_config_spec.rb
deleted: kubernetes/spec/config/kube_config_spec.rb
deleted: kubernetes/spec/config/matchers.rb
deleted: kubernetes/spec/fixtures/config/kube_config_hash.rb
...

I guessing that the deleted files under spec folder are hand-written codes, and those were deleted by the code generation step here.

Suggestion

I think generating spec files is not necessary as the auto-generated files under spec are just skelton.

• Remove spec from here
• Configure the exclusion for spec files in ruby.xml

What do you think about it? I would file a PR if the suggestion is OK.

Looking at Kubernetes.configure or Kubernetes.load_kube_config examples in the docs, it seems configuration is global for the gem.
And then one can do parameter-less api = Kubernetes::CoreV1Api.new; api.list_pod_for_all_namespaces.
This is convenient for common case, but does it preclude connecting to several clusters at same time with different auth?

Hmm, it seems CoreV1Api.new etc can take an ApiClient instance. And you can produce ApiClient from a Configuration:
https://github.com/kubernetes-client/ruby/blob/7f268172b/kubernetes/lib/kubernetes/utils.rb#L47
needs more docs...

Is this library abandoned? It appears there are no commits in 2 years and the example failed with Ruby 3.

https://github.com/kubernetes-client/ruby/blob/master/kubernetes/kubernetes.gemspec#L41-L42

Ruby 3 removed the deprecated encode method from the URI module. The usage at

We should use a linter to standardise our code.

I would suggest looking at https://rubocop.readthedocs.io/en/latest/ but we could also compare others.