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