Endpoints entity_type is not plural about kubeclient HOT 9 CLOSED

The easiest (albeit ugly) fix for this problem would be to have a special case for "endpoint" in the create_entity method that sets the kind to "Endpoints".

from kubeclient.

@stephenjlevy,

1. Have you opened an issue/discussion in k8s repo on this inconsistency? it's better to get this fixed on server side instead of each client's custom handling. cc @thockin
2. What is your use case to manually create endpoints rather than use a selector and get them calculated and updated by the server?
   Is this something like the below example, or different?
   https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md#services-without-selectors

Thanks

cc @simon3z

from kubeclient.

@abonas Yes, we need the ability to create external services (services without selectors). Unfortunately, there's no way to declare the endpoints from within the service definition, so they must be declared manually.

I haven't opened an issue with the k8s developers about this...it's really a matter of semantics. When creating an endpoint entity type, you really do have the ability to create multiple "endpoints", which is why I guess they made it plural, although technically, you're only creating one endpoint entity type.

from kubeclient.

Yes, Endpoints objects are a set of individual IP endpoints. It's perhaps
an unfortunate name in the hidden double-pluralness - technically the REST
path should be "endpointses" I guess, but I don't think we're going to do
that.

I'd MAYBE be open to a better name, but that is a post-1.0 change, at
earliest.

As for defining endpoints for external services, we toyed with embedding an
Endpoints into Service as an alternative to Selector, but we just ran out
of time to explore it further.

On Tue, May 12, 2015 at 8:12 AM, stephenjlevy [email protected]
wrote:

@abonas https://github.com/abonas Yes, we need the ability to create
external services (services without selectors). Unfortunately, there's no
way to declare the endpoints from within the service definition, so they
must be declared manually.

I haven't opened an issue with the k8s developers about this...it's really
a matter of semantics. When creating an endpoint entity type, you really do
have the ability to create multiple "endpoints", which is why I guess they
made it plural, although technically, you're only creating one endpoint
entity type.

—
Reply to this email directly or view it on GitHub
#81 (comment).

from kubeclient.

@thockin we kind of worked in parallel :)
kubernetes/kubernetes#8115

from kubeclient.

@abonas so, how to be with Endpoints? I am not good in Ruby and I temporary created workaround like this:
khaliullov@4d328b0
but is so ugly.

from kubeclient.

@abonas so, how to be with Endpoints? I am not good in Ruby and I temporary created workaround like this:
khaliullov/kubeclient@4d328b0
but is so ugly.

Well, ideally it would have been fixed on server side so clients won't need workarounds.
However, given that it hasn't been addressed there yet, your solution seems correct, and I would suggest doing something like the below, just slightly more generic, that's all:

if entity_type.eql? 'Endpoint'
  hash[:kind] = resource_name(entity_type)
else
  hash[:kind] = entity_type
end

(tests addition is needed for endpoints to check that the url for various requests for creation/get/etc. is correct)

cc @simon3z

from kubeclient.

hash[:kind] = resource_name(entity_type)

@abonas we have to check if kind is case-insensitive (and also if we don't care about inconsistencies) because resource_name is downcasing the entity_type.

Anyway, even though it looks ugly we have to fix this, so overall 👍

from kubeclient.

@abonas we have to check if kind is case-insensitive (and also if we don't care about inconsistencies) because resource_name is downcasing the entity_type.

@simon3z
as you suspected it is case sensitive. so needs to be capitalized. no big deal.

from kubeclient.