Brian, wanted your opinion on exposing "nodes" on v1beta1 and v1beta2 as additional endpoints. Right now we allow posting objects of either api version (1 or 2) to any API endpoint, so this is really just allowing naive clients to also post to the old names. Downside is someone writing a new client in another language might not realize that not all v1beta1 servers support "nodes" (joys of additive apis).

Everything looks good, I'm just uncomfortable with removing the sanity checks. I added AddKnownTypeWithName in part to allow for type renames; can we make that work for this?

Unfortunately the type check happens inside conversion, and the lookup happens after we've already checked the type. Name func might be able to abstract it - I'll look at what options we have. It would require a map of all possible type conversions, or normalization to the same type in both places. Will look at it more - I agree safety is lost this way.

On Dec 8, 2014, at 7:48 PM, Daniel Smith notifications@github.com wrote:

Everything looks good, I'm just uncomfortable with removing the sanity checks. I added AddKnownTypeWithName in part to allow for type renames; can we make that work for this?

—
Reply to this email directly or view it on GitHub.

@smarterclayton I'm happier with polluting old API versions (v1beta1/2) to simplify conversion than new ones (v1beta3). Could we not add minions to v1beta3?

We can do that - when I expose v1beta3 I'll elide minions from the rest endpoints

On Dec 8, 2014, at 10:47 PM, bgrant0607 notifications@github.com wrote:

@smarterclayton I'm happier with polluting old API versions (v1beta1/2) to simplify conversion than new ones (v1beta3). Could we not add minions to v1beta3?

—
Reply to this email directly or view it on GitHub.

@lavalamp I reverted the type safety changes, and updated nameFunc to try to find a canonical name for a type by looking at the internal version. If we ever have both "minions" and "nodes" as their own objects (by introducing "minions" as something else in the new api version), we'll need to preserve more information when each type is registered (have an explicit "minions in v1beta1 resolves to nodes internally") but for now we don't need it.

Ready for re-review.

LGTM - thanks, that's exactly what I was hoping for.

Is it harmful to leave Minions out of v1beta3 entirely & not just omit them from the REST interface?

It helps us test both directions round trip, but it's not strictly useful to end users. We can always drop it from v1 without impact.

----- Original Message -----

LGTM - thanks, that's exactly what I was hoping for.

Is it harmful to leave Minions out of v1beta3 entirely & not just omit them
from the REST interface?

---

Reply to this email directly or view it on GitHub:
#2788 (comment)

LGTM. Kicked travis.

looks like it needs a rebase...

Rebased, no code changes needed. Waiting for green.

@GoogleCloudPlatform/kubernetes-write FYI Minions are now called Nodes internally, when reviewing code or adding new code we should be gradually phasing out "minion" in doc, functions, variables, etc and replacing it with "node". That may take a long time, but we should suggest it or do it ourselves when we see it.

For those of us who are new, what was the reason for the renaming? In my mind "minion" maps to a very specific set of components, whereas when I hear "node" I always wonder is the person talking about what we used to call "minion," or everything that runs in the VM, or everything that runs on the physical machine.

Was it perceived political correctness? (I liked "minion" too.)

#1111

Thanks for the pointer to #1111. It looks like the decision was to use "node" in the code and "kubernetes node" or "knode" in documentation and discussion. This seems reasonable, but I hope people actually do use "kubernetes node" or "knode" in documentation and discussion, because "node" is ambiguous for the reasons I mentioned in my previous comment.