In step 4, it would be easier to edit the yml file if the variables were in the same order in the file as in the table in the readme.md.

[mflannery]

Putting the table and the yml file variables in the same order makes it easier to edit the yml file.

Cheers! Mike

[jaredhocutt]

In my OpenShift 3 deployment tool, that's exactly what I did. I "grouped" similar items in the table of variables much like I do in the example variables file.

I debated what to do when I was writing this README and ultimately chose to go with an alphabetical listing so that it's easier to find what you're looking for in the table.

I'm not sure what the right answer is. I guess it depends on how you're trying to use it. If you're creating your variables file the first time, having it in the same order is helpful. But if you're looking to modify or add a variable later, then being able to find it alphabetically is helpful.

Thoughts?

[johnsimcall]

My opinion is that the vars file should be grouped by type/use and that the README.md should list the variables alphabetically for documentation purposes. The vars file would be difficult to navigate if we sorted it alphabetically. With only 8 variables described (currently) in the README.md, the inconvenience of scrolling a short distance to find the right variable is negligible.

If we change the vars file ordering, consider that pull_secret would come before rhcos_ami. This will obscure rhcos_ami in normal-sized terminal windows, potentially leading to deployment errors. Another concern of mine is that base_domain and cluster_domain would be separated by the cloud variable. The *_domain variables should appear next to each other in the vars file to highlight their inter-dependency, especially as it currently relates to the manual step of creating DNS records.

If we introduce many more variables in the future we could revisit this issue but in the short term I think we leave everything alone.