# Thoughts on shared-remote-configurations ## Goals * ability to affect the attributes of a list of Remotes, all at once * ability for the list to be heterogenous Detail objects * ability for a given Remote to be managed by more than one shared-config? * what happens When Configs Collide? ## Problems with Remotes "knowing about" a shared-config * Can only be managed by one config * the Remote becomes responsible for the heuristics of "use the value from the shared-cfg, or the value from 'me', or my default" * heuristics would have to be part of **every** attribute * would require work from every plugin * Serializing a Remote becomes Exciting * user would have to know whether they wanted the "merged" Remote, or "the values that are actually stored" In general, the knowledge of shared-configs leaks into Remote in unsavory ways. ## Proposal We should have * a **persisted** entity, that * knows how to apply an **arbitrary** list of shared attributes, * to a **heterogenous** list of "managed" DetailRemotes. This entity will encapsulate all business-logic around how (and when?) to apply a given attribute, to a given Remote. This lets us have the messy heuristics in one place, rather than have it affecting every attribute of every DetailRemote. Remote entities will therefore be **unchanged**. Remotes know nothing about being managed - when they are invoked, say at sync-time, they just do the job they currently do, with whatever they've been set to. When you look at a Remote, it shows you the values it's been set with. When you ask a Remote which values are required and which are optional, it tells you. ## Some Details * new Model, `SharedConfigManager` (`SharedRemoteConfigManager`? `SharedRemoteManager`? open to different naming) * Attributes: * *name*: str * *managedremotes*: [Remote,...] * *managedattributes*: {key:value,...}? str(JSON) ? * Actions * create * list * delete * has **no** impact on managed-remotes - they're just no longer Managed * reapply-attributes * applies managed_attributes to all remotes in managed_remotes * dispatches on task, that locks all affected remotes and processes as one unit0of-work * add-managed-remote * should this immediately reapply-attributes to the incoming Remote? * if yes - task-dispatch? or serial? * remove-managed-remote * removes the Remote from the list-being-managed - has **no** impact on the Remote itself * update-managed-attributes * **PROPOSAL**: update the entire set at once * (e.g., workflow to update just 'url' would be "get managed_attributes entity, update url, call update-managed-attributes with new entity") * should this immediately reapply-attributes to the list of Remotes? Or should that be a second step? * if "immediately reapply", dispatches task ## Hard Parts * How do we handle heterogeneous DetailRemotes, which can have their own attributes (and even their own semantics around base-remote-attributes)? * Are there any unexpected RBAC interactions between "who owns the SharedManager" and "who owns the list of Remotes"? * How do we deal with a given Remote being managed by more than one of these at the same time? * do we need some operation that says "apply-attributes from this set of SharedManagers **in the specified manager-order**"? * do we need to have some kind of validation-action that analyzes all SharedManagers, finds the ones managing overlapping Remotes, and reports on overlaps in managed-attributes? * **PROPOSAL**: at least to start with - document "managing a given attribute of a remote via multiple managers will have unpredictable consequences"