14:59:41 #startmeeting Server Working Group Special Overflow Meeting (2013-12-19) 14:59:41 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:59:46 #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr 14:59:46 Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta 14:59:50 #topic roll call 15:00:00 * nirik is about 25% here. :) 15:00:04 .hellomynameis mizmo 15:00:05 mizmo: Sorry, but you don't exist 15:00:11 oh oops 15:00:13 Hello all 15:00:14 .hellomynameis duffy 15:00:17 mizmo: duffy 'Máirín Duffy' 15:02:21 .hellomynameis sgallagh 15:02:23 sgallagh: sgallagh 'Stephen Gallagher' 15:02:34 We're currently under quorum... 15:03:04 simo declined (after marking this time available in whenisgood...?) 15:04:06 adamw also declined 15:04:36 Evolution: You here? 15:04:47 yep 15:04:53 Ok, now we have quorum. 15:05:42 So we ended Tuesday after deciding to defer release cadence discussions. 15:06:02 The remaining items on the agenda are "Use Cases" and "Server Role Requirements" 15:06:23 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 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 I'm sorry about sending that reply so late 15:07:13 mitr: No problem. Thanks for sending it at all :) 15:07:28 " Provide a platform for acting as a node in an OpenStack rack. " do we ask cloud wg about this one 15:08:00 mizmo: Is that a vote for discussing it today, I'm guessing? 15:08:05 #topic PRD: Use Cases 15:08:37 lol sure 15:09:29 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 so, what are these? for the prd? or? 15:09:36 unless a node in openstack rack is a host? 15:09:39 yeh for the prd 15:09:58 We do need to sort this out with Cloud 15:10:02 mizmo: We should clarify that, but yes. It intended to mean a hypervisor. 15:10:13 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 I think we should queue certain questions for that day. 15:10:40 #info Fedora Cloud has requested a joint PRD hackfest on Jan 8 15:10:53 #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 (fair?") 15:10:57 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 okay so we work that out with them 15:11:39 I think it's probably a good idea to have cloud overlap conversations with the Cloud WG> 15:11:44 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 what kind of software are you thinking? system-config-firewall? 15:12:24 I'd actually like to drop some of the language here. 15:12:27 Later below the page lists various third-party installers 15:12:45 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 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 But the question of third-party installers is a valid one. 15:13:48 "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 Though if there are third-party programs that don't support installation in a headless environment, do we care? 15:14:36 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 I don't care. users who 'need' it do. 15:15:15 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 (OTOH I wouldn't mind at all having X11 as a dependency for a Server-intended functionality) 15:15:49 Perhaps we need to leave room for a "Desktop Environment" role? 15:15:56 sgallagh: no 15:16:22 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 I think this is a corner we should specifically not target at least at first. 15:17:01 mitr: I was thinking more about "DE+VNC" 15:17:19 we're thinking of ourselves here to some extent. we need to remember the users as well. 15:17:36 and there's a large class of "admins" (air quotes required) who need the security of a gui. 15:17:49 i would have failed my rhct without sys-config-firewall :) 15:17:50 s/security/security blanket/ 15:17:58 sgallagh: yesthat. thanks. 15:18:00 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 mitr: I don't think we get to make that decision 15:18:48 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 and also 15:19:04 I don't want to make that case hard... but requiring a gui seems like a bad idea to me. 15:19:19 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 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 Without making any promises to support it. 15:19:49 "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 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 well i'm writing these in mo speak, we can professionalize them later :) 15:20:37 mitr: dunno. we might have. 15:20:46 mitr: I think so too. We can check the archives. 15:21:01 mitr: I'm pretty sure we agreed that a headless install was absolutely necessary 15:21:45 yeh 15:21:47 it should be 15:21:52 very much yes. 15:22:18 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 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 #info It should be possible to install a GUI-less server. 15:22:40 mitr, whoah you have a mail client that lets you search the body of emails without snarfing itself? 15:22:40 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 ... when sending meeting summaries 15:22:50 i could use some help sending them too :) 15:22:55 mizmo: gmail seems to work 15:23:05 it takes me hours to do the summaries each week, haven't done in a couple of weeks bc of that 15:23:14 15:23:21 nirik: pretty sure the stuff we ship all works. I haven't found something that doesn't yet. 15:23:43 nirik: that said, even in centos-land we still have users who want gparted or similar to manage their partitions. 15:23:59 nirik, i guess maybe the functional requirement htere is that ssh -Y shouldn't be broken on fedora server? 15:24:00 security blanket thing. 15:24:03 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 mizmo: yeah, thats what I was getting to... at least for software we control. 15:24:22 mitr, if you could do that, it would be awesome, that would give me more time to do the blogging 15:25:30 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 Anyway, we seem to have agreed now on that :) 15:25:47 dec 3 and nov 12 meetings 15:25:47 yep 15:25:58 So...? 15:26:44 I don't think we've added anything to the "Headless only or support GUI?" section 15:26:49 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 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 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 yeah. that works for me. 15:28:09 Fine with me 15:28:15 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 only those (gui admin tools?) 15:28:49 s/only those/only those GUI applications/ 15:29:18 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 +1 15:29:21 :) 15:29:30 sure, +1 15:29:30 (and this is to replace use case #1 right?) 15:29:41 mizmo: Yes 15:29:47 sgallagh: I'd rather have "headless" than "without X11 libraries installed"; a megabyte of compiled code never hurt anybody :) 15:30:09 mitr: Good point 15:30:15 Rephrasing: 15:30:18 I wouldn't like us to go to great lengths to reshape dependency chains just because of this 15:30:30 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 +1 15:30:56 +1 15:31:13 +1 15:31:30 ill update the wiki with that now? 15:31:51 nirik, Evolution: Agree? 15:32:00 Just looking for +5 15:32:17 yep. agree. 15:32:18 +1 15:32:56 I'm assuming nirik's +1 from before the rephrase still stands 15:32:57 #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 yes, +1. 15:33:14 okay #2 we have an #action item to talk about with cloud wg 15:33:25 #3: Provide a platform and simple setup for certain infrastructure services, e.g. 15:33:35 ( FreeIPA Domain Controller 15:33:35 BIND DNS 15:33:35 DHCP ) 15:33:42 #3 is pretty much "roles" 15:33:50 that's not really phrased as a use case 15:33:55 but meaning understood 15:34:36 "The server is only useful as a means to deploy applications. We need to provide that deployment environment"? 15:35:14 "The user must be able to easily deploy certain infrastructure services to Fedora Server." 15:35:25 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 mitr: True 15:36:07 mizmo: In your experience, how many use-cases should we be looking for, and how general? 15:36:21 Are we being too specific by listing the roles here? 15:36:48 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 # 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 How about "The user must be able to easily deploy common infrastructure services to Fedora Server" 15:37:29 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 And list a few non-exhaustive examples 15:37:34 that sounds great 15:37:36 that implies a bunch 15:37:50 perhaps "some common..." ? :) 15:38:09 the use cases should describe what our target users want to do, not necessarily what we will exhuastively to for them 15:38:12 Well, "common" is a subjective term >:) 15:38:23 for each use case we could make a statement eg 15:38:40 "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 sure. 15:38:57 so we are picking initial roles we want to try and do? 15:39:00 mizmo: +1 15:39:23 Actually slight rephrase 15:40:03 "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 I don't think we need to commit to the initial roles in the PRD 15:40:23 Just that the set will grow over time 15:40:57 to be clear, they can install common services already, are we talking about our roles (improved/valueadd) here? 15:41:06 I do think giving representative examples helps people reading understand what we mean / what level we're talking at 15:41:20 nirik: yes. "... and simple setup for" kind of implies this 15:41:59 The PRD might contain the use cases in one section, and then expand on featured roles more in another, perhaps. 15:42:09 so, "The user must be able to easily deploy and configure any of the supported roles fedora server supports" 15:42:29 +1 15:42:38 for example 'freeipa, openstack-server, lamp-stack, etc) 15:43:33 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 +1 15:43:42 ... 15:43:42 mizmo: +1 15:43:56 +1 15:44:02 that wording seems loads better 15:44:12 mizmo: keeping the list of examples? 15:44:57 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 +1 15:45:22 well, the supported... supports reads weird.... what monkey came up with that? oh wait, it was me. 15:45:39 +1 for it tho with whatever minor wording changes to make it read better. 15:47:26 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 mizmo: As mitr suggests, maybe we keep the list that we have there as "services suggested/requested by the community" 15:48:37 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 Quite the opposite 15:49:11 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 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 (Ultimately, of course, whatever will find contributors will get done...) 15:50:24 whats the page people are looking at again? 15:50:33 https://fedoraproject.org/wiki/Server/Use_Cases 15:50:36 ohhh sure, that sounds fine 15:50:37 #link https://fedoraproject.org/wiki/Server/Use_Cases 15:51:02 ok, sure, we could leave existing examples, thats fine with me. 15:51:10 (although I don't think we should care about non free. ;) 15:51:26 I agree. We can reword the database one 15:51:58 mizmo: Want me to make this edit? 15:51:59 Let's just drop both of the parentheses in there, shall we? 15:52:05 mitr: +1 15:52:15 "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 sgallagh, (sorry was editing in hexchat input window :) ) 15:52:43 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 mizmo: Drop "(both free and commercial)" 15:52:54 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 do we have a winner? 15:53:04 great 15:53:06 +1 15:53:44 Now that 3 is perfect, do we merge 4 into 3? :) 15:54:02 mitr: Ack 15:54:14 i'll update the wiki? 15:54:26 Actually... "Samba AD Domain Controller, iSCSI target, file server" (leaving out the clients because those are clearly not roles) 15:54:40 mizmo: Actually, we should probably check what else should be merged into 3 from below 15:54:55 Some of these were added stream-of-consciousness, I think (sorry, mea culpa) 15:55:11 or "NFS and/or SMB file server"? 15:55:18 sgallagh: I think it's only 4 and perhaps 17 15:55:29 well it does say examples "may" include, so we're not committing here 15:55:39 mitr: Let's leave out specific tech and just say Files Server 15:55:40 maybe we should be piratepad-ing this :) 15:55:44 sgallagh: wfm 15:55:47 err s/Files/File/ 15:55:57 We may want to include owncloud in the list, for example. 15:55:58 sgallagh: +1 or (storage server) 15:56:02 http://piratepad.net/serverwg-usecases 15:56:38 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 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 "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 ? 15:59:11 We probably don't need "and initiator" either 15:59:12 sure. 15:59:15 (That's basically the client) 15:59:29 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 I don't think we should bog down there in an complete list. 15:59:34 shipit +1? 15:59:38 on to #4? 15:59:38 +1, 15:59:39 +1 15:59:46 Directly to #5 15:59:50 #4 seems exactly the same so we drop it 15:59:52 on to #5 16:00:06 What level of expertise is required to deploy and configure the servre roles? 16:00:42 rdoty: We're not on that topic right now 16:00:51 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 Currently revising the language of the use cases 16:00:53 http://piratepad.net/serverwg-usecases 16:00:58 rdoty: these guys https://fedoraproject.org/wiki/Server/Personas 16:01:13 right, I've looked at those 16:01:20 so jr sysadmin up to cto 16:01:24 BTW, we're over the hour. Anyone have a problem continuing? 16:01:25 rdoty: http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/ was floated as a possible example 16:01:38 thank you 16:01:46 i can keep going 16:02:03 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 Let's see if we can finish up the use-cases portion todayt 16:02:37 (For the parts that don't need cross-coordination with other WGs) 16:02:44 4. Platform for deploying web applications with high-value frameworks. (Example frameworks: Ruby on Rails, Django, Turbogears, Node.js.) 16:02:50 question here, how does this affect appliaction stacks? 16:02:56 action item to discuss with app stacks wg? 16:03:06 also it's not stated as a use case 16:03:08 mizmo: Yes 16:03:44 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 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 seems valid to me 16:04:45 (php) 16:05:50 "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 Let's drop the question about SCLs. 16:05:58 We don't need to define the technology in the PRD 16:06:00 Just the intent 16:06:01 I've got to drop out for another meeting. 16:06:10 whats an SCL? 16:06:17 Software Collections 16:06:25 oh right 16:06:46 so how bout we mark this one as 'ask software collection wg' and move on? 16:06:53 Hmm, we may as well merge "JBoss" into 4) as well 16:07:03 mizmo: Ack 16:07:05 merged 16:07:24 Drupal? 16:07:25 #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 Yes, and perhaps put it first? (re-emphasizing that I'm a Red Hat employee for transparency) 16:07:53 rdoty: That's an application, not a framework 16:08:08 Ummm, it's directly comparable to Django... 16:08:13 Come up with standardized mechanisms for centralized monitoring, configuration and ongoing management 16:08:26 rdoty: List doesn't need to be exhaustive 16:08:35 mitr, moved to first :) 16:08:38 so what about #5 16:08:44 first issue, not phrases as a use case 16:09:31 also seems very... ambitious 16:09:38 "The user must be able to monitor, configure and manage a Fedora Server" 16:09:54 mizmo: This line is written with the clear subtext "OpenLMI" 16:10:05 That's pretty much its entire purpose. 16:10:46 "The user must be able to monitor, configure and manage a Fedora Server remotely" 16:11:01 "The user must be able to monitor, configure and manage a Fedora Server remotely using stable public interfaces" 16:11:15 Proposal: ^^ 16:11:18 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 mitr: Well, that's why OpenLMI isn't spelled out. 16:11:33 sgallagh: stable and consistent? 16:11:37 Just that such a mechanism must exist. 16:11:52 mitr: +1 to that rephrase. 16:12:06 Proposal: "The user must be able to monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces." 16:12:09 +1 16:12:35 +1 16:12:43 sure, +1 16:13:18 okay move on? 16:13:40 6. The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain. 16:14:01 yes 16:14:05 seems straightforward to me +1 16:14:07 This is one case where I think we should keep the tech named specifically 16:14:37 I think line 14 is probably marketing noise. 16:15:07 okay kill it? 16:15:11 I'm not sure what 7) means in a real meaningful sense. 16:15:15 please 16:15:16 Anyone want to take a stab at it? 16:15:20 Ok, kill it. 16:15:22 # Isolation of OS from applications 16:15:42 nto phrased as a use case :) 16:15:49 None of the "Isolation" things are use cases IMHO 16:15:53 I agree 16:15:54 kill 'em? 16:15:59 They're implementation details. 16:16:06 7 could be 'provide a api to list items each role requests be monitored' 16:16:08 i think they're all security-minded implementation ideas 16:16:10 thats not great tho 16:16:35 Management is more than monitoring 16:17:12 "7. Management of application resource consumption" 16:17:28 That's kind of the tuned/cgroups catch-all 16:17:55 so much subcontext in these :) 16:18:08 i didnt realize that one okay 16:18:08 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 Administrators must be able to control and contain the resources consumed by services running on the system. 16:18:25 "Administrators must be able to control and contain the resources consumed by services running on the system." 16:18:35 +1 16:18:35 sure 16:18:44 let's be consistent tho, users or administrators? 16:18:59 Stick with users 16:19:03 kk 16:19:07 "simplify management and deployment" - kill ? 16:19:14 Our user personas are all admins anyway ;-) 16:19:28 Yeah, that's part of our mission 16:19:28 yeh that one... wtf 16:19:45 mizmo: Which one? 16:19:55 "simplify management and deployment" is my wtf one 16:20:07 unless theres a subcontext im missing? 16:20:08 The DevOps bit is strange but there's some substance to it; not sure how to rephrase 16:21:02 it's tightly packed 16:21:07 what makes a platform a great devops platform 16:21:40 "Provide mechanisms to enable rapid re-deployment of services to enable DevOps practices" 16:22:01 much better 16:22:03 yes 16:22:20 Now... someone else phrase that as a use-case :) 16:22:53 "Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server." 16:22:55 ? 16:23:00 mizmo: WFM 16:23:02 sure 16:23:43 ooh the newest buzzword containers 16:23:50 Container host management, including at scale (10k containers per host with container hibernation and migration capability) 16:24:21 "Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface" 16:24:27 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 +1 16:24:57 Is this essentially a "container host" role? Related to 2. ? 16:25:04 sounds like 16:25:13 Lets drop hibernation and migration from an explicit part of the PRD 16:25:40 Yeah, let's take this to Cloud WG too 16:26:13 kk 16:26:31 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 not an use case, kill it? 16:26:50 I'm not sure there's anything here that isn't already covered 16:26:56 kill it 16:27:12 theres nothing in there systemd-y that might be a valid use case? 16:27:29 next one sounds systemd-y too 16:27:30 No packaged config shipping to /etc (system and services should use defaults with empty /etc) 16:27:31 We could probably make a couple specific requests 16:27:42 But not use-cases. 16:27:56 "User will be able to enjoy a high-level of systemd hygiene" 16:28:06 I can think of some general requirements (like: we should prefer socket activation where possible) 16:28:06 Users must be able to easily identify the server roles deployed on a server. 16:28:20 mizmo: You expect Linux users to have hygiene now? ;-) 16:28:30 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 this seems more like a implemention thing than a use case. 16:28:44 nirik: Ack 16:28:46 Some similar rules things like the /etc thing may end up as an implementation decision of roles 16:28:54 i just wanted to use systemd and hygiene in a sentence 16:28:59 I mean, I'm not against it, I thiink its a nice goal, but... it's not really a use case. 16:29:04 mizmo: ha. 16:29:04 * mitr needs to start using actual nouns instead of "thing" 16:29:08 :) 16:29:18 the next one is valid though right 16:29:20 "Users must be able to easily identify the server roles deployed on a server." 16:29:31 mitr: That one actually worked fine. 16:29:47 * sgallagh added that one during this conversation, so I hope so :) 16:30:01 sgallagh: which "that one"? 16:30:06 10) 16:30:15 "Users must be able to easily identify the server roles deployed on a server." 16:30:24 does that come under the configuration and management/ 16:30:35 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 Ah, true. Probably covered there 16:30:47