Summary
The operator now has a passthrough mechanism (#75) for arbitrary config values, but still only covers ~25-33% of each product's typed config fields. We should auto-generate these typed fields from the product documentation rather than maintaining them by hand.
Context
- Connect has ~200+ config values, operator defines ~65
- Package Manager has ~100+ config values, operator defines ~25
- Both use gcfg format with well-structured documentation at docs.posit.co
- The documentation HTML is consistently formatted and parseable (Section.Key headings with Type/Default metadata)
- Workbench is deferred — multiple config files, scattered docs, passthrough-only for now
Work
- Write a scraper/parser for the Connect and Package Manager configuration reference pages
- Generate Go structs with appropriate types, json tags, kubebuilder validation markers, and doc comments
- Define type mapping: doc types (string, boolean, integer, duration, byte-size, etc.) → Go types
- Handle enums via kubebuilder validation markers
- Output to
connect_config_generated.go and package_manager_config_generated.go
- Add CI job to detect drift between generated code and latest product docs
- Determine whether generation runs at build-time or as a periodic sync workflow
- Consider version tagging: generated code should record which product version it was generated from
- Consider how dev/pre-release product versions interact with generated configs (passthrough covers the gap)
References
Summary
The operator now has a passthrough mechanism (#75) for arbitrary config values, but still only covers ~25-33% of each product's typed config fields. We should auto-generate these typed fields from the product documentation rather than maintaining them by hand.
Context
Work
connect_config_generated.goandpackage_manager_config_generated.goReferences