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