Open Stack

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 at 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-container-agent
> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200325/ddec46d6/attachment.html>