On Thu, Oct 29, 2015 at 8:33 AM, Michael McGrath <mmcgrath@xxxxxxxxxx> wrote: > On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier <jzb@xxxxxxxxxx> 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@xxxxxxxxxx | (312) 660-3547 > Atomic | Red Hat Chicago | http://projectatomic.io/ > _______________________________________________ > 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
