9:46 p.m.
On 03/10/2014 06:35 PM, Colin Walters wrote:
On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake <sdake(a)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
https://github.com/cgwalters/min-metadata-service/issues/2
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct