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

[Adam Miller]

On Thu, Oct 29, 2015 at 8:33 AM, Michael McGrath <mmcgrath at redhat.com> wrote:
> On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
>> On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier <jzb at redhat.com> 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
>> problematic.
>>
>> (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... :)
>>
>
> If you hate cloud-init, then you'll love rich boot.  Which is
> essentially a handoff at boot time from cloud-init to Ansible for
> further configuration.

+1

Sounds great, looking forward to more information on the topic.

-AdamM

>
>        -Mike
>
>>> 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] https://github.com/tmrts/flamingo
>>
>> 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.
>>
>> josh
>
>
>
> --
> Mike McGrath | mmcgrath at redhat.com | (312) 660-3547
> Atomic | Red Hat Chicago | http://projectatomic.io/
> _______________________________________________
> 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