Moving windows networking information to a new page

[marosset]

Signed-off-by: Mark Rossetti [email protected]

Moving Windows networking information to a new page.

Part of #31428

/label refactor
/sig windows

[netlify]

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

Name	Link
🔨 Latest commit	641aa2c
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/624c9e4bd3b5f30009fad8a6

[marosset]

@brasmith-ms @daschott @jayunit100
We should review/update this page for accuracy too. I mostly just copy/pasted what was present in the intro-to-windows page.

[marosset]

Hmm, perhaps this page should go under /concepts/services-networking/
What do people think?

[jihoon-seo]

Previews: (Because Netlify GitHub bot is not updating its comments properly 🤔)

• https://deploy-preview-31852--kubernetes-io-vnext-staging.netlify.app/docs/reference/windows/windows-networking/
• https://deploy-preview-31852--kubernetes-io-vnext-staging.netlify.app/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#:~:text=Check%20the%20DNS%20limitations%20for%20Windows%20in%20this%20section.
  (I confirm that for now the updated link works. 😊)

[sftim]

Would it be reasonable to put “Networking on Windows Nodes” within https://kubernetes.io/docs/reference/node/ ?

[sftim]

If this merges, I can update #30817 to link to the information about Windows specifics.

[marosset]

Would it be reasonable to put “Networking on Windows Nodes” within https://kubernetes.io/docs/reference/node/ ?

Let me move some sections out of this document and into the existing pages (like DNS limitations to https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) and then we can see what information is left.

If I was a user I think I expect some of the information in this page to be near other pages in https://kubernetes.io/docs/concepts/services-networking/ . I also think we can probably remove "node" from the page heading to make it better fit in here.
I'm also OK moving it to /reference/node/ if folks agree that is a good place.

What do you all think? @immuzz @aravindhp @jsturtevant @jayunit100 @perithompson @brasmith-ms

[aravindhp]

Let me move some sections out of this document and into the existing pages (like DNS limitations to https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) and then we can see what information is left.

If I was a user I think I expect some of the information in this page to be near other pages in https://kubernetes.io/docs/concepts/services-networking/ . I also think we can probably remove "node" from the page heading to make it better fit in here.

My vote is for the above.

I'm also OK moving it to /reference/node/ if folks agree that is a good place.

I not sure if users would end up on this page looking for Windows networking information.

[marosset]

Let me move some sections out of this document and into the existing pages (like DNS limitations to https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) and then we can see what information is left.
If I was a user I think I expect some of the information in this page to be near other pages in https://kubernetes.io/docs/concepts/services-networking/ . I also think we can probably remove "node" from the page heading to make it better fit in here.

My vote is for the above.

I'm also OK moving it to /reference/node/ if folks agree that is a good place.

I not sure if users would end up on this page looking for Windows networking information.

Updated - PTAL

[marosset]

@bridgetkromhout FYI too!

[aravindhp]

Thanks for doing this, @marosset

LGTM

[sftim]

Thanks, this layout looks OK.

I've suggested a few tweaks; the key thing to address is heading levels. Other feedback is nits.

[sftim]

Suggested change

	Setting the maximum session sticky time for services that run on Windows is not supported.
	Setting the maximum session sticky time for Services that run on Windows is not supported.

What does it mean for a Service to “run on” Windows. For example, if I run two Deployments and select both deployments with a single Service, what happens?
I'm guessing it's undefined behavior, but maybe I'm wrong?

[marosset]

Good question and I was struggling with the wording here.
Services are not tied to any OS.
Does something like:

Setting the maximum session sticky time for services connected to pods running on Windows nodes is not supported?

Unfortunately, I'm not sure exactly what does not work in this scenario and was copying this from other parts of the docs :(

[marosset]

I fixed the capitalization. Leaving this comment open for the additional discussions.

[jsturtevant]

This is a good start to make changes easier to manage for the Windows docs. The Windows networking do need some more love but this is a good start to making it easier to do so in the future.

[tengqm]

This PR has been dangling for over a month. I'd like to move this forward instead of blocking it for trivial issues.
/approve

[tengqm]

/label tide/merge-method-squash

[marosset]

I can address most of the easy comments today after some community meetings.

[marosset]

/hold
We want all the PRs that break up /modify https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/
See #31851 (comment)

[tengqm]

@marosset Could you please elaborate what do you mean by "We want all the PRs..."? Do you intend to merge all these refactor PRs into a single one, or break the huge task into several pieces? For the sake of easier reviewing, I'd like to suggest the second approach. However, the overall plan and pace would be up to you. Hopefully, these changes are not introducing a lot of dangling links between them.

[sftim]

What I suggested (this was in the SIG Docs meeting) was that once there are a bunch of PRs that are ready to merge into the main branch, SIG Docs can help get those merged.

In my view, there great part of the effort is lining up PRs that are good to merge, and actually merging them is more restricted (needs an approver's time) but less effort.

We also agreed in that meeting to continue working towards doing that merge after the v1.24 release.

[k8s-ci-robot]

@marosset: PR needs rebase.

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.

[nate-double-u]

Hi @marosset, I don't think this PR should target dev-1.24

[marosset]

/close
I will squash the commits and create a single PR with all of the related changes targeting main.

[k8s-ci-robot]

@marosset: Closed this PR.

In response to this:

/close
I will squash the commits and create a single PR with all of the related changes targeting main.

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.

[nate-double-u]

/milestone clear

[sftim]

(sorry about the mixed messaging here @marosset)
You'll likely have an easier time of it if you hold of making that single PR until after the v1.24 release.

The way I suggest you do that is by waiting 'til then, making a new branch, and then merging in all of your existing work. If you then want to rebase against main, or against the merge point for the v1.24 release, that's tidier but optional.

[marosset]

(sorry about the mixed messaging here @marosset) You'll likely have an easier time of it if you hold of making that single PR until after the v1.24 release.

The way I suggest you do that is by waiting 'til then, making a new branch, and then merging in all of your existing work. If you then want to rebase against main, or against the merge point for the v1.24 release, that's tidier but optional.

No worries.
Yea, I was thinking about waiting for 1.24 release - thanks for the advice!