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

Tue Mar 11 02:46:11 UTC 2014

On 03/10/2014 06:35 PM, Colin Walters wrote:
> On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake <sdake at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20140310/e130e6ea/attachment-0001.html>