jmdeal
commented
3 months ago I'm personally in favor of option 2. It does mean we wouldn't be able to perform runtime validation of the config, but I think that's worth the benefit of not coupling the Karpenter version to a specific version of the Bottlerocket config schema. Autogen would definitely be an improvement over what we have today, but a Karpenter version would still be coupled to the config schema at the time of release.
Description
What problem are you trying to solve?
Every time there is a setting that we don't support in https://github.com/aws/karpenter-provider-aws/blob/main/pkg/providers/amifamily/bootstrap/bottlerocketsettings.go but is supported in https://github.com/bottlerocket-os/bottlerocket/blob/d427c40931cba6e6bedc5b75e9c084a6e1818db9/sources/models/src/lib.rs#L260, a user has to raise a PR to add that additional key into the interface so that Karpenter will parse it and won't silently drop it from the userData. We should either: 1) Auto-gen this schema from upstream so that we don't have to constantly perform manual updates to this file OR 2) Not add the schema into our codebase and just don't validate the schema that users pass through their userData. If we want to override values, we can do so by grabbing the keys out of the TOML, but the object itself would be treated as `map[string]interface{}
How important is this feature to you?
This prevents us from having to perform manual updates and should reduce the number of user issues and PRs we get from settings not being supported.