On Thu, Jun 11, 2015 at 03:37:00PM -0400, Matt Micene wrote:
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.
I'm not clear on the "track down and automate" comment here. That's
going to be the same on Cloud _or_ Server — `nf groupinstall
rubyonrails`
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.
That RHEL image doesn't ship with rails installed either, though, does
it?
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.
Agreed — that's where the idea of having a dozen or so images
preconfigured with popular runtimes makes sense. But an image with
_all_ the runtimes doesn't.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader