Agreed, the purpose of the Cloud Base (per the current PRD) is pre-built guest images in various IaaS formats and availabilities.
I want it tailored *for that
environment* and that's it.
Is where we're at loggerheads. While cloud environments are operationally different than bare-metal, it's not useful to most cloud admins to have to track down and automate huge amounts of packages to get to a working Ruby on Rails server, and having a major usability difference between Server and Cloud in that context is going to harm adoption.
To possibly commit a faux pas and talk about RHEL (as a consumer, I'm not a red hatter), RHEL 6 Base on bare metal and RHEL 6 Base in AWS are functionally equivalent. Someone on the inside who knows exactly what the builds contain can probably pick nits but the differences are mostly invisible, aside from repo locations. That's what I think the Cloud SIG needs to deliver for Fedora Cloud Base.
Spinning up a image *inside* an IaaS environment (from Heat or EC2 console) slightly faster isn't an advantage if I then lose more time installing packages over the network, creating a new image to then start using as my baseline.
The SIG goals from the PRD are
Increase in adoption.
Third party support / targeting of Fedora Cloud as a platform.
The reduced footprint should do nothing to harm the goals. I believe that aggressive attempts at driving size down (refactoring cloud-init and removing system python) do not have the return that we expect in terms of the goals over the requirements.
To mangle Einstein "As small as necessary, but no smaller"
- Matt M