Alternatives to cloud-init (was Re: [DISCUSS] Cloud and Server Workgroup relationship)

Josh Boyer jwboyer at
Thu Oct 29 13:30:29 UTC 2015

On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier <jzb at> wrote:
> On 10/28/2015 08:21 PM, Josh Boyer wrote:
>> The *could* be the same thing,
>> except cloud-init is terrible and I hate it and if that was the single
>> offering we had for some kind of C&S WG I would cry.  I hate it
>> because it is ridiculous to use in a non-cloud environment, and Server
>> very much has that as part of it's reach.
> Forking this thread briefly because I think this deserves its own
> discussion.

I apologize if my rambling wasn't clear on this point.  Hopefully this
tangent is short-lived.

> Is your objection primarily to the concept of cloud-init or the
> implementation? If it's the concept, not much we can help with there. If
> it's the implementation...

Well, neither really.  Admittedly my use of the Cloud images, and
therefore cloud-init, was in attempted to boot it in a VM and log in
more like a traditional install for simple test purposes.  That didn't
work and getting it to the point where I could log in required running
some virt-tool thing to modify the image offline.  So in the context
of "Server & Cloud", where people expect to be able to log in after an
install in many cases, cloud-init makes it really hard and is
ill-suited to that kind of environment.

Specific to cloud environments, I have no idea if the hassle of
getting it setup is the norm or worthwhile.  I've been told it is, and
I can see where having the infrastructure setup to provide the
credentials already in place might make the hassle much less

(It is also quite possible I hit a bug in the cloud image.  I tried
running the local setup to provide cloud-init with ssh keys and it
didn't work, hence the virt-tool thing.  It has been a while since I
tried again.)

> We've talked about replacing cloud-init a few times in the past, but
> there are two objections:
> - cloud-init is "standard" and we have an uphill marketing battle to get
> our image adopted with something else.
> - lack of a great alternative.

I completely believe both of these.

> Mike has talked about a "rich boot process" previously, and I wonder if
> we're ready to start working on that?

I'm not sure what "rich boot process" means.  I'd immediately
interpret that as "a real init process" which to me means using
systemd.  Somehow I don't think that's what you're thinking... :)

> Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight
> contextualization tool that aims to handle initialization of cloud
> instances." [1] Maybe this is something we could look at for F24? CC'ing
> Tamer Tas, the student who worked on that. (It's targeted at being a
> cloud-init replacement for Atomic, so...)
> [1]

That might be nice for "get rid of python" reasons.  If it had
cloud-init compatibility that would be even better, since people
wouldn't need to migrate their provisioning infrastructure.


More information about the server mailing list