Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken links #15

Open
kosyfrances opened this issue Dec 18, 2018 · 4 comments
Open

Broken links #15

kosyfrances opened this issue Dec 18, 2018 · 4 comments

Comments

@kosyfrances
Copy link

In Validation and Generators section, the link infer is broken.

To make that work, kubectl will infer the resource type if the generator name wasn't explicitly specified using the --generator flag.

In API groups and version negotiation section, the find the appropriate API group and version and assembles a versioned client links are broken.

Anyhow... After kubectl generates the runtime object, it starts to find the appropriate API group and version for it and then assembles a versioned client that is aware of the various REST semantics for the resource.

In same section as above, the send and based on the desired output format links are broken too.

The final step is to actually send the HTTP request. Once it does so and gets back a successful response, kubectl will then print out a success message based on the desired output format.

In etcd section, I think the generic apiserver is created url points to a different line on the file.

  1. When this happens, a generic apiserver is created that serves as a default implementation.

In Scheduler section, the filters pods link is broken.

In this case, it filters pods that have an empty NodeName field in their PodSpec and attempts to find a suitable Node that the pod can reside on.

@egernst
Copy link

egernst commented Feb 7, 2019

I see the same, @kosyfrances

I'll look into fixing these, but could use some input. I can:

  • use latest, and these will break again some time soon, or
  • this doc could point to code, which wouldn't necessarily be the latest, but be based on SHA of the HEAD of kubernetes/kubernetes, and guarantee to point to the latest code, viewable on GitHub, at the time of writing.

@egernst
Copy link

egernst commented Feb 7, 2019

@jamiehannaford - WDYT?

@jamiehannaford
Copy link
Owner

Pinning to a sha is reasonable IMO. Unfortunately I don't have the bandwidth to keep these docs up to the date with the latest code.

@ankitpateledu
Copy link

can we use a particular tag or release as reference ; it wont remain upto date in future; but the reader will get complete full understating and if needed he/she should be able to follow latest code as well.

I am eagerly waiting for these links to be fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants