Bugzilla – Full Text Bug Listing
| Summary: | [Admin] Client API and UI for managing repositories in a server | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Christian Damus <give.a.damus> |
| Component: | cdo.core | Assignee: | Christian Damus <give.a.damus> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | stepper |
| Version: | 4.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
| Bug Depends on: | 420644 | ||
| Bug Blocks: | 415375 | ||
I'll work on this. Hi, Eike,
I have pushed a new branch bugs/418454 to origin with a proposed implementation of creation and deletion of repositories. For a demonstration of the new functionality, I recommend first watching a screencast:
https://www.youtube.com/watch?v=hdoo7exGLWI
Note that this branch includes fixes for blocking bugs that I raised separately and for which I pushed Gerrit reviews:
* bug 420528 - Gerrit https://git.eclipse.org/r/17835
* bug 420644 - Gerrit https://git.eclipse.org/r/17847
There are two commits, one for back-end and protocol changes, one for the client UI.
Commit 721bc4c:
Introduces a new RepositoryConfigurationManager on the server side that a DefaultCDOAdminHandler uses to manage repositories. The RepositoryConfigurationManager is responsible for
* querying what repositories are configured on the server
* creating new repositories
* deleting repositories
The default implementation of the RepositoryConfigurationManager is instantiated by a new IAppExtension that looks for an <adminRepository> element in one of the repositories configured in the server's XML configuration file. This new XML element designates that repository as the "administration repository" for the CDO server (it would be a best practice to dedicate a repository to this function solely). The DefaultRepositoryConfigurationManager uses this administration repository to:
* store a catalog of which repositories exist on the server
* authorize creation and deletion of repositories by authenticating the Administrator user
The second point above requires that the admin repo have a SecurityManager and effectively establishes server-wide administrator credentials. The repository catalog contains XML repository configurations in CLOBs, which allows the RepositoryConfigurator, app extensions, store factories, and whatever else to read the configuration data as from cdo-server.xml. This requires a new stream-based (not file-based) API in the RepositoryConfigurator and a new IAppExtension2 interface to parse the XML in these CLOBs.
The IAppExtension2 is practical in that app extensions can choose whether to parse only the cdo-server.xml or also the dynamic repository configurations. For example, the Net4jExtension doesn't implement this optional interface because we only configure acceptors in cdo-server.xml, not in dynamic repositories. The SecurityExtension does implement IAppExtension2 because we support configuring SecurityManagers in dynamically-created repositories.
Another benefit of requiring the SecurityManager in the admin repository is that the DefaultRepositoryConfigurationManager uses its RealmOperation API to initialize and maintain the repository catalog, piggy-backing on the SecurityManager's privileged session. Otherwise, some severe changes would be needed in the security infrastructure to allow the DefaultRepositoryConfigurationManager to get a separate privileged session as CDO_SYSTEM.
Create/delete repository signals from the client require authentication of the administrator's credentials. To that end, I pulled up the basic implementation of this signal into the Net4j layer from CDO and re-used it in a new authentication signal in the CDOAdmin protocol. Similarly, the authentication/credentials-related API from the ISessionProtocol is factored out into a new IAuthenticationProtocol which the CDOAdminServerProtocol implements.
Commit 886d5a7:
This implements the new create/delete repository actions in the CDO Administration view. Deletion of a repository is straight-forward: an "are you sure" dialog followed by authentication of the request.
The creation of a repository involves a two-step wizard, for general repository configuration options and store-specific options. Currently only the H2 store is supported and its configuration is implemented within the cdo.ui.admin plug-in. I have tried to make it easy to factor that out into UI plug-ins for each store implementation to contribute their own UI panels to the wizard on a new extension point; that is a future enhancement. Currently, the repository store configuration is generated as XML in the wizard from a template and sent as text to the server. This isn't ideal, but it avoids the problem of having to add API for store providers to either read their configuration from some non-XML format (e.g., name-value properties) or two write the XML on the server side.
Finally, I gave some thought to adding an optional extension interface for IStore to support deletion of the actual store (dropping a database or whatever) and decided, for now, against that. Deleting possibly large amounts of data is a very serious decision and not something that I think it makes sense to provide from the client UI. Database administrators should be relied on to make appropriate back-ups and clean up databases on the server as required.
So, as usual, any and all feed-back on that issue, this design, and the code will be most welcome!
I have pushed a new branch bugs/418454a containing the same work described in comment #2, plus: * rebased on latest master, including fix for bug 420644 and the security form editor bug 418452 * rebased on latest patch set bug 420528 (which is still pending in Gerrit review) I'm thinking now that the original intent to add the "Manage Security" action from bug 418452 on a repository in the CDO Administration view is problematic, because opening the editor requires a session that is logged in as an administrator. I suppose we could look for an existing session and open a new one if we can't find one, but it needs to be logged in as the adminstrator, so it would be rather awkward. OK, so I've abandoned the bug branches and instead squashed my commits and pushed a new Gerrit review:
https://git.eclipse.org/r/18049
It's a big 'un! Let's see how reviewing such a large change works in Gerrit. :-)
The principal functionality of this enhancement has been merged to master. commit f61eb9d90cf4076baab01072c005e9cbf0fecdce Hi, Eike, I have created a new Gerrit change for the last detail of this enhancement: https://git.eclipse.org/r/18156 It implements a server signal-back (TM) to confirm deletion of a repository if it has any users currently connected. This checks whether the repository has any server-sessions on transport channels that are not JVM channels (on the assumption that local sessions within the JVM implement system services and do not count). I found a reasonably straight-forward way to add the "Manage Security" action that opens the new security form editor to context menu of repositories in the CDO Administration view. So, I have pushed a new patch set to the Gerrit change referenced in comment #6. Thanks again for the reviews, Eike! That wraps up a nice milestone. Fixed in git master, with latest changes described in comment #6 and comment #7. commit 452e6c6a3919d55c3074eb02aba46ec24081c487 Closing. Closing. |
Currently, the CDOAdmin API defines a protocol for clients to request servers to create and delete repositories. However, this is largely unimplemented in the server side and there is no UI to access these functions. This enhancement will add actions to the CDO Administration view to: * create a repository (on a server node) * delete a repository (on a repository node) * administer security permissions (on a repository node; opens the editor specified by bug 418452) For creation of a new repository, the same configuration parameters as would be specified in the server XML are required and potentially vary by store back-end. Deletion of a repository should at the very least be restricted to administrators of that repository and be denied or at least warn strongly if any clients currently have transactions open. Restriction of access to the creation function would require some kind of server-level security model; does such a facility exist? These actions will require implementation of the server-side handlers of the CDOAdmin requests. The initial implementation will support the embedded H2 database store only, where a handler needs to be store-specific. Start/stop repository actions are not in the scope of this enhancement.