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

Describe config.yaml syntax more prominently #56

Closed
AJMansfield opened this issue Feb 17, 2023 · 2 comments
Closed

Describe config.yaml syntax more prominently #56

AJMansfield opened this issue Feb 17, 2023 · 2 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@AJMansfield
Copy link

A significant number of the different configuration options are described in their respective documents only in terms of command-line argument passed to the rke2 binary, significantly burying the lede on being able to configure the server using the same keys and values in config.yaml.

Given that the quickstart install directions lead you to a configuration where changing the server's command line arguments is rather not straightforward, I'd wager that the config.yaml method is probably far more useful to most people following those directions, and information on how to do this needs to be a lot more prominent than it currently is, buried between several other less-relevant sections.

If nothing else, the section describing the equivalence between command-line arguments and config.yaml keys should be made a lot more prominent and discoverable. But I'd even argue that the config.yaml syntax should probably be the primary way of describing the configuration options themselves, with the command-line syntax only secondary.

For instance, take this paragraph:

To enable Multus, pass multus as the first value to the --cni flag, followed by the name of the plugin you want to use alongside Multus (or none if you will provide your own default plugin). Note that multus must always be in the first position of the list. For example, to use Multus with canal as the default plugin you could specify --cni=multus,canal or --cni=multus --cni=canal.

IMO this would probably be more useful if paragraphs like that were rewritten something along the lines of:

To enable Multus, add multus as the first list entry in the cni config key, followed by the name of the plugin you want to use alongside Multus (or none if you will provide your own default plugin). Note that multus must always be in the first position of the list. For example, to use Multus with canal as the default plugin you could specify:

# /etc/rancher/rke2/config.yaml
---
cni:
- multus
- canal

This can also be specified with command-line arguments, i.e. --cni=multus,canal or --cni=multus --cni=canal.


That paragraph above is actually specifically the one I just spent two days stumped on before finally figuring it out.

Just to describe my own experience here:
I had RKE2 set up and installed from the quickstart guide. I knew that I needed Multus for my use-case, and was able to find the Using Multus section, and therefore "knew" that I somehow needed to get --cni=multus,canal passed as a command-line argument... and then spent the next two days going down dead ends, reinstalling RKE2 half a dozen times, even just reading the RKE2 source code (e.g. to see if there was some undocumented option that would get the https://get.rke2.io installer script to append --cni=multus,canal to the ExecStart line in the rke2-server.service systemd unit file it created). It wasn't until near the end of day 2 combing through the docs and reading every bit on every page that I finally found what I needed with the config.yaml file.

@AJMansfield
Copy link
Author

If this is something of interest, I don't mind doing most of the leg-work to add a config file example for each CLI argument example -- but I did want to open the issue here first in case this isn't a change the maintainers would accept.

@brandond brandond added the documentation Improvements or additions to documentation label Feb 17, 2023
@dereknola
Copy link
Contributor

@AJMansfield Thanks for point this out, this problem is certainly relevant. I'll take a pass at rewording the docs and pushing config yaml values over flags.

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

No branches or pull requests

3 participants