On 11/15/2013 01:35 PM, Stephen Gallagher wrote: Agreed I myself are in the both camp since as I envision things being more or less like this in the future ( 5+ years )... Home/hobby/Junior administrators and small businesses will be running and administrating servers from an mobile web app and or mobile web interface in a public cloud or what I like to dub "containerships" where you simply chose/select a server role through a google play store deployment process, while the medium/large businesses administrators host it themselves on bare metal or in their own private cloud or "containerships". JBG

On 11/15/2013 04:53 PM, Kevin Fenzi wrote: Or they can just install a single role into a container or a run it in a VM on the " *one* beefy machine" We truly should not play blender here because the outcome will be just that a mess. JBG

On 11/15/2013 05:31 PM, Kevin Fenzi wrote: Or if we go separated product way simply continue to use Fedora like you have been doing for the last 10 years. JBG

Hello, (Choosing a fairly random point in the thread, just because this happens to illustrate my point.) On Fri, Nov 15, 2013 at 6:28 PM, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote: And... what OS does the "one beefy machine" run? Is it a pet or livestock? Actually, I'd say our role _is_ that of the blender. Or, alternatively, I think I'm arguing that the pet vs. livestock question is irrelevant and possibly misleading in what we are trying to do here. There is a difference between pets and livestock, but _every site has both_: * Even the pure-cloud, throw-all-instances-away deployments have a critical pet component (the shared storage mechanism that keeps the company/user's data). * In a sense, every single startup of a daemon is a "livestock" process that can be just restarted if it crashes[1] Or, from another angle: for each application/deployment, there is a scale of how automated the deployment is, and how much state is stored locally and mustn't be lost, and how little manual work is required from the sysadmins, all the way from "prototype being reconfigured by changing #defines in the source code" (0%) to "completely stateless arch-independent ISO image" (100%). On this scale, there is a fairly definite point when pets become livestock, and it is fairly close to the "completely stateless ISO image" end. _But that doesn't make all the rest of the scale (pets) equivalent_. We do need comprehensive, reliable, and easy to use software that helps with configuration and deployment; we do need to minimize manually managed state; we do need to remove manual work from the sysadmins in general; and _that's_ the core of the work, both for Server and Cloud, and whether any specific machine or VM this runs on ends up as a "pet" or a "livestock". Historically for servers we've found it acceptable to get perhaps to 60% of the scale, and Cloud wants to get to 95% so that it can be called "livestock". In the meantime, we're talking about a Server product that does more for the administrators, perhaps getting us to 80-85%. In any case, this is a _shared_ problem between Server and Cloud, and it should be a shared design allow us to share work results. I'm really not that worried about the pet/livestock difference, because it's "only" a matter of getting bits to run. As suggested above, every single running process is, in a sense, a piece of livestock [2], and every cloud deployment as a group is a pet; from the point of user interaction If, given anaconda source code and a repository of RPMs, getting to a working interactive installation method, or kickstart installation method, or image deployment method, is about a man-month of work (a completely made up number), getting Fedora from 60% on the automation scale to 95% will certainly take man-years (hopefully shared between many people). Focusing on the pets/livestock divide between Server/Cloud obscures the work that we should be doing together. We already have methods to get the bits to run, let's start working on having useful bits.[3] (Or, Stephen, to more directly address your post: In any case we need a configuration API, and software that implements requests by that API. Whether that API is working with pets or livestock is not that important in its design; if having that API shared between Server and Cloud required some changes to how we treat server roles on an already installed machine, that would probably be well worth it.) Mirek [1] ... if it hasn't corrupted the "pet" data storage mechanism. Corner cases always kill analogies. [2] And we _can_ actually implement the various server roles in that way, using a "server+cloud mail server configuration tool" to create $data and use said $data to set up the mail server role; to reconfigure the server, load $data back into the tool, modify it to get $data_v2, and "unistall+reinstall" the server role using $data_v2. There doesn't need to be any huge difference between the underlying Cloud and Server mechanism. [3] This is of course somewhat hand-wavy and actual installation/deployment does need a lot of careful thought and effort; this is not meant to denigrate that work.

On 11/16/2013 03:56 AM, Simo Sorce wrote: What you say there is the state were we are at this time then why not simply drop the effort of ServerWG altogether and leave things as they are? JBG

On 11/16/2013 02:34 PM, Simo Sorce wrote: Coming from the man that tears down the entire logic of having server roles in the first place. JBG

On 11/16/2013 01:17 AM, Miloslav Trmač wrote: I disagree we should not be allowing people to play blender and mix/change server roles not with this effort. We should rather find what they are adding and why because maybe it something we missed in the FOSSP or simply missing Application stack in a server role and we work towards adding that missing functionality or missing server role. If people want to play blender they user Fedora if they want to "server roles" they use FedoraOS" ( assuming we dont do the drastic mistaken of actually disrupting users workflow by mutuality current Fedora ) JBG

On Mon, Nov 18, 2013 at 2:45 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: The line between "pre-installed role" and "first-boot configuration" is somewhat blurry; this might in fact be very similar to 2). Hypothetically, we might design it in such a way that the only difference between 2) and 3) is that in 3), "adding a role" notices that the required RPM packages are already present and doesn't install them again. Mirek