Communishift

Purpose

Investigate what is needed in order to run a community focused Openshift instance.

Identify possible bottlenecks, issues and whatever the CPE team needs to develop new components/services for this new Openshift instance.

Resources

Investigation

The team discussed the following topics:

Conclusions

  • The cluster can leverage EFS to provision volumes (using the AWS EFS operator from the Operator Marketplace) and an extra ansible playbook to automate part of the process;

  • Quotas can be enforced by creating an Openshift operator that watches all user namespaces;

  • Authentication groups can be automatically synched between FasJSON and Openshift with a new Operator.

Proposed Roadmap

AWS EFS Ansible Playbook

One needs to provide some AWS info when creating a volume using the EFS operator, sample resource bellow:

apiVersion: aws-efs.managed.openshift.io/v1alpha1
kind: SharedVolume
metadata:
  name: sv1
  namespace: default
spec:
  accessPointID: fsap-0123456789abcdef
  fileSystemID: fs-0123cdef

Both “accessPointID and fileSystemID” are generated by AWS with “accessPointID” being generated for every PVC that gets provisioned in the cluster.

An ansible playbook comes into play to automate the process of creating an “accessPoint” for a namespace whichs should be request in an infra ticket when requesting the creation of a new namespace in the cluster.

Fedora Cloud Quota Operator

An operator can be created to ensure a namespace’s resource quota.

The operator would watch for namespaces with specific tags/annotations (TBD) and apply the required quotas in those namespaces.

The quotas themselves are applied by creating a ResourceQuota object in the namespace is supposed to manage: https://docs.openshift.com/container-platform/4.6/applications/quotas/quotas-setting-per-project.html.

Fedora FasJSON Sync Operator

An operator can be used to ensure FasJSON groups are synched with the cluster groups used by Openshift roles.

This operator would retrieve a group(s) information every N seconds from FasJSON and apply the changes in the cluster, ensuring syncrhonization between the two systems.

Food for thought: it would be interesting if FasJSON notifies group changes to fedora-messaging.

Team and Skills

A team of three indivduals should be able to deliver the proposed roadmap in ~6 weeks (2 week sprint, a sprint per component) assuming the following technical skills:

  • Kubernetes basic concepts/usage; * API or previous operator knowledge is a plus;

  • Ansible basic usage; * AWS API knowledge is a plus.

It might be a good opportunity to learn about Kubernetes and Operator/Controller development.