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. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
