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!
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
