2019-03-29 - System Operations and Management SIG Agenda and Notes
Date
Attendees
- Greg Delisle
- Anton Emelianov (Deactivated)
- Debra Howell
- spampell
- Philip Robinson
- jroot
- Wayne Schneider
- Brandon Tharp
- Nico Toerl
Goals
- Deployment concerns
- Recommended toolchain
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 5 | Welcome | Ingolf |
|
| Issue about tenant admin bootstrapping | MODUSERBL-70 - Getting issue details... STATUS | ||
| Recommended Toolchain | All | Last week, we had a lively discussion (also after the meeting in Slack) whether we as a group should refer to a specfic toolset in our reference implementation(s). While some argued that we should be as agnostic (to specific tools) as possible, others argued that the support will not be considered part of the project if the project doesn't adopt a default or primary choice of toolkits. At the end of the chat, there seemed to be agreement that the SysOps SIG should come up with a "recommended" orchestration toolset. This will enable core developers to support orchestration deployment, and not only deployment for the purpose of development. So far it seems we have agreed upon
| |
| Deployment issues | Move dependency resolution away from Okapi and other issues - how do we get them into the development pipeline ? What needs to be done by the core team to resolve these issues ? | ||
Action items
Write up a discuss post to explain issue, gather use cases and requirements. Discuss post: https://discuss.folio.org/t/administrative-user-bootstrapping/2375
Meeting Notes
Tenant admin bootstraping
Discussing what we need to initialize tenant admin.
Existing Perl script.
Chicken and egg issue. Need a set of modules in place prior the securing.
TAMU sets whole system before securing tenant.
Do we want the tenant initialization to be outside the system?
How do we want to be able to setup a tenant? API from a mod?
There are 2 super users going on. One for Okapi and another in the scope of the tenant.
Stripes core requires the Okapi interface.
An API can have a UI on top of it.
Okapi module has a super tenant so we can see Okapi's web services. So it has the same setup as the modules.
How do we protect super tenant admin from being an observable/editable user in the system?
What needs to be addressed with multi-tenancy?
Currently we need to turn off mod-auth to create a new tenant which is a problem when adding a new tenant to an existing multi-tenant system.
Tenant initialization does not have a notion of a user right now.
Can there be special restrictions on Okapi interface to require a superuser before tenants are created?
Tenant superuser should only have access to it's own modules and Okapi for enabling more modules for itself.
Recommended toolchain
Not much difference to cloud vs. on-prem on Rancher
Difference between using Okapi to managing our environment vs using some other orchestration tool.
Okapi has tooling to interact with Docker daemon. Not specifically meant for production, but for setting up developers.
We aren't defining a set of tools that will be a requirement.
Is there a better way Okapi can support deployment with this toolchain?
Next week
Integrations and continuing this conversation about the toolchain
Other agenda items
June conference topics
- Wayne Schneider will do a write-up of the tenant initialization issues and post it on Discuss. (https://discuss.folio.org/t/administrative-user-bootstrapping/2375)