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

Steve Baker sbaker at redhat.com
Sun Mar 16 20:30:47 UTC 2014


On 12/03/14 02:57, Steven Dake wrote:
> On 03/11/2014 05:09 AM, Matthew Miller wrote:
>> On Mon, Mar 10, 2014 at 07:46:11PM -0700, Steven Dake wrote:
>>> 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
>> I think some key context may have been lost here, causing some degree of
>> general panic. The *primary* Fedora Cloud image will be, and I think
>> always
>> will be, flexible and general purpose.
>
> Thanks, I thought the proposal was to do this for the general cloud
> image.
>
>> We're additionally going to make several more tailored images for
>> specific
>> purposes, and I was proposing both rpm-ostree and
>> min-metadata-service for
>> one of those, an image made specifically for Docker. From there, I
>> wanted to
>> at least consider whether min-metadata-service should be the standard
>> and
>> cloud-init an expanded case.
>>
>> The problem with cloud-init isn't just bloat (although there is a lot of
>> that). The problem is that we haven't really done the work to make it
>> really
>> integrate nicely with Fedora. (With no disrespect to Garrett -- it
>> was a lot
>> of hard work to get it running to the largely-functional degree that
>> it is
>> at now.) So in thinking about it, I wondered if it might be better
>> overall
>> to build min-metadata-service up to the level of functionality we need
>> rather than to try and reforge cloud-init. It may very well be that
>> Heat is
>> a showstopper in that line of thinking. But in that case, I'd
>> _really_ like
>> to see an effort around really making cloud-init _ours_.
>>
>>
> After speaking with Steve Baker last night, we discussed transitioning
> off cloud-init as a possibility.  What we are considering
> transitioning to is the os-*-* python tools.  The general idea is
> these tools would replace cloud-init long term for the Heat use case. 
> We can't make such changes until Juno wraps up (November).
At this stage I would say that cloud-init is very much a soft
dependency. For the new software-config features I think we can make it
unnecessary during Juno.

We've just made it possible to specify cloud-config (and other
cloud-init scripts) in the heat templates themselves. I'm going to
assume we can continue to encourage users to author templates to use
these if it meets their needs, since they can always customize an image
to include cloud-init.  However if they're customizing images then they
already have more appropriate config options than cloud-init anyway.


More information about the cloud mailing list