Suppport deployment via operator lifecycle manager

[lulf]

Overview

It is desirable to deploy EnMasse via the Operator Lifecycle Manager (OLM), in order to be provisioned without requiring cluster-admin privileges in a default OpenShift install.

The operator lifecycle manager defines a ClusterServiceVersion resource that should contain with the required privileges, the deployments to create, and any custom resources that are provided by an operator.

Requirements

• Service admin should be able to install EnMasse using the Operator Lifecycle Manager
• Service admin should be able to upgrade EnMasse using the Operator Lifecycle Manager
• Service admin should be able to install EnMasse using existing installation methods: bundle and ansible playbook
• Service admin should be able to upgrade an existing EnMasse version to a version that supports OLM

Design

Some changes to EnMasse components are needed in order to fit into a CSV:

• ConfigMaps and templates used by address-space-controller must be embedded within the controller component
• Services and non-deployment resources must be created by the controller process itself.
• Authentication services must be deployed separately from the address-space-controller process.
• Templates must be defined in a way that allows creating a CSV
• Plans and infra configs must be deployed by the user after installing the operator instead of being provided by default.

Tasklist

• [x] Embed configmaps in address-space-controller
• [x] Create services for address-space-controller and api-server at startup
• [ ] Create CSV for installing to operator catalog
• [ ] Submit PR to https://github.com/operator-framework/community-operators for EnMasse operator.
• [x] Move plans and infra configs into templates as an example and update documentation

[k-wall]

What does this mean for the existing deployment procedures? Will they contain to be supported? How would a user who had deployed using say the templates, move to the operator?

[lulf]

@k-wall i think existing deployment procedures could be kept. The contents of the 'bundles' would change, and the ansible playbooks would also keep the same interface but 'do something different'.

Upgrade should continue to work as before.

[kornys]

done