Page tree
Skip to end of metadata
Go to start of metadata




  • Deployment concerns
  • Recommended toolchain

Discussion items


Issue about tenant admin bootstrapping

MODUSERBL-70 - Getting issue details... STATUS

Recommended Toolchain


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

  • Kubernetes and Docker
  • Rancher 2.0
  • Secret Management as a part of Rancher

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:

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