Re: Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

[Steven Dake <sdake@xxxxxxxxxx>]

On 03/10/2014 06:35 PM, Colin Walters wrote:

On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake <sdake@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct