paul-rogers commented on pull request #2251: URL: https://github.com/apache/drill/pull/2251#issuecomment-885898568
@vdiravka, on the plugins side, let's please do list our requirements and design goals. Else, I worry that the comments I make get lost, and I will this have to repeat them over and over. Requirements as I extract them from your description: * Provide a bootstrap option to enable the new semantics. The default is off, meaning that Drill behavior will not change by default. * Retain global plugin configurations. (They allow multiple users to share the same configuration without copy/paste.) * Add per-user plugin configurations. * Users can add and change only their own per-user configurations. (No user can "share" a config with another user: either the config must be copied to a global config by the admin, or the second user must make their own copy.) * If a user configuration happens to have the same name as a global configuration, the per-user configuration takes precedence. (If the admin make a global version of a now-shared config, the user must delete his own copy in order to use the now-shared version.) * No non-admin user can see or change the configuration for another user. (That is, if two people work in the same group, and want to share a config, they must do so via copy/paste, or by asking the admin to make the plugin global to all users.) * No non-admin user can change a global configuration. * The admin user can see, add, modify or delete *any* plugin configuration, both global and per-user. (Without this, the system is not maintainable as the admin won't be able to manage per-user configurations.) Now, one can disagree with these requirements. For example, in a multi-tenant environment, we do not one *tenant* to see the plugins for another *tenant*. But, we might want all users in "Tenant A" to see a shared set of configs. Your description appears to assume that "Tenant" = "User": one user per tenant. However, a typical model is for each human in a tenant to have their own user account. Please spell out the desired semantics. *Aside*: Clarifying the desired tenant model may help with the options discussion. I've been equating "user" with "person". If your tenant model equates "user" with "tenant", so you are tying to define per-tenant defaults, then please clearly say so in the design. If you want per-tenant default, I would suggest a somewhat different design for options. Finally, if the goal is a true multi-tenant model, in which tenants are distinct business entities (rather than different departments within a single entity), then we must also ensure each tenant has access to only their own query profiles. Will there be another PR for this? Is there a roll-up Jira ticket for all the issues involved in true multi-tenant operation? Also, the Drill UI assumes a single organization. If the UI is to be exposed to multi-tenant users (so they can monitor queries, see query profiles, etc.), then the UI must change. Tenants should not be able to see details, or change the state of, Drillbits. Session options should reflect tenant values. Probably other changes. Will there be a design or PR for this? Further, each tenant must have guarantees on resources. That is, Tenant A should not be able to run a huge query that denies resources sold to Tenant B. This is a **very hard** problem. If you don't solve the hard problem, the options and plugins are somewhat moot. The option and plugin features are handy, but do not, by themselves, give you multi-tenant support in Drill. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
