On Fri, Oct 25, 2013 at 08:41:15AM -0400, Robyn Bergeron wrote:
Just thought it might get some thoughts moving in people's heads
around
use cases and different goals in usage - I think folks are going to
continue to basically go with "best tool for the job" (where the job ==
their job and its associated requirements, which may not necessarily be
technology-related requirements), so I think it might be useful to have
some good thought around how to make ... what we wind up making :) ...
fairly flexible, or maybe "re-composable" is the word i'm looking for.
Images, guests, containers, etc... how to build them similarly enough to
make them consistent enough to test, how to make the building simple
enough for build them themselves (and applying config mgmt of sorts either
as part of the build, or afterwards) ...
One approach would be to produce a library of "base images" for different
tasks -- docker (maybe even 3x: host, system container, app container),
openshift, vagrant, generic cloud-init, generic lighter-than-that,
repackaged fedora-server-in-the-cloud, fedora-desktop-in-the-cloud,
openstack host node.... each of the things. Here, the Fedora Cloud product
is actually a tool/ui/process for making cloud images, not really the cloud
image itself (although the library would be important).
At the other extreme, we could take something like Docker (which I've
personally been playing with and think is pretty cool), or ZeroVM, or
whatever, and focus our resources around it as _the_ particular one thing we
are going to knock out of the park. We wouldn't _block_ the other things,
but would focus on making that case the best possible.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>