On 03/10/2014 06:35 PM, Colin Walters
wrote:
On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake
<sdake@redhat.com> wrote:
If these
are removed from a guest operating system, the guest won't be
able to function with TripleO, Heat, or anyone that depends on
cloud-init. Removing cloud-init support effectively kills any
motivation for AWS adoption of a guest operating system that
we may produce.
I would say that there are many valid ways to provision and
manage machines, of which Heat/CloudFormation is one.
min-metadata-service does exactly what it needs to do to
provide the fundamental basis for secure remote access to the
machine, and with
the guest will also be able to reach out and register on
bootup (perhaps by first pulling a docker container), which is
all one needs to implement higher order management tools.
Colin,
TL;DR don't remove cloud-init
I have had a look at the min-metadata-server repo.
I am not certain Heat could be made to work with only ssh and
userdata execution. Heat relies on something called part handlers
to join multiple blobs of data into one userdata blob that can then
be ran by cloud-init and our cloudinit part handler code. I suppose
it is possible to convert how we execute guest configuration by
translating all our code base into a userdata blob, but there are
other packages, specifcally os-collect-config, os-refresh-config,
and os-apply-config in play here.
Heat is a fundamental dependency of TripleO, so if Heat doesn't
work, TripleO doesn't work. TripleO also has a fundamental
dependency on the os-*-* packages, so even if Heat could be made to
operate with min-metadata-server, TripleO still requires these other
os-*-* agents to operate. It is unfortunate that agents are
implemented in Python, but in the OpenStack community, non-python
agents are essentially a non-starter because of maintenance reasons.
We have two broad user types for Heat. The first are the devops
folks who would use Heat as you mentioned, as one way to manage a
set of resources in a stack. These folks could use other tools if
heat were disabled by such a change.
However Heat has another often overlooked user type, which is other
incubated/integrated OpenStack projects. For these users, Heat
isn't just one way to manage deploying resources on OpenStack. It
is the *only* way available beyond re-implementing some or all of
Heat. A removal of cloud-init from these guest images would block
the Fedora cloud images from being used by the scope growth that
naturally occurs in the OpenStack community.
I really don't think replacing cloud-init with min-metadata-server
will work for the OpenStack use cases. It may work for a very
limited set of OpenStack use cases, but not the broad general set.
The cloud-init package is not ideal, but it is what it is, and I
don't foresee a dramatic shift in the way OpenStack views cloud-init
as a fundamental guest OS dependency.
And there implementation will stop =)
But I'd agree with you (and others have expressed this
sentiment) that we should be conservative with backing away from
cloud-init in the near future.
We are stuck with cloud-init if we want OpenStack to operate an
os-tree enabled guest.
At least for Fedora Cloud. That said, I am trying to create
momentum for a smaller but still useful core, ideally written in
lovingly hand crafted C code, with languages like Python and
Ruby still *available*.
I am a bit
confused at the scope because min-metadata-server was
mentioned early on, but is unnecessary if the target of this
OS is to only run on hosts.
Running as a guest is definitely in scope.
Can you explain how atomic runs in a guest launched by OpenStack
without the dependencies people have become dependent on?
I think what is needed is two things a) a general purpose guest
image b) a tidy host image. We don't want to threaten our
guest-image by making it non-general purpose. The host-image can be
customized by TripleO so the fact that it may not include a python
runtime, or even the os-*-* and cloud-init tools for the TripleO
case is solvable using the image customization tools provided by
TripleO.
For 3 fedora cycles I maintained separate Fedora images with
heat-cfntools. I really want to avoid doing so in the future. In
addition, for three years I saw people struggle daily to make a
guest bootstrapping tool, and the only one that survives today is
cloud-init. Lets please not relive that pain for the gain of
reducing dependency count.
Ideally a
python run time would still be available to run virtualization
platforms like OpenStack.
Sure, of course. No one is talking about making python
unavailable. Just possibly not installed by default in all
builds.
Such a
bare-bones operating system would make alot of sense, but I've
copied a TripleO upstream developer (James) for his thoughts
on atomic + ostree and its relationship to how TripleO handles
continuous deployment through imaging.
I'm certainly interested in the discussion! OSTree was made
from the very start to do continuous deployment - at the moment
with rpm-ostree I am restricting myself to merely accepting RPMs
as input, so no continuous integration. But gnome-continuous is
a custom build system that takes git repositories and writes to
the OSTree repository directly (with no intermediate package
step).
Mark and James may have thoughts here.
Regards,
-steve
_______________________________________________
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct