That RHEL image doesn't ship with rails installed either, though, does
it?
Ok ROR was probably a bad example since it's not a standard package anywhere.
But what I was trying to get across with "track down and automate" is the build and fix dance it takes to build a Docker image right now, where a package used by a runtime isn't an RPM dependency. Where in Server, an admin isn't going to have to add tar and procps to dnf install rubyonrails. Again, probably not the best specific examples.
But having to install python is probably not the experience a Fedora user would expect.
And that said: if we _do_ decide to make Fedora Atomic the primary
focus, those runtimes would be docker images, with the runtimes as
layers
Runtimes as containers would probably be a nifty thing regardless of Atomic's status. I can see that as a pretty attractive use case for new Fedora users if they can pull a containerized stack and start poking around.
- Matt M
On Thu, Jun 11, 2015 at 4:48 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
