heat-operator

The Heat Operator deploys the OpenStack Heat project in a OpenShift cluster.

Description

This project should be used to deploy the OpenStack Heat project. It expects that there is an existing Database and Keystone service available to connect to.

Getting Started

This operator is deployed via Operator Lifecycle Manager as part of the OpenStack Operator bundle: https://github.com/openstack-k8s-operators/openstack-operator

To configure Heat specifically, we expose options to add custom configuration and the number of replicas for both Heat API and Heat Engine:

The following is taken from the Sample config in this repo:

spec:
  customServiceConfig: ""
  databaseInstance: openstack
  databaseUser: "heat"
  heatAPI:
    containerImage: "quay.io/podified-antelope-centos9/openstack-heat-api:current-podified"
    customServiceConfig: ""
    replicas: 1
    resources: {}
  heatCfnAPI:
    containerImage: "quay.io/podified-antelope-centos9/openstack-heat-api-cfn:current-podified"
    customServiceConfig: ""
    replicas: 1
    resources: {}
  heatEngine:
    containerImage: "quay.io/podified-antelope-centos9/openstack-heat-engine:current-podified"
    customServiceConfig: ""
    replicas: 1
    resources: {}
  memcachedInstance: memcached
  preserveJobs: false
  rabbitMqClusterName: rabbitmq
  secret: osp-secret
  serviceUser: "heat"

If we want to make some changes to the Heat configuration, for example num_engine_workers. We would modify the resource to look like this:

spec:
  customServiceConfig: |
    [DEFAULT]
    num_engine_workers=4
  databaseInstance: openstack
  databaseUser: heat

In this example, we are setting num_engine_workers to 4. After this resource has been updated, the controller will regenerate the Secret to include the updated values in the 01-custom.conf file.

❯ oc get secret heat-config-data -o jsonpath={.data} | jq '."01-custom.conf"' | sed 's/\\n/\n/g'
"[DEFAULT]
num_engine_workers=4
"

We can see this change reflected in the /etc/heat/heat.conf.d/01-custom.conf file within each of the API and Engine pods:

❯ oc get po -l service=heat
NAME                           READY   STATUS    RESTARTS   AGE
heat-api-5bd49b9c6d-6cprh      1/1     Running   0          2m51s
heat-engine-5565547478-v2n4j   1/1     Running   0          2m51s

❯ oc exec -it heat-engine-5565547478-v2n4j -c heat-engine -- cat /etc/heat/heat.conf.d/01-custom.conf
[DEFAULT]
num_engine_workers=4

Running on the cluster

To enable the Heat service, we simply need to set the Heat service to enabled in the OpenStackControlPlane. The following snippet is taken from the OpenStackControlPlane Custom Resource:

❯ oc get openstackcontrolplane openstack -o yaml | yq .spec.heat
enabled: true #<-- This needs to be set to true for Heat to be deployed
template:
  customServiceConfig: ''
  databaseInstance: openstack
  databaseUser: heat
  heatAPI:
    replicas: 1
    resources: {}
  heatCfnAPI:
    replicas: 0
    resources: {}
  heatEngine:
    replicas: 1
    resources: {}
  memcachedInstance: memcached
  passwordSelectors:
    authEncryptionKey: HeatAuthEncryptionKey
    service: HeatPassword
  preserveJobs: false
  rabbitMqClusterName: rabbitmq
  secret: osp-secret
  serviceUser: heat

As we can see, the Heat definition remains consistent within the OpenStackControlPlane resource, so the same logic applies here when we want to customize the service. Once again, configuring num_engine_workers in this example, it would like look this:

heat:
  enabled: true
  template:
    customServiceConfig: |
      [DEFAULT]
      num_engine_workers=4
    databaseInstance: openstack
    databaseUser: "heat"
    memcachedInstance: memcached
    rabbitMqClusterName: rabbitmq

The osp-secret contains the base64 encoded password strings:

❯ oc get secret osp-secret -o jsonpath={.data.HeatPassword}
MTIzNDU2Nzg=

❯ oc get secret osp-secret -o jsonpath={.data.HeatPassword} | base64 -d
12345678

These are user defined, and should be present prior to the deployment of the Heat service.

Undeploy controller

To undeploy the operator, simply set the enabled value to false from within the OpenStackControlPlane resource.

Contributing

The following guide relies on a already deployed OpenStackControlPlane. If you don't already have this, you can follow the guides located on the following repo: https://github.com/openstack-k8s-operators/install_yamls

To contribute, you can disabled the Heat service in the OpenStackControlPlane resouce and run the Operator locally from your laptop using make install run. This will start the operator locally, and debugging can be done without building and pushing a new container.

Once you have tested your feature, you can use pre-commit run --all-files to ensure the change passes preliminary testing.

Ensure you have created an issue against the project and send a PR linking to the relevant issue. You can reach out to the maintainers from the included OWNERS file for change reviews.

How it works

This project aims to follow the Kubernetes Operator pattern

It uses Controllers which provides a reconcile function responsible for synchronizing resources untile the desired state is reached on the cluster

Modifying the API definitions

If you are editing the API definitions, generate the manifests such as CRs or CRDs using:

make manifests

NOTE: Run make --help for more information on all potential make targets

More information can be found via the Kubebuilder Documentation

License

Copyright 2022.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.