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

Update install-xcp-ng.md #266

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

kevemueller
Copy link

Added section on advanced installer parameters.

Before submitting the pull request, you must agree with the following statements by checking both boxes with a 'x'.

  • "I accept that my contribution is placed under the CC BY-SA 2.0 license [1]."
  • "My contribution complies with the Developer Certificate of Origin [2]."

[1] https://creativecommons.org/licenses/by-sa/2.0/
[2] https://docs.xcp-ng.org/project/contributing/#developer-certificate-of-origin-dco

Added section on advanced installer parameters.

Signed-off-by: Keve Müller <[email protected]>
@stormi stormi requested a review from ydirson April 2, 2024 11:00
@stormi
Copy link
Member

stormi commented Apr 2, 2024

Thanks for your contribution! This looks useful but needs to be also reviewed against existing docs in https://github.com/xcp-ng/host-installer/blob/master/doc/ and raises questions about duplication of information where one may become obsolete while the other is updated.

Also, I wouldn't list deprecated items.

@kevemueller
Copy link
Author

Hi Stormi,
this information was necessary for me to get xcp-ng installed in the first place (network_device is a must if you have multiple cards). It is not obvious where to look for it if you are on the xcp-ng site. Indeed I have found host-installer documentation and used it as a guideline.
IMO this information must be easily accessible directly from the xcp-ng installation page.
The txt file in the repo may as well be removed in favour of the clear and up-to-date information on the web.
As for deprecated options, I would mark them deprecated, but still list them. I don't have the history to tell which is deprecated and the code would not tell me.

Happy to review, resubmit based on specific feedback.

@ydirson
Copy link
Contributor

ydirson commented Apr 3, 2024

What about just linking to https://github.com/xcp-ng/host-installer/blob/master/doc/parameters.txt instead, and submit improvements as patches to the official doc?
Maybe we should setup a 8.2 ref in there so we could separately link to the docs pertaining to each release, BTW.
We could also consider submitting patches upstream to make those docs proper Markdown for better reading.

@kevemueller
Copy link
Author

Hi Yann,
the place of this file is not easy to find, especially if you do not know of its existence. The information in it is valuable for anyone browsing https://docs.xcp-ng.org/ so that is the primary place I would expect it to be.
As a newcomer to xcp-ng you just read its documentation, and if something is not there, you just expect it not to exist.

You have there in the appendix a reference for the answerfile and a reference for xe. The crucial missing first piece in the chain, the reference for the boot parameters would fit there very well. Neither of these two appendices are "authoritative" either, but they are there for a good reason.

Feel free to close this as not mergeable if you disagree.

@olivierlambert
Copy link
Member

I think the Appendix section could be a right fit for it. In theory with Docusaurus, we could have "namespace" for each release, but just for this extra content, I don't think it's a big deal.

About duplicating the content, I agree it's suboptimal, but @kevemueller has a fair point about discoverability.

@ydirson
Copy link
Contributor

ydirson commented Apr 4, 2024

I think the Appendix section could be a right fit for it. In theory with Docusaurus, we could have "namespace" for each release, but just for this extra content, I don't think it's a big deal.

This is actually a place where some content actually changes from 8.2 to 8.3, some options removed (due to removal of DOS disklabel) and some added (control over *gpgcheck). And more could come from our pending PRs.

About duplicating the content, I agree it's suboptimal, but @kevemueller has a fair point about discoverability.

I'd think linking to the content would address the discoverability issue?

@olivierlambert
Copy link
Member

You won't be able to use the search, parsing for arguments (since the text is parsed by Algolia). That's why I'm talking about discoverability :)

@ydirson
Copy link
Contributor

ydirson commented Apr 4, 2024

You won't be able to use the search, parsing for arguments (since the text is parsed by Algolia). That's why I'm talking about discoverability :)

Ah, what we need is rather an include mechanism, then!

@olivierlambert
Copy link
Member

I don't think it's possible sadly (or not easily). I prefer to keep people inside our doc than having to browser all around, at least a dedicated page with various examples (the most common things to use) and a link to the complete documentation will probably be a lot better than just a link provided somewhere. That could be a good intermediate solution.

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

Successfully merging this pull request may close these issues.

None yet

4 participants