openstack-k8s-operators / heat-operator Goto Github PK

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>openstack-k8s-operators/renovate-config)

Issue
Need to implement logic for the Heat API service.

Description
We have three Controllers defined in this project. The underlying Heat Controller handles the DB sync / manage operations, and takes overrides for heat.conf. We need to implement the next Controller for the API service.

Ideally, this would be responsible for creating a deployment of the Heat API container. Additionally, it should allow for scaling of Heat API independent to Heat engine.

We can probably re-use some of the logic used for other API controllers. eg:
https://github.com/openstack-k8s-operators/ironic-operator/blob/master/controllers/ironicapi_controller.go#L106

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Update module github.com/onsi/gomega to v1.33.1

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update k8s.io/utils digest to fe8a2dd

Detected dependencies

Issue
Need to implement logic for the Heat Engine service.

Description
We have three Controllers defined in this project. The underlying Heat Controller handles the DB sync / manage operations, and takes overrides for heat.conf. We need to implement the next Controller for the Engine service.

Ideally, this would be responsible for creating a deployment of the Heat Engine container. Additionally, it should allow for scaling of Heat Engine independent to Heat engine.

Considerations
This needs some additional thought. Considering we currently scale Heat engine workers using the num_engine_workers config option:
https://docs.openstack.org/heat/zed/configuration/sample_config.html

# Number of heat-engine processes to fork and run. Will default to either to 4
# or number of CPUs on the host, whichever is greater. (integer value)
#num_engine_workers = <None>

However, this would scale threads within the initial heat-engine container. The question and design consideration here is:

1. Do we just want to stick with this method?

2. Do we want to scale the number of pods and expose an option via the Heat CRD?

3. Do we want a combination of both?

4. This option isn't overly k8s friendly, given that we're launching new threads within a container, it doesn't give additional visibility via the kube API. But, it does maintain the current design expectation implemented by Heat and may be less complicated.

5. This option would provide the users with visible feedback via the kube API, as we would be scaling a ReplicaSet and the additional pods could be seen. However, this would inevitebly result in higher resource consumption as we need to run entire containers to do this. It would also possibly create confusion for users if the num_engine_workers was set to 24 within heat.conf. We would have $n replicas with 24 heat-engine processes in each.

6. Do we set a low default for num_engine_workers in heat.conf and primarily lean on scaling within k8s?

We can probably re-use some of the logic used for other controllers. eg:
https://github.com/openstack-k8s-operators/ironic-operator/blob/master/controllers/ironicconductor_controller.go#L94