Apps and pods both support environment variable definitions. Environment variable names, for pods, are more strict w/ respect to allowed characters. Apps, traditionally, are the exact opposite (minus the current regression on master) and have allowed users to define environment variables with names that incorporate hyphens, spaces, and other nonstandard/surprising characters. This creates some problems:
- the apps and pods APIs are inconsistent w/ respect to allowed environment variable names. this is surprising for API consumers
- we'd like more strict names for app envvar names. we know there are users in production defining envvars with names using non-standard characters, so we can't just "flip on" strict naming without breakage
- we still don't have a formal API deprecation policy; setting user's expectations w/ respect to API changes remains a challenge
Discussed with Jason Gilanfarr a bit. Came up with this proposal:
v1.5: introduce a gating feature `migrate_app_envvars` and make it opt-in
v1.6: make the feature opt-out
v1.7: no longer possible to opt-out; Marathon ignores the feature_flag
What does the feature do? Presumably it would migrate an environment variable like "framework-id" to "framework_id" (substituting the hypen for a dash). Other substitutions (e.g. trimming whitespace) could also be considered. A new variable could either be injected along-side or else replace it's "parent" variable – open to additional thoughts here.
Spanning the deprecating cycle across more than one release should (hopefully) give plenty of time for Marathon users to migrate their apps accordingly.