[FOLIO-1110] Mod-diku-admin, and other test data loaders Created: 07/Mar/18 Updated: 29/Mar/19 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Heikki Levanto | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | durham | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 1 hour | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Sprint: | |||||||||
| Development Team: | Core: Platform | ||||||||
| Description |
|
Based on
|
| Comments |
| Comment by Heikki Levanto [ 07/Mar/18 ] |
|
At the moment, most developers have their own scripts to set up some modules they need in their work, set up users and permissions, and load test data. All these have been written with the favorite tools of each developers, and documented more or less well. This means that it is always a struggle to get to work with some other part of the system. My proposal is to drop the shell/perl/python/whatever scripts, and to standardize on a system based on Okapi modules. These modules would do most (all?) of their work during the tenant init call, and offer no real services at all. They still need to be deployed, so that tenant interface can be called at the time the module is enabled for a given tenant. Perhaps a good example of this kind of module would be the "diku_admin" module, that would create a user called "diku_admin" and the corresponding permission user, set a well-known password for the user, give him all the permissions we know he is going to need, etc. The module could also enable the auth-token module for the tenant, effectively securing the tenant. Other good examples would be a module loads inventory-storage with reference data, and one that sets up a nearly complete back end for the front end developers to work with. This one would probably depend on the other two modules to set up the basics. |
| Comment by Heikki Levanto [ 07/Mar/18 ] |
|
As it is now, it is still necessary to load ModuleDescriptors into Okapi and to deploy the necessary modules. Actually, we already have a repository for back-end modules that gets updated every time a module gets released. Okapi can pull the complete list from that repository. But we still need to deploy the modules manually, because our ModuleDescriptors do not contain LaunchDescriptors. But the machinery is already in place, the install code will attempt to deploy any module required by dependencies. There is one more tool that will make things easier: The command line interface that would allow us to install and deploy a small list of modules in one go. Ideally that would be enough to set up a complete environment. |
| Comment by Heikki Levanto [ 07/Mar/18 ] |
|
I suggest making some simple module as a proof of concept. The diku_admin module would be a likely candidate. It may be a little bit trickier than many of the others, because it can not depend on the install function to enable the auth modules in the exactly right order, that will have to be done in code. The rest of the test-data modules will be simpler. They can probably be written in a way that is easy to clone when new modules are needed. Quite likely we will not need any code changes, only editing some predefined data files. And changing the module name in various places. |
| Comment by Heikki Levanto [ 07/Mar/18 ] |
|
One more comment about the diku_admin module. It would create a well-known admin user, with a well-known password, but for the tenant that it is being installed on. So we could use the same module for setting up the basics for different tenants. It should even be possible to install that module for the supertenant, securing the installation. But once the system has been secured, enabling modules will require permissions. The diku_admin user may be given such permissions, but I guess we would not like the admin of one tenant to be able to disable the operations of another, at least in a production environment. That may be fine for a development setup. |
| Comment by Heikki Levanto [ 20/Mar/18 ] |
|
Just a thought I want to write down before I forget: Whole modules are a bit heavy to dance around with, with definitions in Jira, Github, etc. It may be better to make one or two data-loading modules that are controlled by some external things, probably environment variables. Thus, the same module could be used for loading basic reference data, and for loading test data in small or large quantities, depending on an environment variable. |
| Comment by Heikki Levanto [ 08/May/18 ] |
|
We concluded in Durham that we certainly need a mod-superuser, and probably a mod-inventory-storage-ref-data. Some of these data loaders should logically live with the related modules, so they can be kept up to date. Perhaps it would be possible to keep them in the same github repo and use the same Jira labels. We will need a second ModuleDescriptor, and of course a place for the code. Can we make Maven to create a new jar for some subset of the source tree? (Like I said in Durham, I would be happy to write a mod-superuser, or something like that. I might need a bit of help with the maven trickery) |