Heat and requirements for all-it-does-is-docker cloud image

Steven Dake sdake at redhat.com
Thu Mar 13 17:28:02 UTC 2014


On 03/13/2014 08:41 AM, Matthew Miller wrote:
> This is a three part question. No, wait, one clarifying statement and
> two questions. Okay, one clarifying statement, one main question with
> many sub-questions, and then a bonus question. :)
>
> -----------------------------------------------------------------------
>
> First, again, the primary Fedora Cloud image is going to continue to
> contain heat-cfntools, and python, and we won't migrate away from
> cloud-init without a replacement which covers what heat needs. So, this
> is just about a specialized image tailored for docker.
Matt,

Yes I apologize for causing such a fuss; I thought the intent was to get 
rid of cloudinit entirely, which as you can guess I don't support. :)

> -----------------------------------------------------------------------
>
> So, the main question: given that Docker upstream is recommending Heat
> as the best way to do Docker in OpenStack, what are the minimal
> requirements on the image for doing that?
>
> Is there a way to preconfigure the image so that heat-cfntools aren't
> required? In that case, do we need #cloud-config formatted userdata or
> can we get away with the #! shell-script style? If it is #cloud-config,
> is a _subset_ of that syntax sufficient (as for example CoreOS does)?

With the docker plugin, no heat-cfntools or other python dependencies 
are required.  One way to think about how the docker plugin works is as 
a management tool for building composite applications out of separate 
containers.  Heat is the management tool, the docker plugin in the 
linkage.  It uses the built-in docker container and image python library.

> If we choose to go with rpm-ostree for the image itself, will Heat be
> foiled by a surprise lack of ability to install packages? (Not just no
> yum, but actually read-only /usr?) I know that CloudFormation can do
> all sorts of things, but which will it need to do in this case? And is
> there a way to present these limitations to users in a way that won't
> be confusing? (Including, I assume, pointing them to the
> general-purpose image if the Docker one isn't flexible enough.)

Not an issue for Heat docker-plugin based containers

I would like to point out that the docker driver is in the /contrib 
directory of the heat repository and is not generally supported by 
upstream.  The heat community doesn't have the same policy around 
functional test gating that Nova does for plugins.  Our policy is "if it 
passes the various tempest functional testing already enabled and the 
2000 Heat unit tests and two core reviewers approve of the change, it 
can go in".

Nova has an extra requirement that every plugin must have tempest 
functional testing.  As such, I expect the Nova upstream more likely to 
be willing to support all of their plugins.  The Heat upstream only 
supporting resources in heat/engine/resources (of which there are ~50 
resources.

The docker plugin is in the fedora repositories, but not installed by 
default in the packaging.  I'll have someone take a look at the plugin 
to see if it even makes sense to enable it by default, since I doubt any 
of the heat-core personally tested it.

> -----------------------------------------------------------------------
>
> And the bonus question: if in the F23 or F24 timeframe, we go full-on
> rpm-ostree for the primary image (while still keeping it basically
> general purpose), will the "pkglayer" concept (where groups of packages
> can be added on top) be sufficient? I assume that it is _required_, and
> the basic idea is that we would need to add support for it to
> cfn_helper.py -- and possibly to Amazon's CloudFormation stuff too.
> Would going this direction be _workable_ for Heat?
I don't know what pkglayer is so I can't answer your question.  We plan 
to move away from heat-cfntools over the long term, and focus on os-*-* 
tools.  We will likely need heat-cfntools in the distro for some time to 
come for compatibility reasons and to allow migrations from AWS 
environments.

Regards,
-steve

> -----------------------------------------------------------------------
>
> Thanks!
>



More information about the cloud mailing list