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

Incorrect docs of port object in NavLink #1409

Open
lindhe opened this issue Jul 29, 2024 · 4 comments
Open

Incorrect docs of port object in NavLink #1409

lindhe opened this issue Jul 29, 2024 · 4 comments

Comments

@lindhe
Copy link
Contributor

lindhe commented Jul 29, 2024

The docs seems to indicate that the .spec.toService.port field of a NavLink object is a string:

But API spec seems to disagree:

$ kubectl explain navlinks.ui.cattle.io.spec.toService.port
GROUP:      ui.cattle.io
KIND:       NavLink
VERSION:    v1

FIELD: port <Object>

DESCRIPTION:
    <empty>

I'm running Rancher v2.8.5. I have no idea when the API broke. I'm pretty sure it was a string back in v2.7.8.

I'm guessing the docs should be updated to adhere to the API spec. I am unsure of how exactly, since the API spec just says "Object" but no specifics. 😕

@lindhe lindhe changed the title Fix docs of port object in NavLink Incorrect docs of port object in NavLink Jul 29, 2024
@lindhe
Copy link
Contributor Author

lindhe commented Jul 29, 2024

Wait a minute… Creating a NavLink via the Rancher GUI also sets port: "80". Is the API spec wrong??

@martyav
Copy link
Contributor

martyav commented Aug 9, 2024

@lindhe we took a look at https://github.com/rancher/rancher/blob/release/v2.8.5/pkg/apis/ui.cattle.io/v1/types.go#L33 and technically the port field is an intstr, which is an Object, but the intent is clearly to accept values that are entered as either integers or strings. And the GUI must only be sending strings.

@lindhe
Copy link
Contributor Author

lindhe commented Aug 12, 2024

Ah, I see. Alright. I'm guessing the API docs are generated directly from the code, so there's probably not much to do about the type then. Unless there is some hint we can use to help the API docs?

In that case, perhaps we can at least add a description so it's possible to read the information that way?

@martyav
Copy link
Contributor

martyav commented Aug 13, 2024

I brought it up to the API team

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

No branches or pull requests

3 participants