Explicit config [WIP]

[Adam-D-Lewis]

Reference Issues or PRs

Fixes #2122, based on #2348 which should be merged first

Currently, we set all the nebari-config fields manually in

nebari/src/_nebari/initialize.py

Line 33 in 0210a47

def render_config(

but it's confusing for users to not see some useful parts of the config (e.g. #2122). We could add more fields to render_config method, but every time we add a new field in any InputSchema, we'd have to update the render_config method which is inconvenient. Additionally, having the fields hard coded in render_config means Nebari extensions don't have their InputSchema's written to the config file even if installed. They would need to be added some other way (e.g. typing them in manually) in order to control the extension's settings exposed by it's InputSchema.

This PR instead writes all of the InputSchema's to the nebari-config file by default, but this led to some confusing config in cases like infrastructure InputSchema where this PR caused a section to be added for each of "local", "existing", "google_cloud_platform", etc. for each cloud prodiver and all except one of these provider sections was blank.

nebari/src/_nebari/stages/infrastructure/__init__.py

Lines 540 to 546 in 0210a47

	class InputSchema(schema.Base):
	local: Optional[LocalProvider]
	existing: Optional[ExistingProvider]
	google_cloud_platform: Optional[GoogleCloudPlatformProvider]
	amazon_web_services: Optional[AmazonWebServicesProvider]
	azure: Optional[AzureProvider]
	digital_ocean: Optional[DigitalOceanProvider]

So this PR also allows InputSchemas to define a exclude_from_config method which returns the names of the fields to exclude from the config file to fix this issue. We likely could address this issue by separating the different providers into separated Pydantic Models (similar to what I've done to the certificate Pydantic models), but I feel it's important to have some mechanism to manually exclude portions of the InputSchema from being written to the nebari-config file when running nebari init, and have to chosen to address the extra providers with exclude_from_config.

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe): nebari init results in a more complete nebari-config.yaml

Testing

• Did you test the pull request locally?
• Did you add new tests?

Any other comments?

[Adam-D-Lewis]

Opened an RFD to address new requirements - nebari-dev/governance#48

[Adam-D-Lewis]

This fixes a deprecation warning from ruff.