14:59:41 <sgallagh> #startmeeting Server Working Group Special Overflow Meeting (2013-12-19)
14:59:41 <zodbot> Meeting started Thu Dec 19 14:59:41 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:46 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
14:59:46 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
14:59:50 <sgallagh> #topic roll call
15:00:00 * nirik is about 25% here. :)
15:00:04 <mizmo> .hellomynameis mizmo
15:00:05 <zodbot> mizmo: Sorry, but you don't exist
15:00:11 <mizmo> oh oops
15:00:13 <mitr> Hello all
15:00:14 <mizmo> .hellomynameis duffy
15:00:17 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
15:02:21 <sgallagh> .hellomynameis sgallagh
15:02:23 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:34 <sgallagh> We're currently under quorum...
15:03:04 <sgallagh> simo declined (after marking this time available in whenisgood...?)
15:04:06 <sgallagh> adamw also declined
15:04:36 <sgallagh> Evolution: You here?
15:04:47 <Evolution> yep
15:04:53 <sgallagh> Ok, now we have quorum.
15:05:42 <sgallagh> So we ended Tuesday after deciding to defer release cadence discussions.
15:06:02 <sgallagh> The remaining items on the agenda are "Use Cases" and "Server Role Requirements"
15:06:23 <sgallagh> I tried to restart the use-case conversation on the list, but I only just received the first reply (haven't read it yet)
15:06:40 <sgallagh> Do we want to try to hash those out live right now or on the list?
15:06:43 * nirik has not had much time at all this week to catch up on that. Too busy
15:06:58 <mitr> I'm sorry about sending that reply so late
15:07:13 <sgallagh> mitr: No problem. Thanks for sending it at all :)
15:07:28 <mizmo> " Provide a platform for acting as a node in an OpenStack rack. " do we ask cloud wg about this one
15:08:00 <sgallagh> mizmo: Is that a vote for discussing it today, I'm guessing?
15:08:05 <sgallagh> #topic PRD: Use Cases
15:08:37 <mizmo> lol sure
15:09:29 <mizmo> so what do you think? we sort out openstack rack node one with cloud wg? (although tbh it really does seem like their thing, not ours)
15:09:33 <nirik> so, what are these? for the prd? or?
15:09:36 <mizmo> unless a node in openstack rack is a host?
15:09:39 <mizmo> yeh for the prd
15:09:58 <mitr> We do need to sort this out with Cloud
15:10:02 <sgallagh> mizmo: We should clarify that, but yes. It intended to mean a hypervisor.
15:10:13 <mizmo> okay let's action item that?
15:10:15 * sgallagh notes that Cloud has requested a joint PRD hackfest on Jan 8
15:10:24 <sgallagh> I think we should queue certain questions for that day.
15:10:40 <sgallagh> #info Fedora Cloud has requested a joint PRD hackfest on Jan 8
15:10:53 <mizmo> #action @ Joint PRD Hackfest to-do: Ask Cloud WG about use case #1 "Provide a platform for acting as a node in an OpenStack rack." <= hypervisor
15:10:55 <mizmo> (fair?")
15:10:57 <mitr> I think a very minimal image (one of those 50MB things) should belong in Cloud, but I can equally vell imagine a "full" Server with a Virt Hypervisor role (and the associated Server features)
15:11:33 <mizmo> okay so we work that out with them
15:11:39 <sgallagh> I think it's probably a good idea to have cloud overlap conversations with the Cloud WG>
15:11:44 <mizmo> re #1, "Users of Fedora server will be able to install - at their option - a select set of software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y). [1]"
15:11:55 <mizmo> what kind of software are you thinking? system-config-firewall?
15:12:24 <sgallagh> I'd actually like to drop some of the language here.
15:12:27 <mitr> Later below the page lists various third-party installers
15:12:45 <sgallagh> I think we should be more vague about how we present such GUIs. Merely that we will be able to offer them.
15:13:24 <nirik> so, really really would be nice if a cloud instance could install/use the same roles setup as a bare metal server node... we shouldn't diverge if at all possible.
15:13:39 <sgallagh> But the question of third-party installers is a valid one.
15:13:48 <mitr> "includes a X11 wm" is not an use case.  "Can be used to install Oracle" is (though I'm not sure whether a desirable use case)
15:13:59 <sgallagh> Though if there are third-party programs that don't support installation in a headless environment, do we care?
15:14:36 <mizmo> ah " "We see this also as a dependency requirement for various 3rd party software. For example, Oracle, some printserver software, ArcGIS, and several FlexLM intergrated apps all want at least some portion of a gui to run. Not all of them handle a forwarded display properly. Some link directly to firefox to display their documentation." --Evolution "
15:14:39 * nirik doesn't much
15:14:53 <Evolution> I don't care. users who 'need' it do.
15:15:15 <mitr> I think in practice it will be very likely possible to install X11/whatever packages "from Fedora"; I'm not thrilled about going out of our way to make that a priority right now
15:15:45 <mitr> (OTOH I wouldn't mind at all having X11 as a dependency for a Server-intended functionality)
15:15:49 <sgallagh> Perhaps we need to leave room for a "Desktop Environment" role?
15:15:56 <mitr> sgallagh: no
15:16:22 <mitr> sgallagh: I can run a web browser perfectly fine without going to the server room, thank you; same for my mail client
15:16:35 <nirik> I think this is a corner we should specifically not target at least at first.
15:17:01 <sgallagh> mitr: I was thinking more about "DE+VNC"
15:17:19 <Evolution> we're thinking of ourselves here to some extent. we need to remember the users as well.
15:17:36 <Evolution> and there's a large class of "admins" (air quotes required) who need the security of a gui.
15:17:49 <mizmo> i would have failed my rhct without sys-config-firewall :)
15:17:50 <sgallagh> s/security/security blanket/
15:17:58 <Evolution> sgallagh: yesthat. thanks.
15:18:00 <mitr> sgallagh: I think we don't ever want a web browser running on the server for general web browsing (as opposed to a html widget for $something specific), whether on a physical display or VN
15:18:17 <sgallagh> mitr: I don't think we get to make that decision
15:18:48 <mizmo> why don't we make this use case something like, "Third party installers sometimes suck, and require a graphical environment to run for at least a portoin of the install process. We don't intend to screw users who need these horrible programs"
15:19:01 <mizmo> and also
15:19:04 <nirik> I don't want to make that case hard... but requiring a gui seems like a bad idea to me.
15:19:19 <sgallagh> mizmo: I suppose just a public statement that we will not actively impede such software might be enough
15:19:34 * nirik quotes "The Fedora Project is not interested in having its distribution be a platform for proprietary or patent encumbered components. While we do not purposely make installation of such components more difficult, we also do not allow our schedule or processes to be driven by theirs."
15:19:34 <mitr> I don't necessarily need the language to be so negative, but we can make the decision that in practice this kind of software matters, yes
15:19:39 <sgallagh> Without making any promises to support it.
15:19:49 <mizmo> "Cockpit is great but it doesn't fully cover all you can do with system-config-*, which targets a junior sysadmin who may not be comfortable modifying iptables conf directly. We'll allow usage of such GUI software remotely until such point its functionality is covered by a web-based console tool" ?
15:20:12 <mitr> nirik: I think there earliser was a Server decision that it will be possible to install a GUI-less Server.  Am I misremembering?
15:20:19 <mizmo> well i'm writing these in mo speak, we can professionalize them later :)
15:20:37 <nirik> mitr: dunno. we might have.
15:20:46 <sgallagh> mitr: I think so too. We can check the archives.
15:21:01 <sgallagh> mitr: I'm pretty sure we agreed that a headless install was absolutely necessary
15:21:45 <mizmo> yeh
15:21:47 <mizmo> it should be
15:21:52 <Evolution> very much yes.
15:22:18 <Evolution> I don't want a gui. I (personally) agree with mitr. but at the same time I don't want to actively impede users who want it.
15:22:21 <mitr> mizmo: as an aside, could you please copy&paste rather than link the meetbot minutes (with #action and #agreed) so that mail search works?
15:22:21 <mizmo> #info It should be possible to install a GUI-less server.
15:22:40 <mizmo> mitr, whoah you have a mail client that lets you search the body of emails without snarfing itself?
15:22:40 <nirik> so, the cases where ssh -Y doesn't work are all non free stuff? or is there some common case of software we ship that doesn't work?
15:22:43 <mitr> ... when sending meeting summaries
15:22:50 <mizmo> i could use some help sending them too :)
15:22:55 <mitr> mizmo: gmail seems to work
15:23:05 <mizmo> it takes me hours to do the summaries each week, haven't done in a couple of weeks bc of that
15:23:14 <mizmo> </whine>
15:23:21 <Evolution> nirik: pretty sure the stuff we ship all works. I haven't found something that doesn't yet.
15:23:43 <Evolution> nirik: that said, even in centos-land we still have users who want gparted or similar to manage their partitions.
15:23:59 <mizmo> nirik, i guess maybe the functional requirement htere is that ssh -Y shouldn't be broken on fedora server?
15:24:00 <Evolution> security blanket thing.
15:24:03 <mitr> mizmo: I could commit to resending the meetbot minutes (only);  I can't do the enormous job of re-blogging like you have done I'm afraid
15:24:15 <nirik> mizmo: yeah, thats what I was getting to... at least for software we control.
15:24:22 <mizmo> mitr, if you could do that, it would be awesome, that would give me more time to do the blogging
15:25:30 <mizmo> i searched the blog and didn't get any hits for gui-less install; rather we talked about potentially offering gui ways of doing things
15:25:45 <mitr> Anyway, we seem to have agreed now on that :)
15:25:47 <mizmo> dec 3 and nov 12 meetings
15:25:47 <mizmo> yep
15:25:58 <mitr> So...?
15:26:44 <sgallagh> I don't think we've added anything to the "Headless only or support GUI?" section
15:26:49 <mitr> 1) X11 is not required, but we will make to possible to use it by 3rd parties; 2) X11 is not required, we will not go out of our way to break it (but not an use case) 3) defer 4) let's just not talk about it?
15:26:53 <mizmo> Proposal: Functional requirement that ssh -Y shouldn't be broken on Fedora Server (For use cases of third-party gui-requiring software, and junior sys admins needing sys-config guis)
15:27:01 <sgallagh> Shall we look for a one-sentence phrasing of that and move on?
15:27:46 * nirik would drop the third party there... just say for those wishing to run gui administation tools?
15:27:59 <Evolution> yeah. that works for me.
15:28:09 <mitr> Fine with me
15:28:15 <sgallagh> Proposal: Server must be useful without X11 libraries installed. We commit to supporting only those that can work with forwarded X (or the equivalent on other windowing systems)
15:28:34 <mizmo> only those (gui admin tools?)
15:28:49 <sgallagh> s/only those/only those GUI applications/
15:29:18 <mizmo> Proposal:  Server must be useful without X11 libraries installed. We commit to supporting only those GUI applications that can work with forwarded X (or the equivalent on other windowing systems)
15:29:19 <mizmo> +1
15:29:21 <mizmo> :)
15:29:30 <nirik> sure, +1
15:29:30 <mizmo> (and this is to replace use case #1 right?)
15:29:41 <sgallagh> mizmo: Yes
15:29:47 <mitr> sgallagh: I'd rather have "headless" than "without X11 libraries installed"; a megabyte of compiled code never hurt anybody :)
15:30:09 <sgallagh> mitr: Good point
15:30:15 <sgallagh> Rephrasing:
15:30:18 <mitr> I wouldn't like us to go to great lengths to reshape dependency chains just because of this
15:30:30 <sgallagh> Server must be useful in fully headless operation. We commit to supporting only those GUI applications that can work with forwarded X (or the equivalent on other windowing systems)
15:30:33 <mitr> +1
15:30:56 <sgallagh> +1
15:31:13 <mizmo> +1
15:31:30 <mizmo> ill update the wiki with that now?
15:31:51 <sgallagh> nirik, Evolution: Agree?
15:32:00 <sgallagh> Just looking for +5
15:32:17 <Evolution> yep. agree.
15:32:18 <Evolution> +1
15:32:56 <sgallagh> I'm assuming nirik's +1 from before the rephrase still stands
15:32:57 <sgallagh> #agreed Server must be useful in fully headless operation. We commit to supporting only those GUI applications that can work with forwarded X (or the equivalent on other windowing systems) (+5, 0, -0)
15:33:04 * mizmo updated wiki
15:33:05 <nirik> yes, +1.
15:33:14 <mizmo> okay #2 we have an #action item to talk about with cloud wg
15:33:25 <mizmo> #3: Provide a platform and simple setup for certain infrastructure services, e.g.
15:33:35 <mizmo> ( FreeIPA Domain Controller
15:33:35 <mizmo> BIND DNS
15:33:35 <mizmo> DHCP )
15:33:42 <sgallagh> #3 is pretty much "roles"
15:33:50 <mizmo> that's not really phrased as a use case
15:33:55 <mizmo> but meaning understood
15:34:36 <sgallagh> "The server is only useful as a means to deploy applications. We need to provide that deployment environment"?
15:35:14 <mizmo> "The user must be able to easily deploy certain infrastructure services to Fedora Server."
15:35:25 <mitr> sgallagh: That's not really how I read 3.  3. reads to me we want to provide "these roles" (~applications?); not "we will provide underlying infrastructure for those applications.
15:35:42 <sgallagh> mitr: True
15:36:07 <sgallagh> mizmo: In your experience, how many use-cases should we be looking for, and how general?
15:36:21 <sgallagh> Are we being too specific by listing the roles here?
15:36:48 <mizmo> sgallagh, i think we don't need an exhaustive list of roles here. I think listing a representative sample (we wanted to only start out with 2 or 3 anyway right?) is fine.
15:36:55 * sgallagh nods
15:37:16 <mizmo> # of use cases depends on the size of the product, we're pretty big so we could have a lot. i think to start it's better to keep things simple and focus on the highest priority ones
15:37:23 <sgallagh> How about "The user must be able to easily deploy common infrastructure services to Fedora Server"
15:37:29 <mizmo> i'd say this one is the highest priority one we've discussed thus far. so maybe we reorder the use cases in priority order
15:37:34 <sgallagh> And list a few non-exhaustive examples
15:37:34 <mizmo> that sounds great
15:37:36 <nirik> that implies a bunch
15:37:50 <nirik> perhaps "some common..." ? :)
15:38:09 <mizmo> the use cases should describe what our target users want to do, not necessarily what we will exhuastively to for them
15:38:12 <sgallagh> Well, "common" is a subjective term >:)
15:38:23 <mizmo> for each use case we could make a statement eg
15:38:40 <mizmo> "The user must be able to easily deploy common infrastructure services to Fedora Server." (To start, we will support 1) xxxx and 2) xxxx.)
15:38:47 <nirik> sure.
15:38:57 <nirik> so we are picking initial roles we want to try and do?
15:39:00 <sgallagh> mizmo: +1
15:39:23 <sgallagh> Actually slight rephrase
15:40:03 <sgallagh> "The user must be able to easily deploy common infrastructure services to Fedora Server. We will implement the available services over time."
15:40:17 <sgallagh> I don't think we need to commit to the initial roles in the PRD
15:40:23 <sgallagh> Just that the set will grow over time
15:40:57 <nirik> to be clear, they can install common services already, are we talking about our roles (improved/valueadd) here?
15:41:06 <mizmo> I do think giving representative examples helps people reading understand what we mean / what level we're talking at
15:41:20 <mitr> nirik: yes.  "... and simple setup for" kind of implies this
15:41:59 <mitr> The PRD might contain the use cases in one section, and then expand on featured roles more in another, perhaps.
15:42:09 <nirik> so, "The user must be able to easily deploy and configure any of the supported roles fedora server supports"
15:42:29 <mizmo> +1
15:42:38 <nirik> for example 'freeipa, openstack-server, lamp-stack, etc)
15:43:33 <mizmo> Proposal, replace use case #3 with "The user must be able to easily deploy and configure any of the supported roles fedora server supports"
15:43:41 <mizmo> +1
15:43:42 <mizmo> ...
15:43:42 <sgallagh> mizmo: +1
15:43:56 <Evolution> +1
15:44:02 <Evolution> that wording seems loads better
15:44:12 <mitr> mizmo: keeping the list of examples?
15:44:57 <mizmo> sure, edit "The user must be able to easily deploy and configure any of the supported roles fedora server supports. Examples may include: freeipa, openstack-server, lamp-stack, etc."
15:45:03 <mitr> +1
15:45:22 <nirik> well, the supported... supports reads weird.... what monkey came up with that? oh wait, it was me.
15:45:39 <nirik> +1 for it tho with whatever minor wording changes to make it read better.
15:47:26 <nirik> edit: "The user must be able to easily deploy and configure any supported fedora server role. Examples may include freeip, openstack-server, lamp stack, etc"
15:47:52 <sgallagh> mizmo: As mitr suggests, maybe we keep the list that we have there as "services suggested/requested by the community"
15:48:37 <mizmo> sgallagh, so you're saying not give specific examples but just say ones suggested/requested by the community? i think specifics help readers gauge the scope no?
15:48:52 <sgallagh> Quite the opposite
15:49:11 <sgallagh> I'm saying leave the list that's already on the wiki, but head it with "Some example services suggested by the community:"
15:50:07 <mitr> mizmo: AFAIK the specific list in there was compiled with some thought and I'm not sure about throwing it away and replacing it with "random" examples
15:50:19 <mitr> (Ultimately, of course, whatever will find contributors will get done...)
15:50:24 <nirik> whats the page people are looking at again?
15:50:33 <mitr> https://fedoraproject.org/wiki/Server/Use_Cases
15:50:36 <mizmo> ohhh sure, that sounds fine
15:50:37 <sgallagh> #link https://fedoraproject.org/wiki/Server/Use_Cases
15:51:02 <nirik> ok, sure, we could leave existing examples, thats fine with me.
15:51:10 <nirik> (although I don't think we should care about non free. ;)
15:51:26 <sgallagh> I agree. We can reword the database one
15:51:58 <sgallagh> mizmo: Want me to make this edit?
15:51:59 <mitr> Let's just drop both of the parentheses in there, shall we?
15:52:05 <nirik> mitr: +1
15:52:15 <mizmo> "The user must be able to easily deploy and configure any supported fedora server role. Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server (both free and commercial), Samba Ad Domain Controller, iSCSI target and initiator, NFS server and client.)
15:52:23 <mizmo> sgallagh, (sorry was editing in hexchat input window :) )
15:52:43 <mizmo> Er "The user must be able to easily deploy and configure any supported fedora server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server (both free and commercial), Samba Ad Domain Controller, iSCSI target and initiator, NFS server and client.)"
15:52:45 <sgallagh> mizmo: Drop "(both free and commercial)"
15:52:54 <mizmo> Er "The user must be able to easily deploy and configure any supported fedora server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, Samba Ad Domain Controller, iSCSI target and initiator, NFS server and client.)"
15:53:03 <mizmo> do we have a winner?
15:53:04 <mitr> great
15:53:06 <sgallagh> +1
15:53:44 <mitr> Now that 3 is perfect, do we merge 4 into 3? :)
15:54:02 <sgallagh> mitr: Ack
15:54:14 <mizmo> i'll update the wiki?
15:54:26 <mitr> Actually... "Samba AD Domain Controller, iSCSI target, file server" (leaving out the clients because those are clearly not roles)
15:54:40 <sgallagh> mizmo: Actually, we should probably check what else should be merged into 3 from below
15:54:55 <sgallagh> Some of these were added stream-of-consciousness, I think (sorry, mea culpa)
15:55:11 <mitr> or "NFS and/or SMB file server"?
15:55:18 <mitr> sgallagh: I think it's only 4 and perhaps 17
15:55:29 <mizmo> well it does say examples "may" include, so we're not committing here
15:55:39 <sgallagh> mitr: Let's leave out specific tech and just say Files Server
15:55:40 <mizmo> maybe we should be piratepad-ing this :)
15:55:44 <mitr> sgallagh: wfm
15:55:47 <sgallagh> err s/Files/File/
15:55:57 <sgallagh> We may want to include owncloud in the list, for example.
15:55:58 <nirik> sgallagh: +1 or (storage server)
15:56:02 <mizmo> http://piratepad.net/serverwg-usecases
15:56:38 <nirik> I think a role that setup nfs server, samba server and owncloud would be nice... all playing well together and serving any subset of things the admin wanted.
15:57:23 <sgallagh> nirik: Ditto. I'll ask my unicorn to get to work on that ;-)
15:57:47 * nirik sprinkles rainbows over the storage server. ;)
15:58:39 <mizmo> "The user must be able to easily deploy and configure any supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server,  iSCSI target and initiator, File/Storage server."
15:58:40 <mizmo> ?
15:59:11 <sgallagh> We probably don't need "and initiator" either
15:59:12 <nirik> sure.
15:59:15 <sgallagh> (That's basically the client)
15:59:29 <mizmo> 3. The user must be able to easily deploy and configure any supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server,  iSCSI target, File/Storage server.
15:59:30 <nirik> I don't think we should bog down there in an complete list.
15:59:34 <mizmo> shipit +1?
15:59:38 <mizmo> on to #4?
15:59:38 <nirik> +1,
15:59:39 <mitr> +1
15:59:46 <mitr> Directly to #5
15:59:50 <mizmo> #4 seems exactly the same so we drop it
15:59:52 <mizmo> on to #5
16:00:06 <rdoty> What level of expertise is required to deploy and configure the servre roles?
16:00:42 <sgallagh> rdoty: We're not on that topic right now
16:00:51 <nirik> rdoty: hopefully not too much... but it's hard to say until we get down to implementations and some roles will likely vary
16:00:53 <sgallagh> Currently revising the language of the use cases
16:00:53 <sgallagh> http://piratepad.net/serverwg-usecases
16:00:58 <mizmo> rdoty: these guys https://fedoraproject.org/wiki/Server/Personas
16:01:13 <rdoty> right, I've looked at those
16:01:20 <mizmo> so jr sysadmin up to cto
16:01:24 <sgallagh> BTW, we're over the hour. Anyone have a problem continuing?
16:01:25 <mitr> rdoty: http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/ was floated as a possible example
16:01:38 <rdoty> thank you
16:01:46 <mizmo> i can keep going
16:02:03 <mitr> I'd prefer getting this done in 20-30 minutes
16:02:04 * nirik has a number of things to get done, so wouldn't mind quitting now, but I can try and keep chiming in if people keep going
16:02:25 <sgallagh> Let's see if we can finish up the use-cases portion todayt
16:02:37 <sgallagh> (For the parts that don't need cross-coordination with other WGs)
16:02:44 <mizmo> 4. Platform for deploying web applications with high-value frameworks. (Example frameworks: Ruby on Rails, Django, Turbogears, Node.js.)
16:02:50 <mizmo> question here, how does this affect appliaction stacks?
16:02:56 <mizmo> action item to discuss with app stacks wg?
16:03:06 <mizmo> also it's not stated as a use case
16:03:08 <sgallagh> mizmo: Yes
16:03:44 <mitr> My preferred split would be that $some_other WG makes it possible to run Ruby *gem, and we make it easy to turn a Ruby on Rails app into a running web server
16:04:06 <mitr> The thread I started on fedora-devel has not been terribly encouraging in that direction so far, however
16:04:23 * nirik wonders as a side note if we should mention php here.
16:04:41 <mizmo> seems valid to me
16:04:45 <mizmo> (php)
16:05:50 <mizmo> "The user must be able to easily deploy and configure applications to supported high-value frameworks. (Example frameworks: Ruby on Rails, Django, Turbogears, Node.js, PHP.)"
16:05:51 <sgallagh> Let's drop the question about SCLs.
16:05:58 <sgallagh> We don't need to define the technology in the PRD
16:06:00 <sgallagh> Just the intent
16:06:01 <Evolution> I've got to drop out for another meeting.
16:06:10 <mizmo> whats an SCL?
16:06:17 <sgallagh> Software Collections
16:06:25 <mizmo> oh right
16:06:46 <mizmo> so how bout we mark this one as 'ask software collection wg' and move on?
16:06:53 <sgallagh> Hmm, we may as well merge "JBoss" into 4) as well
16:07:03 <sgallagh> mizmo: Ack
16:07:05 <mizmo> merged
16:07:24 <rdoty> Drupal?
16:07:25 <mizmo> #action approach software collection wg about use case #4: "The user must be able to easily deploy and configure applications to supported high-value frameworks. (Example frameworks: Ruby on Rails, Django, Turbogears, Node.js, PHP, JBoss.)"
16:07:45 <mitr> Yes, and perhaps put it first?  (re-emphasizing that I'm a Red Hat employee for transparency)
16:07:53 <sgallagh> rdoty: That's an application, not a framework
16:08:08 <rdoty> Ummm, it's directly comparable to Django...
16:08:13 <mizmo> Come up with standardized mechanisms for centralized monitoring, configuration and ongoing management
16:08:26 <sgallagh> rdoty: List doesn't need to be exhaustive
16:08:35 <mizmo> mitr, moved to first :)
16:08:38 <mizmo> so what about #5
16:08:44 <mizmo> first issue, not phrases as a use case
16:09:31 <mizmo> also seems very... ambitious
16:09:38 <sgallagh> "The user must be able to monitor, configure and manage a Fedora Server"
16:09:54 <sgallagh> mizmo: This line is written with the clear subtext "OpenLMI"
16:10:05 <sgallagh> That's pretty much its entire purpose.
16:10:46 <sgallagh> "The user must be able to monitor, configure and manage a Fedora Server remotely"
16:11:01 <sgallagh> "The user must be able to monitor, configure and manage a Fedora Server remotely using stable public interfaces"
16:11:15 <sgallagh> Proposal: ^^
16:11:18 <mitr> That's not really how I read it, I'd be honestly perfectly willing to throw OpenLMI overboard if there were something better / more likely to be widespread and useful
16:11:31 <sgallagh> mitr: Well, that's why OpenLMI isn't spelled out.
16:11:33 <mitr> sgallagh: stable and consistent?
16:11:37 <sgallagh> Just that such a mechanism must exist.
16:11:52 <sgallagh> mitr: +1 to that rephrase.
16:12:06 <sgallagh> Proposal: "The user must be able to monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces."
16:12:09 <mitr> +1
16:12:35 <mizmo> +1
16:12:43 <nirik> sure, +1
16:13:18 <mizmo> okay move on?
16:13:40 <mizmo> 6. The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.
16:14:01 <mitr> yes
16:14:05 <mizmo> seems straightforward to me +1
16:14:07 <sgallagh> This is one case where I think we should keep the tech named specifically
16:14:37 <sgallagh> I think line 14 is probably marketing noise.
16:15:07 <mizmo> okay kill it?
16:15:11 <sgallagh> I'm not sure what 7) means in a real meaningful sense.
16:15:15 <mitr> please
16:15:16 <sgallagh> Anyone want to take a stab at it?
16:15:20 <sgallagh> Ok, kill it.
16:15:22 <mizmo> # Isolation of OS from applications
16:15:42 <mizmo> nto phrased as a use case :)
16:15:49 <mitr> None of the "Isolation" things are use cases IMHO
16:15:53 <sgallagh> I agree
16:15:54 <mizmo> kill 'em?
16:15:59 <sgallagh> They're implementation details.
16:16:06 <nirik> 7 could be 'provide a api to list items each role requests be monitored'
16:16:08 <mizmo> i think they're all security-minded implementation ideas
16:16:10 <nirik> thats not great tho
16:16:35 <mitr> Management is more than monitoring
16:17:12 <mizmo> "7. Management of application resource consumption"
16:17:28 <sgallagh> That's kind of the tuned/cgroups catch-all
16:17:55 <mizmo> so much subcontext in these :)
16:18:08 <mizmo> i didnt realize that one okay
16:18:08 <mitr> Basically true.  I'm tempted to nitpick application vs. role, whether we will allow doing this at the level of individual PHP applications, etc, but we probably shouldn't :)
16:18:22 <sgallagh> Administrators must be able to control and contain the resources consumed by services running on the system.
16:18:25 <sgallagh> "Administrators must be able to control and contain the resources consumed by services running on the system."
16:18:35 <mizmo> +1
16:18:35 <mitr> sure
16:18:44 <mizmo> let's be consistent tho, users or administrators?
16:18:59 <sgallagh> Stick with users
16:19:03 <mizmo> kk
16:19:07 <mitr> "simplify management and deployment" - kill ?
16:19:14 <sgallagh> Our user personas are all admins anyway ;-)
16:19:28 <sgallagh> Yeah, that's part of our mission
16:19:28 <mizmo> yeh that one... wtf
16:19:45 <sgallagh> mizmo: Which one?
16:19:55 <mizmo> "simplify management and deployment" is my wtf one
16:20:07 <mizmo> unless theres a subcontext im missing?
16:20:08 <mitr> The DevOps bit is strange but there's some substance to it; not sure how to rephrase
16:21:02 <mizmo> it's tightly packed
16:21:07 <mizmo> what makes a platform a great devops platform
16:21:40 <sgallagh> "Provide mechanisms to enable rapid re-deployment of services to enable DevOps practices"
16:22:01 <mizmo> much better
16:22:03 <mitr> yes
16:22:20 <sgallagh> Now... someone else phrase that as a use-case :)
16:22:53 <mizmo> "Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server."
16:22:55 <mizmo> ?
16:23:00 <sgallagh> mizmo: WFM
16:23:02 <nirik> sure
16:23:43 <mizmo> ooh the newest buzzword containers
16:23:50 <mizmo> Container host management, including at scale (10k containers per host with container hibernation and migration capability)
16:24:21 <sgallagh> "Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface"
16:24:27 <mitr> Hibernation and migration are AFAIK still research projects with ugly ptrace-based implementations (but I haven't been following it in detail)
16:24:51 <mizmo> +1
16:24:57 <mitr> Is this essentially a "container host" role?  Related to 2. ?
16:25:04 <nirik> sounds like
16:25:13 <sgallagh> Lets drop hibernation and migration from an explicit part of the PRD
16:25:40 <sgallagh> Yeah, let's take this to Cloud WG too
16:26:13 <mizmo> kk
16:26:31 <mizmo> Working with upstream and packagers to have first-class systemd support, including native units and outsourcing privilege dropping, logging, and socket listening to systemd. Maximize use of isolation for capabilities, privileges, and namespaces. Continually raise the bar for uniformity of configuration and management tools.
16:26:49 <mitr> not an use case, kill it?
16:26:50 <sgallagh> I'm not sure there's anything here that isn't already covered
16:26:56 <sgallagh> kill it
16:27:12 <mizmo> theres nothing in there systemd-y that might be a valid use case?
16:27:29 <mizmo> next one sounds systemd-y too
16:27:30 <mizmo> No packaged config shipping to /etc (system and services should use defaults with empty /etc)
16:27:31 <sgallagh> We could probably make a couple specific requests
16:27:42 <sgallagh> But not use-cases.
16:27:56 <mizmo> "User will be able to enjoy a high-level of systemd hygiene"
16:28:06 <sgallagh> I can think of some general requirements (like: we should prefer socket activation where possible)
16:28:06 <mizmo> Users must be able to easily identify the server roles deployed on a server.
16:28:20 <sgallagh> mizmo: You expect Linux users to have hygiene now? ;-)
16:28:30 <mitr> mizmo: that's on the level of "Users will be able to use programs that compile without warnings", why would they care?
16:28:39 <nirik> this seems more like a implemention thing than a use case.
16:28:44 <sgallagh> nirik: Ack
16:28:46 <mitr> Some similar rules things like the /etc thing may end up as an implementation decision of roles
16:28:54 <mizmo> i just wanted to use systemd and hygiene in a sentence
16:28:59 <nirik> I mean, I'm not against it, I thiink its a nice goal, but... it's not really a use case.
16:29:04 <nirik> mizmo: ha.
16:29:04 * mitr needs to start using actual nouns instead of "thing"
16:29:08 <sgallagh> :)
16:29:18 <mizmo> the next one is valid though right
16:29:20 <mizmo> "Users must be able to easily identify the server roles deployed on a server."
16:29:31 <sgallagh> mitr: That one actually worked fine.
16:29:47 * sgallagh added that one during this conversation, so I hope so :)
16:30:01 <mitr> sgallagh: which "that one"?
16:30:06 <sgallagh> 10)
16:30:15 <mizmo> "Users must be able to easily identify the server roles deployed on a server."
16:30:24 <nirik> does that come under the configuration and management/
16:30:35 <mitr> We do need to analyze an installed system; I'm not sure that specifically this needs to be called out (as opposed to any number of other things) but I'm not going to spend time arguing against it
16:30:39 <sgallagh> Ah, true. Probably covered there
16:30:47 <mizmo> we talk about identify, deploy, and configure, but what about remove roles?
16:31:01 <mitr> mizmo: secondary IMHO
16:31:03 <sgallagh> mizmo: I'm going to suggest that we explicitly ignore that
16:31:11 <mitr> (... and will probably be implemented as a part of re-deploy anyway)
16:31:15 <mizmo> what if we modify #3, "The user must be able to easily deploy, configure, and identify any supported Fedora Server role."
16:31:19 <sgallagh> In the real-world, people remove roles by re-deploying/formatting.
16:31:25 <mizmo> or just leave 10
16:31:41 <sgallagh> mizmo: Scrap 10. I think it's covered by 5)
16:31:44 <mizmo> k
16:31:45 <mitr> sgallagh: Would the "identify roles" be sumbsumed by "monitor", or do we need a little more in there?
16:32:04 <mizmo> #action ask cloud wg about use case #9: "Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface"
16:32:20 <sgallagh> mitr: added "query" to 5)
16:32:30 <sgallagh> Sufficient?
16:32:39 <mitr> great
16:32:46 <nirik> sure
16:32:50 <mizmo> can we order these in priority order? #1 is definitely not most important
16:33:35 <sgallagh> mizmo: I'd like to suggest that we may want to make prioritization a task for the full WG
16:33:40 <mizmo> maybe put the ask other wg ones at the bottom, headless one at the very bottom?
16:33:41 <sgallagh> We're at minimum quorum here.
16:33:43 <mizmo> just for now?
16:33:56 <sgallagh> mizmo: Sure, that's ok for now.
16:34:00 <mizmo> the #1 is really not so critical, so at least move that one, i think the first in the lits should be important if anything to make the list more readable
16:34:00 <mizmo> kk
16:34:10 <sgallagh> Let's submit this current list to the mailing list and ask for input on priority order
16:35:06 <sgallagh> I'll add it to https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Document_Draft (which is the draft I've been working on this last week) and send out an email to the list.
16:35:16 <sgallagh> s/it/the results of this discussion/
16:35:21 <mizmo> okay we good
16:35:32 <mizmo> i'll update the use case wiki page?
16:35:42 <sgallagh> #action sgallagh to update the PRD draft
16:36:01 <sgallagh> #action sgallagh to send email requesting prioritization of the use-cases
16:36:21 <sgallagh> mizmo: Go ahead. I'm going to copy the one-sentence versions to the PRD draft directly
16:36:35 <mizmo> kk
16:36:36 <sgallagh> (No need to link away just for that)
16:36:37 <mizmo> done
16:36:42 * mitr vanishes
16:36:45 <mitr> Thanks everyone
16:36:46 <sgallagh> mitr: Thanks!
16:37:11 <sgallagh> mizmo: Should we move the Questions/Discussion points to the Talk page?
16:37:21 <sgallagh> Actually, no
16:37:26 <sgallagh> Ignore that.
16:37:50 <sgallagh> Ok, thanks everyone for participating. I think we made a lot of headway today
16:38:01 <sgallagh> #topic Open Floor
16:38:51 <sgallagh> #info Cross-WG PRD Hackfest 14:00 UTC to 18:00 UTC on 2014-01-08
16:39:04 <sgallagh> Anyone else have anything for Open Floor?
16:39:34 <sgallagh> Happy Holidays everyone! I'll close out the meeting in 60s
16:39:35 <mizmo> nothing here from us chickens
16:40:36 <sgallagh> #endmeeting