-
Notifications
You must be signed in to change notification settings - Fork 2
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
RFD - Proposal for more explicit nebari-config.yaml #48
Comments
Ruamel does not seem flexible enough to write the config as I've described it. I think we'll need to write our own yaml writer if we want to accomplish default values being commented out. I'm also appreciating more fully that it may be difficult to change the commented out default values when running nebari upgrade. It'd be easier to just have a cli command to regenerate the config file preserving the values that have been set explicitly. |
@Adam-D-Lewis, this looks great!! Based on what was discussed during our last meeting, having all the values in the yaml by default would be great. My overall perspective on this would be:
On a side note, regarding dynamically updating the docs on conda-forge, for example (this doc for the conda-forge.yml schema):
|
We have the pydantic models here; Thanks @viniciusdc, that sounds very useful and I'll work on adding something similar for Nebari. |
No worries. I think this would be a separate issue, though, a the docs repo. For this RFD, I suggest:
|
I think @viniciusdc is dead on. There is room for further refinement later, but this seems to be the most direct line to delivering value. I think additional related tickets would be:
|
As far as generating a nebari config with commented out sections, the tomlkit library looked promising. https://tomlkit.readthedocs.io/en/latest/quickstart/#writing |
I like this idea @viniciusdc of autogenerating some docs from openapi.json, but it seems like we'd need some typescript expertise to create this which I don't think any contributors have at the moment. Is that your understanding as well? |
Talking with other members of nebari core team, we propose that we add this as a non default cli flag that can be enabled for the time being e.g. PR here: nebari-dev/nebari#2294 |
We merged a PR adding |
Proposal for more explicit nebari-config.yaml
Summary
The average user doesn't know what options they have available to them to adjust from
nebari-config.yaml
. Those who deploy fresh deployments may run into the situation where they need to adjust these immediately (see here, and it's not apparent how to do so and not straightforward at the moment.Additionally, extensions InputSchema are not currently written to nebari-config.yaml, meaning users have to copy those in manually to manage them from nebari-config.yaml.
User benefit
Users will better understand what they can configure from the nebari-config.yaml file. They will also see what they've set to custom values easily since those will be the only values not commented out.
Design Proposal
The following features are a part of this design proposal.
nebari-config.yaml
nebari upgrade
should notice the updated defaults and update the corresponding commented out default values in nebari-config.yamlA sample nebari config.yaml might look something like below under this design proposal (inspired from grafana's defaults.ini)
Not all Nebari config will be shown. Instead, just the config relevant to what they've chosen in the nebari init command will be shown.
E.g. Only the e.g. aws provider will be shown instead of all the cloud provider config sections.
Alternatives or approaches considered (if any)
We could allow more flexibility by allowing each stage to have it's own write_config method which returns yaml, but I'm not sure we have a use case for that currently and it's nice to enforce some stylistic uniformity between the sections.
Best practices
User impact
Unresolved questions
The text was updated successfully, but these errors were encountered: