paul-rogers edited a comment on pull request #2251: URL: https://github.com/apache/drill/pull/2251#issuecomment-885888891
@vdiravka, thanks for the explanation. Let's be careful not to confuse existing implementation with new requirements. Yes, there is a comment that says that the system options are persistent and session options are not. Be careful to read this correctly. *At the time the comment was written*, system options were the only persistent options. System options, by definition, have to be persistent. The comment did not *forbid* session options from being persistent; it simply observes that, at that time, for the reasons we discussed, session options were not persistent. Nor does the comment say that, if you add persistent user-level options, that they have to be system options because only system options are persistent: you are free to add persistence to session options. I strongly recommend splitting this PR into two: one for options, another for plugins. Else, discussion becomes overly complex. *Before* we worry about code details, we have to get the semantics right. After writing the comment on plugins, below, I realize that we are probably using the same words for entirely different ideas. Your goal is to add multi-tenant support to Drill. You uses the term "user options". I now realize you probably mean "tenant options." If we are doing per-user options (which is how I first read your description), then the requirements are one thing. If we want per-tenant options, the requirements are different. Let's list both scenarios: per-user options and per-tenant options. Please let us know which you are trying to build (or if you are tying to build something else entirely.) ## Per-User Persistent Options Suppose the goal is to let users (individual named humans) persist options. We assume that system-wide settings are set as system options. We are simply avoiding the need for the user to configure their own personal options on each login. Users will want to persist only *some* of their session options. We discussed that this may not work as one might think: we have to think through the issues. The point was that concurrency of user options will be a mess if they work like system options: if changes to user/session options are written to persistent storage immediately. This will screw up queries as I persist "all-text-mode" in one session, which breaks a query in another. Point is, user options *must* have semantics different from system options. * We need a concurrency guarantee. One choice is "options are propagated to all active sessions with unknown latency, just like system options." Another, more dependable, is "session options are initialized on session startup, after which they do not reflect changes made in other sessions." Whatever it is, the definition has to be stable and explainable. * Some options apply to queries: we've been using "all-text-mode" as an example. Such options will be set frequently. Since these options are per-query, we cannot set the option across all user sessions immediately, as that will break queries. Instead, the user has to *tell us* when they want to persist that setting. Otherwise the setting is per-session (that is, per-query.) Is it a bad thing that the behavior of queries depends on session options? Certainly. That was a poor design choice. But, it is how Drill works, and we have to design new features to reflect this choice. ## Per-Tenant Options Now, if the goal is to have "per-tenant" options, we have a much different problem. Each *tenant* is an organization which believes it has its own Drill cluster. That the cluster is shared is invisible to the tenant. The tenant reads in the docs that they can change system options, so they decide to do so. Those changes must persist only for that one *tenant* and all that tenant's users. I now see that this is probably what you are trying to implement. As a result, the semantics are closer to system options. For now, let's assume that you do not, in fact, need per-user (per-named human) persistent options. Let's list some possible requirements: * A bootstrap option enables multi-tenant support. The option is off by default, meaning that existing Drill behavior is unchanged by default. * A tenant is an organization with (a single user? multiple users?) * Each tenant has a *tenant admin* user who may set its own (subset of) system options. This subset is called *tenant preferences*. Such options persist, like session options, but apply only to sessions started for that tenant. Values set by one tenant cannot be seen by any other tenant. * Both server options and tenant preferences are system options: changes take effect immediately (after some latency) in all active sessions. Both are changed with the `ALTER SESSION` and related commands. * A new class of user, "tenant admin", is given permission to change tenant preferences. The "tenant admin" cannot change server options. When a tenant admin issues an `ALTER SESSION` command, that command alters the tenant preferences. * The full set of system options include options outside of the tenant preferences set. These are called *server options* and may only be set by a *server admin* user who belongs to the organization that administers the physical Drill cluster. * In multi-tenant mode, the Drill "admin" user becomes the *server admin* who can modify server options. The server admin can also view and change tenant preferences.When the server admin issues an `ALTER SESSION` command, that command alters the server options. * When not run in multi-tenant mode, server options and tenant preferences are identical, they are just *system options*. In multi-tenant mode, the concepts are distinct: each tenant has their own persistent set of tenant preferences separate from server options. * Normal users can change neither server options nor tenant preferences; such user can only change session options using the `ALTER SESSION` command. * The server options, tenant preferences, and session options form a hierarchy, as in present Drill. The server admin can alter any option which "flows down" to all other levels. The tenant admin can alter tenant preference which "flow down" to sessions. Code wise, you will be adding a new system options layer. You should mark options as "server", "tenant" or "user" so the above requirements can be enforced. -- 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]
