Tenant Configs

[Datron]

Goals

• Allow tenants to change the predefined behaviour of Superposition without environment variable changes
• Features can define tenant configs that tenants can enable/disable
• tenant configs can make available variables like a hostname, API key and envs to validation functions to enhance their capabilities
• Role management (AuthZ) can be done with tenant configs

Questions

• Should tenant config be staggered via an experiment or be a binary config change?
• Will all tenant configs be pre-defined by Superposition?
• How should we store tenant configs? Can cac_toml be used here?
• Will tenant configs need overrides? (Yes if staggering is needed)

Solutions

Tenant Config as a tenant in Superposition

Pros

• Tenant Config gets the full power of superposition
  • typed configs
  • validation functions for configs
  • dimensions
  • overrides
  • experimentation
  • snapshotting for rollbacks
  • audit logs
• Every tenant creates an override for configs they want to change

Cons

• More DB connections
• Tenant Config has to be resolved for APIs which want the config value
• In the API handler code, we inject a DB connection that is specific to that tenant - we now need to inject more than one connection so that the handler can access tenant configs. At any point, every request to a handler will hold more than 1 connection to the DB.
  • Solution: This can be mitigated by including the tenant config in the search path when connecting
• Since all tenant configs are grouped in one place, the role to change tenant configs will be held with a few people. The tenant has to request these select few users to make any change they want (maybe a good thing?)
• We cannot bring in cac_toml right now

Tenant Config as a table in postgres tenant schema

The tenant config key and value would be stored in the same schema as the current tenant. The table structure would be

Config Key	Description	Type	Config Value	created_at	created_by	last_modified_at	last_modified_by
The name of the config	A small description of what the config is used for	JSON schema typing of the config	The value of the config	time when this was created	Who was it created by	When was this last modified	who made the last change

Pros:

• Less DB connections made to postgres
• No need to inject another connection into the API handler
• The tenant user can manage their own configs
• Simpler resolution (its just a lookup)

Cons

• No audit trail with audit log
• Cannot rollback any changes
• No benefits of superposition
• Cannot stagger config releases

Conclusion

We should create a new tenant for tenant configs

[knutties]

@Datron - I think new tenant for tenant configs is the right thing as concluded. But for immediate usage without boiling the ocean around handling the problem in diesel - I'd like to see if we can use cac_toml to get a CAC version of the tenant config out and then once we solve the diesel issue we can make it a proper tenant.

[Datron]

@knutties the connection problem won't happen, we can just do this. We don't need to fix diesel-multiconnection-manager schema handling just yet, but we should

Solution: This can be mitigated by including the tenant config in the search path when connecting