Fedora 22 is out, Fedora 23 is coming :)

[Matt Micene]

>
> 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 at fedoraproject.org>
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 at fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20150611/1c2c375c/attachment.html>