Description
BLUF: organization- & user-scoped parameter are underspecified, essentially unimplemented, and have unresolved issues in terms of encapsulation. We should drop them for now.
The initial Workspaces V2 RFC defined 4 parameter scopes:
- organization
- template (nee project)
- user
- workspace
However, it didn't give exact details on how resolution would work if a parameter were specified in multiple scopes.
Template- and workspace-scoped parameter values are currently implemented. However, organization- and user-scoped parameter values are unused in workspace creation at present, and no CLI or WEB UI affordances exist to set them. The only implementation is via the REST endpoint which could be used to create them.
Parameters are identified by name in the template, and so the template is the natural namespace for parameter names. Template-scoped parameters identified by name thus present no ambiguity, and neither do workspace-scoped parameters since each workspace has exactly one template.
However, organization-scoped parameters are a challenge if different templates use the same name for different things. Introducing a new organization-scoped parameter could easily break existing templates if a naming collision occurs. Ditto for user-scoped parameters. These problems are akin to global variables in software. If local names can be interpreted in some other scope without warning, encapsulation is difficult.
These problems are not insurmountable (the software analogy gives some immediate possible paths), but without a detailed customer/user/business need it's hard to pick the right path. Removing the problematic scopes does not constrain us appreciably in re-introducing them later when the matter has been given more analysis and/or it is driven by a concrete customer request.