openshift-docs
openshift-docs copied to clipboard
GitHub-16568: Reordering fields to match the expected order
Version(s): 4.9+
Issue: Fixes #46568
Link to docs preview:
- http://file.rdu.redhat.com/~ahoffer/2022/github-16568/authentication/configuring-internal-oauth.html#customizing-the-oauth-server-url_configuring-internal-oauth
- http://file.rdu.redhat.com/~ahoffer/2022/github-16568/web_console/customizing-the-web-console.html#customizing-the-web-console-url_customizing-web-console
LGTM!
@xingxingxia can you please QE review this update?
Link to docs preview:
- http://file.rdu.redhat.com/~ahoffer/2022/github-16568/authentication/configuring-internal-oauth.html#customizing-the-oauth-server-url_configuring-internal-oauth
- http://file.rdu.redhat.com/~ahoffer/2022/github-16568/web_console/customizing-the-web-console.html#customizing-the-web-console-url_customizing-web-console
Right, the display of kubectl/oc's subcommands like get -o yaml
, edit
, explain
et al print the fields alphabetically. So, while following our documents, if user runs edit
to edit existing fields and sees the display differs from the documents, he/she may be confused.
But by default, these customization fields are not existent in a fresh env, so user only adds new fields rather than edits the existing fields at the beginning. In terms of this, the documents do not have problem.
Anyway, ordering as per the original issue's request is fine. Other problems come as below, though. Need they be updated too?
oc edit ingress.config.openshift.io cluster
will show:
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
spec:
domain: <...>
componentRoutes:
- hostname: <...>
It shows "domain: " but documents don't show, will other users have new confusion about this? And fields under componentRoutes show 4 space indentation:
componentRoutes:
- hostname: <custom_hostname>
name: oauth-openshift
but the documents differ with 6 space indentation:
componentRoutes:
- hostname: <custom_hostname>
name: oauth-openshift
will some careful users have separate confusion about this?
This is an excellent explanation of what's going on. 👍
So why not, instead of modify the documentation and reordering stuff like aI previously suggested, just add as a comment to documentation your explanation? It will not only clarify it but will also teach users something new.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale