For some back group on what's heat container agents here, We have heat agent hooks [1] which design to be used with os-collect-config to and os-apply-config, to keep watching metadata server and execute any received commands with heat agents. If you build with diskimage-builder, you will generate an image with heat agents and services installed inside. But this will force operators to use large images to run for any application deployments and also add limitations to the application environment (you need also able to install all services above). For that, heat container agents seem to be a better approach if we don't want the above limitations. The concept is simple, just put every service into a container, so whatever the OS operator pick, as long as it supports running containers, it should work. Once we have our container image built, we can deploy/config application after the container with heat agents started in Nova instance. [1] https://opendev.org/openstack/heat-agents On Fri, Mar 13, 2020 at 11:46 AM Rico Lin <rico.lin.guanyu@gmail.com> wrote:

Dear all

tl;dr: Shall we build, publish, and test heat container agents on heat-agents directly?:) Please help to review https://review.opendev.org/#/q/topic:build-container-agent+(status:open)

Current I think we encounter with following issues: ** No functional/scenario test for heat-agents but only unit tests* Right now, whatever patch people send up in heat-agents, we only vote against unit tests. This makes no sense for long term maintenance. Which makes me thinking of the second issue. ** No enable scenario tests for software deployment:* We have tests defined, but since we didn't build any customized image. We didn't enable it for a long time. To build a container image for heat-agents (aka heat container agent) is (IMO) the best way for us to enable these teats. Which we can also use it to cross gating on heat and heat-agents (or even heat-template). The no much to change for the test itself but only update the config script to enable the container. ** Can't guarantee cross-project usage:* We currently provide no guarantee for any usage of heat agents from other projects, especially Magnum and TripleO (I didn't personally check if TripleO still using it, but since they still have experiment CI running) who uses heat container agents. It will be nice if we provide basic images for other teams can build their additional requirements.

To resolve the above issues, I propose [1]. Which a lot of logic was copied from the current magnum heat container agent scripts [2] so we can start with a higher possibility to allow magnum to reuse our works.

For a more detail approach in [1]. The patch defines a build job in `check` pipeline. And a publish job in `post-check`. Uses zuul secrets to save docker authN information. As for the account, I created a new `openstackheat` account [3] for it (I specifically recall there ware discussion about having an official image hub for OpenStack, but not quite sure what happened since). The current approach also can support multiple architectures (like amd64 arm arm64 ppc64le s390x, etc). But for now, I think we should have tested before we publish for other architectures.

You can run the build or publish job easily by running `make build-images-all-archs` to build images for all architectures or `make upload-images-all-archs` to build and publish images for all architectures.

[1] https://review.opendev.org/#/q/topic:build-container-agent+(status:open) [2] https://opendev.org/openstack/magnum/src/branch/master/dockerfiles/heat-cont... [3] https://hub.docker.com/r/openstackheat -- May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin

-- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin