- Anne L. Highsmith
- Brandon Tharp
- Chris Creswell
- Christopher Manly
- Craig Boman
- Craig McNally
- Dale Arntson
Michael Winkler ( - 9:30 EST)
- Finish Wayne's single-server FOLIO setup demonstration
- Q&A w/ Wayne
Determine note taker : Chris Creswell
Review action items
|15||Demo for a single-server installation, part 3||Wayne|
|5||Question from German FOLIO Project||Ingolf|
Why is one supposed to do the installation by hand (cf. FOLIO deployment: single server), there are Vagrant files ?
Isn't it reasonable to do the installation for a production environment with Vagrant files ?
|30||Discussion of experiences in putting up local FOLIO instances||Group||Observations and Questions by TAMU|
|5||Topics for the next meeting||Ingolf|
|Topics for future meetings :|
|SIG liaison to other SIGs||Ingolf|
In the absence of a Product Owner, will we establish a SIG liaison to the other SIGs ?
This should be a person who takes the interests and needs of the SysOps SIG to other SIGs. The responsibility of this person should be designated by the Product Council - and declared by the PC to the other SIGs (SIG-Conveners, POs). The SIG liasion to other SIGs will communicate with Conveners and Product Owners of the other SIGs and occasionally take part in other SIGs' meetings.
In order to support our SIG liasion to the developers, Wayne, shall we enforce using the JIRA to bring our issues to the developers ? Ingolf could reach out to Cate to find out in how far we as a SIG can use the JIRA (create and watch tickets; who assigns the tickets ?).
Recommendation from German FOLIO Project :
The SysOps SIG liaison to the other SIGs should be a personality with highly communicative skills, who is technically well-versed. Chris Manly could well fill this position.
The use of JIRA is considered not a sufficient means for this kind of communication.
Martina Tumulla talked to Nassib Nassar about this in Madrid. Result:
Send specifications to Cate, Jakub, Nassib
Review of action items
9:05 -- Part 3 of Wayne's demo
Creating a FOLIO superuser -- we do this by running some SQL to insert the superuser with known UUID into the users, login, and permissions modules.
Should probably be part of tenant initialization for these 3 modules to create these records with known username and password.
The username and password are diku_admin and admin if we use the sample SQL file
Then we need to add the permissions for each module to this superuser. Wayne has written a perl script to harvest all the module IDs and permissions, then add them all. Once you have the superuser setup, this can be done through the UI for other users.
Dale points out that as new permissions are introduced, they'll have to be added to the upseruser. Wayne mentioned there is an "all permissions" set for the users module that lists out all the permissions associated with that module. This is a convention that could be used with other modules, though it is not currently required. The script doesn't do it this way, but could be modified to do so.
Discussion of front-end vs back-end permissions. Front end permissions only control what you can see in the UI. You may have back-end permissions greater than what you can see in the UI, and vice versa. More information here:
Loading module reference data -- this consists of only what is required for you to be able to create records, like instance and material types. This data is needed before you can create instances and items because they're required fields. A user must have a group, etc. There is not a UI for doing this for all modules yet. There is one for the users module. Wayne wrote a perl script to load reference data, organized by API endpoint where you POST it to. This will eventually also be part of tenant module initialization so that you'll have this stuff by default. There will be a UI for it.
Loading sample data is separate. There is some documentation for loading inventory sample data. Loading sample users is more complex becuase you need to know UUIDs for types, and those are set when you load the reference data.
Demo ended. folio-ansible project, roles/mod-users-data/files/gen-folio-users will create random users. The script asks for group and address types on the command line and generates json files you can post to the users creation API endpoint.
Stephen had some questions from TAMU, listed here:
Question 1 is an action item looking for documentation on how to run the images as containers -- what flags and environment variables are needed. The developers will have to document this. How do we get these issues to the developer?
We don't have a product owner. We need a liaison to other SIGs, recognized and empowered by the product council so we can actually get these issues prioritized with the developers. The product council has to be involved in deciding how this will work, from a governance perspective.
If we could be given the ability to create and prioritize JIRA issues, that could work. We can't have our ability to bring up issues mediated by other SIGs. Wayne would go directly to index data staff who are his colleagues, but he can't tell them what to do necessarily. We need something more formal, something addressed through project governance. For now, Wayne will talk with Jakob about Docker image documentation issue.
Dale points out that we uniquely need quick turnaround on our issues. When we run into an issue that we'd bring to developers, it's because we're stuck. We can't wait weeks for a governing body to meet and get back to us.
Ingolf asks that everyone who has made their own installation document it in the "Development Environments in SIG members' insitutes" section on the wiki. Post results and questions there. Use the SysOps SIG slack channel to ask questions. Keep in mind that the channel is public.
Next week we will discuss the rest of TAMU's questions, as well as questions from other institutions related to installation process. This will likely generate more action items that we'll have to figure out how to get them prioritized and dealt with.