2019-05-29 Kubernetes Subgroup Meeting notes

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
5minKubernetes subgroup of SysOps SIG

Meeting notes

We have been chartered as a subgroup of the SysOps SIG. Initial draft charter on landing page Kubernetes Subgroup. Please give any feedback in Slack channel #kubernetes. We agreed to keep meeting Wednesdays at 9:00 U.S. Eastern Time. We will move to Zoom as a meeting platform to enable meeting recording and archiving. We will attempt to hold meetings to 30 minutes. Wayne Schneider volunteered to serve as convener and note taker. There is no need for a mailing list at this time, we will continue to use the Slack channel for communication.

10minUpdate on AWS FOLIO setup

Meeting notes

Taras Spashchenko has set up a Kubernetes cluster using EKS in the FOLIO project AWS account, managed by Rancher. The Okapi URL is http://ad2232214821b11e99fc006191d465ba-a91a08bd720aef8d.elb.us-west-2.amazonaws.com:9130/, UI at http://ae6938491822911e9b94b0af14eadae8-697895a425a7b2d9.elb.us-west-2.amazonaws.com:3000/. He mostly followed jroot's recipe as documented in the folio-install Github repo.

The recipe works well, and setup from start to finish takes about 2 hours. A few concerns:

  • Each node in the cluster is an m4.large, which can host only 20 pods. RAM is significantly underutilized.
  • EKS offers some conveniences, but the cost model may not scale. mark.stacy has had success controlling costs by building nodes on EC2 using spot instances instead of EKS.

We agreed to use the folio-install repo to maintain documentation on different deployment strategies. Taras will add his documentation into a branch on that repo. The Platform: Core/DevOps team will take on the task of organizing the repo and merging documentation branches into master. 

10min

Update on  FOLIO-1550 - Getting issue details... STATUS

Wayne Schneider Jakub Skoczen

Meeting notes

Wayne Schneider outlined the plans for CI-integrated continuous deployment for FOLIO development. The problems that we are trying to address are:

  • Quality control
    • Full stack features currently must be merged into the master branch of all related projects before they can be tested and accepted. This opens us up to the risk that changes in multiple projects need to be revised or rolled back if the feature is not accepted.
    • Integration testing currently requires that changes be merged to master
  • Development experience
    • It is currently challenging for teams to collaborate on full stack features that require iterative development on both the front- and backend. Backend changes must either be merged to master and deployed before frontend development can commence, or frontend developers must be able to compile, deploy, and manage the Okapi instance in a Vagrant box to use backend branch code

Our proposed development workflow:

  • Teams collaborate by creating a tenant on a hosted Kubernetes cluster
    • The tenant lifecycle is triggered by Github events: creation of a feature branch, a pull request, etc.
    • The tenant configuration is controlled by the construction of a Stripes platform with additional metadata to pull in specific backend module versions if required. Perhaps by creating a feature branch of platform-core/platform-complete?
    • On the specified event, CI will build a Stripes bundle for the tenant, deploy it to S3, and configure a compatible backend in the hosted Okapi instance.
  • The hosted cluster consists of an Okapi instance with Kubernetes nodes for deploying backend modules.
  • All commits to feature branches, master, and releases of backend modules launch a container with the running module, and register it with the Okapi discovery service. These versions can then be pulled in by the tenant

This workflow appears to be in the spirit of the /wiki/spaces/DQA/pages/2656765 whitepaper that Anton Emelianov (Deactivated) has been working on. Wayne and Anton will meet early next week to identify any gaps or missed requirements. Wayne and Jakub Skoczen will create Jira issues for the Platform: Core/DevOps team to begin migrating existing CI pipelines and workflows to a target Kubernetes cluster based on Taras Spashchenko's AWS deployment.

5minTopics for future discussion

Action items