Spec: Update the spec for federation

[johnbelamaric]

The current spec covers only a single cluster. It needs to be updated to reflect federation records and behavior.

[thockin]

The federation records need to be totally revamped - last I looked at them they were ambiguous. @csbell @madhusudancs

[csbell]

@thockin The best reference outside of code that I could find is located here. By revamp, do you mean merging the current federation behavior into the spec here or is there more involved?

[thockin]

Welcome to the real guts of the project :) From that doc: `mysvc.myns.myfed.svc.u7s.io` is proposed as an example. This is ambiguous. It could just as likely mean a pod "mysvc" ins a stateful set "myns" in namespace "myfed". The hope waas that the extra token was enough to disambiguate but it's not. This snuck in without me catching it, and now we need to find a way to fix it. We proposed something like `mysvc.myns.myfed.fed.u7s.io` as an alternative, but we need a plan to migrate people. Madhu might recall more details. @bowei

…

On Tue, Jan 17, 2017 at 6:53 AM, Christian Bell ***@***.***> wrote: @thockin <https://github.com/thockin> The best reference outside of code that I could find is located here <kubernetes/kubernetes#25107 (comment)>. By revamp, do you mean merging the current federation behavior into the spec here or is there more involved? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVG4pgnZQtHDUi4LeMtLnLD_zlx8Rks5rTNX6gaJpZM4LjQ0A> .

[bowei]

Given federation is still in its early stages, it would be great to get ahead of this issue

[madhusudancs]

Oh wow! Did not know about the existence of this repo and was hence missing the notifications.

We proposed something like mysvc.myns.myfed.fed.u7s.io as an alternative,
but we need a plan to migrate people. Madhu might recall more details.

This and in addition we had the literal svc somewhere in there, IIRC. Something like mysvc.myns.svc.myfed.fed. We still need to come up with a concrete migration plan.

There is also this doc that Quinton wrote - https://docs.google.com/document/d/1tSTgqSy7iR8cQx2z-bbqaYVITrraDQmV_aE43PuRPoI/edit#heading=h.ys8jzm2jzab9

[nikhiljindal]

Also ref kubernetes/kubernetes#27969

We proposed something like mysvc.myns.myfed.fed.u7s.io as an alternative,

We had also discussed supporting DNS names for ingress. So fsvc and fing should be better than fed.
Also, with that proposal, we will need more than 6 dots for stateful sets (extra dot for federation name). Is that acceptable?

Given federation is still in its early stages, it would be great to get ahead of this issue

+1.

[bowei]

@nikhiljindal One thing to keep in mind, increases in ndots can have a dramatic impact on performance.

When a name has fewer dots than ndots, external names result in 10 DNS lookups/name. Modulo negative caching, this can easily result in DNS server meltdown.

[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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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
/remove-lifecycle stale

[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