16:01:05 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2014-01-07) 16:01:05 <zodbot> Meeting started Tue Jan 7 16:01:05 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:10 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr 16:01:11 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta 16:01:18 <sgallagh> #topic roll call 16:01:25 <davidstrauss> Here we go. 16:01:29 <sgallagh> .hellomynameis sgallagh 16:01:31 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 16:01:32 <nirik> morning 16:01:41 <tuanta> .hellomynameis tuanta 16:01:42 <adamw> .hellomynameis adamwill 16:01:42 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com> 16:01:43 <davidstrauss> .hellomynameis davidstrauss 16:01:45 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com> 16:01:48 <zodbot> davidstrauss: davidstrauss 'David Strauss' <david@davidstrauss.net> 16:01:54 <nirik> .hellomynameis kevin 16:01:55 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com> 16:02:07 <mitr> Hello all 16:02:38 <mizmo> .hellomynameis duffy 16:02:41 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com> 16:04:50 <sgallagh> simo: You around? 16:04:54 <simo> I am now 16:04:54 <sgallagh> I pinged Evolution elsewhere. 16:05:00 <sgallagh> Ok 16:05:05 <simo> sorry discussing alat minute issue with selinux :) 16:05:13 <sgallagh> Yeah, I'm following that. 16:05:15 * sgallagh sighs 16:05:33 <sgallagh> Ok, Evolution cannot make it 16:05:38 <sgallagh> #topic Server Role Requirements 16:06:05 <sgallagh> I realize it was fairly last-minute, but I sent out an email with a first draft of role requirements based on my memory of our other meetings. 16:06:56 * nirik has questions about the api parts... 16:07:00 <mitr> ... and I compounded that by commenting only 10 minutes ago :( I apologize, yesterday I somehow missed that this is the one to review 16:07:58 * adamw goes for a quick read. 16:08:35 <sgallagh> mitr: It only went out in the late afternoon my time, probably late evening for you. 16:08:47 <mizmo> could we maybe organize this a little bit better and maybe start an etherpad? 16:09:04 <sgallagh> mizmo: Sounds good. Mind creating it and I'll copy the two documents in? 16:09:07 <mitr> sgallagh: I had enough time, just was distracted 16:09:16 <sgallagh> We can hopefully reconcile them there 16:09:34 * sgallagh forgets where we're hosting etherpads 16:09:37 <mizmo> yep waiting for the url 16:09:40 <nirik> I guess my concerns are: a) are we writing this api and it's framework? I'd really like us to do as little possible fedora specific... b) when are we going to get to implementation details? because it's hard for my brain to dig into general high level stuff, and I think we might be making a trap for us later if we don't figure out implementation at least at some level. 16:10:08 <adamw> What does 'packaged' mean in point 1., exactly? do you have to be able to deploy the entire role in one yum operation, or are we including the extra layer of 'packaging-y' stuff that server might be doing? 16:10:12 <mizmo> usually use piratepad.net but thats slow so here you go 16:10:13 <mizmo> https://www.piratepad.ca/p/serverwg-roles-proposal 16:10:18 <davidstrauss> I use RiseUp 16:10:25 <mizmo> davidstrauss, do they have etherpad? 16:10:35 <davidstrauss> yes 16:10:40 <mizmo> davidstrauss, oh found it, sec ill move to that 16:10:47 <davidstrauss> https://pad.riseup.net/p/serverwg-roles-proposal 16:10:58 <mizmo> oh there you go thanks 16:11:44 <mitr> Someone please say which one :) 16:12:00 <davidstrauss> We'll use RiseUp 16:12:10 <nirik> adamw: thats the kind of detail I would like to know too. ;) 16:13:14 <sgallagh> Ok, let me try to answer nirik's questions, then adamw's 16:13:58 <sgallagh> nirik: a) I'm using the API term *very* generically. I'd prefer that it be written by the people providing the Role. 16:14:16 <sgallagh> We may set some guidelines for what it has to provide, but not necessarily a wire protocol (so to speak) 16:14:49 <sgallagh> Yes, I realize that this will likely result in fifteen roles with seventeen different implementations of an API that meets those needs 16:15:09 <sgallagh> But I think trying to force them to use one we define will not succeed (initially at least) 16:15:45 <mitr> sgallagh: It's a huge risk, yes; OTOH once we get roles that use different APIs, we'll not be able to standardize again 16:15:55 <sgallagh> b) Discussing too much specific implementation is a trap too. We box ourselves in if we only allow one possible technology to provide a solution 16:16:19 <nirik> sgallagh: weren't you going to make up a role for us to look at ? or was I imagining that? 16:16:47 <sgallagh> adamw: I intentionally left that vague. One example implementation might be that a Role must be a self-contained Docker image, or that it might need to be a complete dep-chain of SCLs. 16:17:10 <sgallagh> nirik: I sent out a FreeIPA example before the holidays 16:17:20 <nirik> ok, perhaps I missed that... will go back and look. 16:17:29 <simo> sgallagh: can you explain rule 2 with an example ? 16:18:04 <nirik> oh right that... 16:18:05 <sgallagh> simo: ipa-client-install 16:18:17 <sgallagh> err ipa-server-install I mean 16:18:29 * nirik fears we are looking off into the castle in the sky and walking off a cliff. 16:18:57 <sgallagh> simo: My intent there was to clarify that installation is not enough for a Role 16:19:06 * adamw is with nirik 16:19:07 <sgallagh> That it must be made useful as well 16:19:25 <adamw> i feel like our only input here is being negative nancys, but - what are we building in the next six months, folks? 16:19:29 <sgallagh> So learn to fly on the way down 16:19:34 <nirik> I mean it's nice we can be general and all, but instead, how about we look at smaller/doable goals and add on to them down the road? 16:19:49 <sgallagh> nirik: Because that's not our deliverable right now? 16:20:08 <sgallagh> That's our deliverable for February(-ish) if the Board approves the PRD 16:20:11 <simo> sgallagh: so if I understand right, if a service does not have a configure script 16:20:27 <simo> the packager needs to create one to be able to make this into a featured role 16:20:30 <sgallagh> We then have to provide a more detailed plan of attack for at least the next release 16:20:30 <jwb> nirik, it's a "builder vs. architect" issue. 16:20:43 <sgallagh> simo: yes 16:20:46 <simo> sgallagh: in this case I would be more subtle 16:20:56 <simo> I would allow 'whatever' if 2 is provided from upstream 16:20:57 <nirik> jwb: yeah, I guess I am a builder and all this architect stuff just makes me wonder what I will have to build. 16:21:11 <simo> but if it is a fedora packaging thing I think we must provide a common framework 16:21:13 <sgallagh> simo: I don't understand that 16:21:23 <sgallagh> ah, I see 16:21:29 <simo> if the script comes from upstream we cannot dictate how it is done 16:21:40 <simo> but if it is done by fedora we should use a common framework 16:21:45 <sgallagh> Right now, I was only indicating that it must be done, not how 16:21:48 <simo> upstream can then adopt it if they like of course 16:21:52 <sgallagh> simo: I can agree with that, though 16:22:02 <davidstrauss> I do want to constrain the roles to one or two packaging/deployment technologies. 16:22:06 <sgallagh> Care to adjust the phrasing in the etherpad, simo ? 16:22:25 <davidstrauss> I don't see it as "boxing us in" any more than RPM boxes us in. 16:22:51 <sgallagh> davidstrauss: Sure, but as previously stated, for the PRD it's okay to specify only that we will select said technologies, not what they are (yet) 16:23:18 <mizmo> guys, i think the point of speaking at a high level for the PRD is to not compromise what our users want/need because of technology limitations. when we get down to the business of implementing stuff, if the PRD asks for something that's not possible, we can change or do it another way. I've been thru the PRD=>product development process a few times and I have never seen anything implemented exactly to the PRD spec 16:23:40 <simo> sgallagh: does that work for you ? 16:23:43 <davidstrauss> I was referring to this: "We box ourselves in if we only allow one possible technology to provide a solution." 16:23:55 <davidstrauss> Is that a statement about our decision now or what we do later? 16:23:58 <sgallagh> simo: Ack 16:24:15 <sgallagh> davidstrauss: Only for the vision, not the implementation 16:24:21 <davidstrauss> Okay, great. 16:24:32 <nirik> mizmo: if so, we should just make a general PRD, pass it, and move on to making some proof of concept roles. (IMHO) 16:24:38 <sgallagh> I'm perfectly fine if we decide "Docker ONLY!" for the implementation later. 16:25:05 <mizmo> nirik, that would be ideal but i think we all keep getting hung up on implementation concerns because we're all more in the engineering discipline than PRD-making :) 16:25:11 <sgallagh> mizmo: That's exactly what I've been trying to say, so I agree :) 16:25:36 <nirik> mizmo: yeah, I know I am... we need to start prototyping and figure out whats doable tech wise... 16:25:45 <mizmo> i mean we should be evaluating sgallagh's proposal, for example, on the basis of whether or not these things would make sense for a user. not whether or not we think it would cause implementation issues 16:25:50 <mizmo> we do the latter after the PRD is passed 16:25:50 <nirik> and whats not doable now, but could be later 16:26:55 <mizmo> should be asking questions like, "how does that help the CTO persona? does that do them any good? will that hinder their workflow? who exactly does this requirement help?" etc 16:27:18 <mizmo> nirik, yep that part is way more fun 16:27:57 <sgallagh> Right, which is why I tried to tie those requirements to use cases 16:28:04 <sgallagh> Which are in turn tied to the personas 16:28:06 <nirik> if we just adjust the PRD later based on the tech, what good is the PRD anyhow? "We will ship fedora server software to our audience the best way possible" done. ;) 16:28:14 <nirik> anyhow... 16:28:54 <jwb> nirik, basically, it's to make sure you build a corporate office building and not a school or house or porta-potty 16:28:54 <sgallagh> nirik: Adjustments to the PRD should be made only if it becomes apparent that how it reads is impossible in some way 16:29:05 <jwb> (to continue the builder analogy) 16:29:11 <sgallagh> jwb: Thanks, I like that 16:29:15 <mitr> nirik: We need to know what we are building prototypes for; or we end up as a collection of people working on their individual favorite ideas 16:29:21 <simo> well the PRD can be amended later if we find out something in it was stupid 16:29:27 <mizmo> nirik, it guides where we want to go. eg going forward without a prd, you might build an awesome house in a shitty neighborhood and missing a needed bedroom. if you sit down in the prd you consider all the variables going on - neighborhood, school quality, number of bedrooms, cost/ budget, size of yard, parking space or not - write down what you want. when you acutlaly go to buy the house you might not end up with the parking spot 16:29:27 <mizmo> you wanted but you got a good house you could afford 16:29:31 <sgallagh> mitr: s/end up/continue to be/ 16:29:32 <simo> so let's see if tihngs *sound right* and let's approve it 16:29:37 <mitr> sgallagh: yes 16:29:38 <nirik> jwb: ok. I fear we may have a house of stucco, mud, bricks and bamboo, but ok. ;) 16:30:05 <jwb> nirik, yeah. implementation of the idea is different than not having an idea ;) 16:30:06 <mizmo> jwb, lol i totally did the builder analogy not seeing your lines, great minds think alike i guess lol 16:30:20 <sgallagh> nirik: A house just like that got me through college ;-) 16:30:30 <davidstrauss> The PRD is a little looser than I'd like it, but I'm okay approving it. 16:30:36 <nirik> anyhow, will stop derailing... sooner we pass a prd, the sooner we can get to prototyping. 16:30:45 <sgallagh> nirik: +1 16:30:50 <mizmo> wait did i miss a prd draft? this is the server role requirements draft right? 16:31:07 <sgallagh> mizmo: This is a section of the PRD draft 16:31:12 <mizmo> oh okay cool 16:31:34 <sgallagh> Assuming we approve it, of course 16:32:25 <mizmo> were there any outstanding questions cuz i had one 16:32:39 <sgallagh> mizmo: Go ahead. 16:32:51 <mizmo> sgallagh, "The Server Role *must* be packaged in such a way that it is possible to install the complete set as a unit." 16:33:07 <mizmo> i hope i'm not nitpicking here, but im wondering what qualifies as the complete set 16:33:23 <sgallagh> mizmo: Fair question. 16:33:43 <mizmo> eg let me give an example, if there's a role for content server, say it uses drupal, and theres maybe 25 drupal plugins packaged up.... are those plugins part of the complete set? 16:33:45 <sgallagh> The stealth requirement here is this 16:34:14 <sgallagh> Using FreeIPA as an example again: The Domain Controller Role must update 389 DS, Kerberos and FreeIPA as a single unit. 16:34:36 <sgallagh> So we avoid issues like FreeIPA being broken regularly by 389 DS patches (for example) 16:34:43 <mizmo> are there optional components to freeipa too? 16:34:56 <simo> mizmo: yes 16:34:58 <sgallagh> mizmo: A few, yes 16:35:02 <simo> and they are a PITA 16:35:06 <sgallagh> You're right, we should clarify. 16:35:14 <mizmo> i mean, maybe we need to say something about each role has a required base, and then optional stuff on top 16:35:14 <simo> because we cannot install rpm on request at ipa-server-install time 16:35:22 <sgallagh> At least the minimal set of useful functionality must be installable as a whole unit. 16:35:24 <simo> so we error out and ask the user to install the missing packages :( 16:35:34 <mizmo> and this required base components and optional components definition should be part of the rol edefinition 16:35:53 <simo> mizmo: I think the idea boild down to creating a 16:35:54 <mizmo> if that were the case then i'd rewrite that requirement so: 16:35:56 <rdoty> Back on Drupal, you have to install and configure a database, a web server, Drupal core, and then there are a lot of optional modules and themes. 16:35:56 <mitr> mizmo: Ultimately this is up to the "definition of the role" - it's not that every role must support plugins, but some will, and the role definition says what is included and if/how it is extensible 16:36:01 <simo> contente-server-role.rpm package 16:36:07 <simo> that has all the required dependencies 16:36:08 <mizmo> "The Server Role *must* be packaged in such a way that it is possible to install the complete set of base components as a unit." 16:36:20 <simo> and if rpom had suggests: it would have the optional deps as suggests 16:36:25 <simo> s/rpom/rpm/ 16:36:42 <davidstrauss> Honestly, I think the current state of Drupal in RPM land is pretty silly. 16:36:42 <mizmo> mitr, +1 that makes sense. do we have that written up anywhere? we probably want to just explicitly state that. 16:36:47 <davidstrauss> I don't know anyone who uses it. 16:37:00 <tuanta> davidstrauss: +1 16:37:09 <simo> davidstrauss: I do not user drupal, but I used django packages 16:37:14 <rdoty> How do you deal with a role that requires a database, and can use MySQL, PostgrSQL, MariaDB, or even SQLite? 16:37:20 <simo> the problem is that then you are stuck to a fedora release 16:37:21 <davidstrauss> I do know that many folks like to install everything necessary to run Drupal using RPM 16:37:24 <simo> but that is ok 16:37:33 <mizmo> rdoty, i think we did say at some point we pick the recommended default but users can switch if they want 16:37:47 <simo> rdoty: you choose one 16:37:48 <mitr> rdoty: +1 to mizmo - just choose one (the one we actually test) 16:37:49 <rdoty> Before, during, or after install? 16:37:50 <mizmo> rdoty, that's just another version of the desktop problem (gnome or kde or whatever) 16:38:07 <simo> rdoty: before install 16:38:23 <simo> rdoty: the role sanctions a specific dependency 16:38:25 <sgallagh> rdoty: Depends on the role, but many of them might punt on that. Nearly all production deployments would be talking to a database managed by a different team 16:38:28 <davidstrauss> What people may want is a "product" that give them everything Drupal needs and a place to put the site code. 16:38:28 <simo> which is what we use for testing 16:38:44 <davidstrauss> Apache, PHP, MariaDB, Redis/memcached, Solr, etc. 16:38:57 <mizmo> davidstrauss, something like buildrequires, but instead - i don't know, runrequires - then you install drupal on your own? 16:39:00 <sgallagh> I'd suggest that installing a DB would not be part of said roles, but the configuration step would allow them to point to any supported DB 16:39:01 <simo> sgallagh: which is where rpm is constraining for the one-click-install 16:39:08 <simo> but I would defer resolving this issue to later 16:39:15 <simo> no need to discuss this for the prd 16:39:17 <rdoty> How about specifying where something is installed? At least user data. 16:39:19 <sgallagh> simo: one-click-install != one-click configuration :) 16:39:42 <rdoty> sgallagh: how do you separate installation and configuration? 16:39:45 <simo> sgallagh: but it is not one-clieck-install if you need multipe clicks to install the various dependencies because you have to choose 16:40:05 <mitr> simo: I think we can't avoid doing something above RPM, to be able to specify the "kickstart-like input" for the installation process 16:40:14 <simo> rdoty: content-server-with-pgsql.rpm vs content-server-with-maria.rpm ? 16:40:17 <simo> just joking 16:40:27 <mitr> rdoty: like we do kickstart files for anaconda 16:40:29 <rdoty> ;-) 16:40:48 <rdoty> mitr: hmm, that could work... 16:41:01 <mitr> (including an s-c-kickstart -like GUI) 16:41:26 <rdoty> simo: I was thinking more along the lines of "where do you want your web root for this Drupal site?" 16:41:33 <sgallagh> mizmo: Have we answered your question sufficiently, or are we making it more confusing? 16:41:45 <sgallagh> rdoty: You're getting too deep in the implementation for now. 16:41:47 <simo> rdoty: that's configuration not installation i mo 16:41:53 <davidstrauss> Allowing an arbitrary webroot would be painful to make work with selinux 16:41:53 <sgallagh> simo: I agree 16:42:16 <rdoty> sgallagh: I'm not sure. If you are configuring a dns server, things are clear. 16:42:16 <simo> davidstrauss: indeed, a "fedora server' role will hardcode a lot of stuff 16:42:19 <mitr> rdoty: We do need to handle storage for "role data", yes. Probably not in the PRD though. 16:42:25 <simo> if you do not like the defaults go install your own thing manually 16:42:29 <mizmo> sgallagh, nope it makes sense! thanks 16:42:31 <mitr> rdoty: even a DNS server needs to store the zone data somewhere. 16:42:35 <rdoty> If you want server roles to include things like Drupal, it gets more complex. 16:42:40 <simo> we are here to make things *simpler* and *standardized* not to "give choice" 16:42:44 <simo> can we all agree on this ^^^^^ 16:42:46 <simo> please ? 16:42:48 <mizmo> amen brother 16:42:49 <mitr> simo: yes please 16:42:53 <rdoty> mitr: isn't their a default location for zone data? 16:42:55 <sgallagh> simo: +1 16:42:56 <simo> rdoty: ? 16:43:12 <rdoty> simo: what are we targeting? 16:43:23 <rdoty> dns, IPA, etc, yes. 16:43:26 <sgallagh> rdoty: I think I can say with some confidence that Drupal will not be a Featured Role in the first pass. 16:43:29 <simo> rdoty: we discussed it quite a few times a while ago 16:43:30 <sgallagh> It's definitely a special case. 16:43:31 <mitr> rdoty: We're thinking "cloud-like deployments", i.e. the ability to "reinstall" a role (on the same or a different machine), keeping the data intact and getting a working server 16:43:43 <rdoty> Drupal, Zimbra, or other applications, more complex. 16:43:49 <rdoty> What is in-scope? 16:43:55 <simo> rdoty: some apps will caus challenges 16:44:01 <rdoty> Yes! 16:44:07 <simo> rdoty: but yes a mail server that use zimbra can be ins cope 16:44:09 <simo> in scope 16:44:20 <mitr> rdoty: First section of https://fedoraproject.org/wiki/Server/Use_Cases is waht we have now, see point 1. 16:44:26 <simo> but it will still hardcode a lot of stuff that is "configurable" in the upstream package 16:44:41 <sgallagh> rdoty: We cannot solve all possible problems up front. We understand fully that some applications may not easily be made into Roles. 16:44:49 <simo> rdoty: but remember "featured roles" are the ones we can work with 16:45:00 <simo> nothing is required to be "featured" 16:45:04 <rdoty> So, Drupal is out of scope? 16:45:17 <simo> no it is just not our foremost concerns at this time 16:45:18 <rdoty> (I'm actually comfortable with that) 16:45:24 <sgallagh> rdoty: Any role is "in scope" if someone wants to spend the effort to make it happen 16:45:35 <rdoty> Umm.... 16:45:38 <sgallagh> What we're defining right now is what rules all roles have to follow to be features. 16:45:41 <sgallagh> *featured 16:45:48 <tuanta> rdoty: if we can define good guidelines, anything could be happened 16:46:04 <mizmo> if scope is f21 - f22 definitely no 16:46:37 <sgallagh> Just a reminder: we're not defining the scope for the next release or two with this document 16:46:59 <sgallagh> We are expressing a guiding set of principals for the forseeable future of the Fedora Server product 16:47:22 <sgallagh> After doing that, we will start to scope specific release goals and focus more on implementation 16:47:39 <davidstrauss> Well, whenever Drupal is in scope, my company runs a good portion of the world's Drupal sites, and we do it on Fedora. 16:47:43 <sgallagh> Can we please table the Drupal discussion as clearly an edge-case? 16:47:58 <sgallagh> ... your timing is impeccable, davidstrauss 16:48:03 <rdoty> sgallagh: no 16:48:14 <rdoty> We can table it as out of scope, but not an edge case 16:48:26 <sgallagh> rdoty: It is out of scope for the PRD at least 16:48:27 <rdoty> To me, it is an example of an entire class of applications 16:48:47 <sgallagh> IMHO I believe it is *in* scope for Fedora Server. 16:48:48 <rdoty> I'm comfortable with declaring it out of scope for the PRD 16:49:04 <rdoty> This helps me understand the boundaries and guidelines 16:49:07 <sgallagh> And yes, that class of applications will require more care and feeding than basic Infrastructure roles 16:49:13 <mitr> I'm ignorant, what's problematic with drupal? That people like to install plugins? Is it structurally different from, say, a Java EE web server where people like to install .[ew]ar s? 16:49:53 <sgallagh> mitr: Primarily just the scope of plugin capabilities. 16:49:55 <simo> mitr: as all frameworks it evolves pretty quickly 16:49:56 <rdoty> mitr: configuration options, modules, data, and site specific customization 16:49:56 <davidstrauss> Jave EE defines the relationship of infrastructure and application more clearly. 16:49:57 <mizmo> mitr: when ive tried to use it from rpm i found it was always out of date and i couldn't use the plugins i wanted 16:50:16 <rdoty> mizmo: that is another interesting issue... 16:50:29 <rdoty> dns and even IPA are a bit more stable 16:50:34 <simo> rdoty: I think specific applications using drupal are more in scope then a generic "drupal" framework, as roles 16:50:43 <rdoty> simo: example? 16:50:48 <simo> I do not know 16:50:55 <simo> I am not a drupal user 16:50:59 <mizmo> i set up a forum gateway for a mailing list server using drupal and some drupal plugins 16:51:00 <sgallagh> simo: Drupal isn't a framework in the same way as Django 16:51:05 <mizmo> that might be a good example 16:51:15 <simo> sgallagh: uhmm indeed 16:51:21 <simo> it is a little bit more specialized 16:51:28 <simo> but I think the same ideas apply 16:51:52 <mizmo> okay moving on 16:52:01 <sgallagh> Perhaps. In any case, can we move on? I think we agree that whoever takes on the responsibility of creating this role has their work cut out :) 16:52:03 <mizmo> any other concerns about the draft 16:52:37 <rdoty> Do we want to say anything about tracking upstream? 16:52:44 <mitr> rdoty: no 16:52:46 <rdoty> Some things evolve rather quickly... 16:53:05 <rdoty> Also, what about supporting multiple versions of some packages and frameworks? 16:53:20 <mitr> Re: 4., do we go as far as "must not duplicate functionality of an existing role"? (Still vague, but I believe the intent is clear) 16:53:36 <sgallagh> mitr: No 16:53:59 <davidstrauss> mitr: I'd say we should say something. Roles should not tarpit the installation in a specific version without automation for security updates. 16:54:05 <sgallagh> mitr: I don't want to answer questions about "Can I make a MySQL role if there's already a MariaDB one?" 16:54:06 <mitr> rdoty: Use cases #6, being somewhat discussed on -server ML. Structurally would probably be an implementation detail of (one of?) the web server roles 16:54:13 <simo> rdoty: I think you keep talking about SCLs 16:54:31 <simo> those are important problems but we are not concentrating on them ourselves at the moment 16:54:46 <mitr> simo: (it seems that nobody really is :( ) 16:54:53 <mitr> davidstrauss: That's an important point, just not sure where to record this. 16:55:04 <simo> mitr: yeah ok, do you want to add "shpards SCL stuff" in the PRD ? 16:55:15 <simo> if not I think we should not discuss it now 16:55:25 <sgallagh> shpards? 16:55:32 <rdoty> How do we want to deal with "latest, latest stable, most widely used" 16:56:17 <sgallagh> rdoty: Probably sufficient for us to assert that as long as someone is maintaining it, any number of versions can be provided (but they have no expectation of co-tenancy) 16:56:37 <mizmo> what is SCL? 16:56:45 <sgallagh> That's kind of the stealth purpose behind Mandatory Requirement 5 16:56:53 <sgallagh> mizmo: Software Collections 16:56:56 <mizmo> ah thanks 16:56:57 <rdoty> sgallagh: good point. I'd suggest calling that out specifically. 16:57:12 <mitr> sgallagh, davidstrauss. Add to start of #5: "A Server role "*must* be possible to update to fix security vulnerabilities with a single click, and maintained to provide security fixes timely"? 16:57:26 <sgallagh> mitr: +1 16:57:33 <davidstrauss> mitr: +1 16:57:42 <mizmo> +1 16:57:52 <rdoty> What about "security vulnerabilities, crashes, and data corruption"? 16:57:53 <simo> sgallagh: takes care of 16:57:54 <simo> sorry 16:57:57 <sgallagh> though I might say "trivially" rather than "single click", but you get the point 16:57:59 <nirik> s/click/action/, but sure :) 16:58:01 <simo> I forgot the word I had in mind :) 16:58:33 <nirik> I don't know that we should micromanage maintainers... that would fall under the fesco updates policy, no? 16:58:41 <mitr> sgallagh: sure 16:58:52 <simo> mitr: you know eventually that rule will be broken right ? 16:58:55 <sgallagh> nirik: How do you see us micromanaging? 16:59:05 <simo> mitr: we have the rule that security updates should be just an rpm update in freeipa 16:59:18 <simo> and yet a couple of time it happend that admins *had* to be involved 16:59:21 <simo> it is lfe 16:59:40 <simo> better to be realistic and acknowledge some times you can't automatically solve eveyrthing 16:59:46 <mitr> simo: (was that fundamental or a limitation of rpm?) 16:59:52 <simo> so that ther eis a franmework to *communicate back* to admins 16:59:57 <nirik> well, just with the number of versions and crashes, etc... a crasher may be a corner case, or may not be easily fixable without a large version bump, etc. 16:59:58 <simo> when something really needs their attention 17:00:10 <mitr> simo: Feel free to reword in any way that doesn't allow "choose the correct upstream version and unpack it manually" 17:00:22 <simo> the lack of a proper admin messaging framework is quite annoying in fact 17:00:33 <sgallagh> mitr: Maybe a data format needs to change in a way not perfectly guaranteed to be automatable? 17:00:47 <simo> it required a password 17:00:55 <simo> which can only be entered if the user is present 17:00:59 <simo> so not automatable 17:00:59 <simo> IIRc 17:01:00 <mitr> simo: the admin messaging framework should be rcorded $somewhere... 17:01:10 <simo> mitr: yes I think that is very important 17:01:17 <sgallagh> simo: We didn't say anything about automatic above 17:01:40 <simo> sgallagh: oh my bad I read "single-click" as automatic 17:02:00 <mizmo> simo, what do you mean by admin messaging framework? 17:02:03 <sgallagh> No, I think we may want to explicitly disallow automatic updating for roles, actually 17:02:03 <mitr> I did kind of read this as implying automatic (or very easily automatable) as well 17:02:13 <mizmo> a way to communicate to admins issues in the software? 17:02:16 <sgallagh> That updates should always require confirmation 17:02:24 <mitr> simo: Add the messaging framework as use case #10 perhaps? 17:02:28 <mitr> a stretch... 17:02:50 * sgallagh wonders if we could abuse fedmsg for that... 17:02:54 <simo> mitr: a way to send messages to admins 17:02:58 <simo> mizmo: ^^ 17:03:07 <mitr> sgallagh: I think this is up to the "data center management" system (Satellite?) to appropriately stage updates to serveres 17:03:15 * sgallagh nods 17:03:59 <simo> mizmo: basically I want a way from an app to call a single API and say: give this "message", of class "security" and priority "urgent" to an "admin" 17:04:09 <simo> mizmo: I do *not* want to know how it is implemented or routed 17:04:25 <simo> mizmo: a simple setup could be to route all this messages via email 17:04:27 <mitr> Basically the current (yum update) system is perfect I think, though we might want to allow more user interaction or post-role-update actions 17:05:02 <mizmo> ah fedmsg would be good for that 17:05:18 <simo> yes, it could be an implementation and a role for fedora-server 17:05:30 <sgallagh> ack 17:05:41 * sgallagh notes we're over the hour 17:05:43 <mizmo> so we're adding admin messaging framework somewhere? 17:05:55 <sgallagh> I'm available to continue 17:06:06 <davidstrauss> We'll re-enable sendmail <ducks> 17:06:08 <sgallagh> mizmo: I think it's being proposed as a use case 17:06:24 <simo> sgallagh: I need to go, more conf calls later and need to do "body servicing" too :-) 17:06:30 <mitr> mizmo, simo: Hm, actually... it's not an use case, I'd suggest to table this as an implementation requirement of some other use cases if/when we need it. 17:06:40 <mitr> sgallagh: I'm available to continue as well. 17:06:47 <simo> mitr: ok, let's just take a not somewhere 17:06:51 <simo> maybe as a potential role ? 17:06:52 <mitr> Actually, I have this week pretty much reserved for the PRD work... 17:07:03 <mizmo> yeh it's not a use case, although it could be rephrased, 'users should be notified by whatever preferred method about issues regarding the server' 17:07:03 <sgallagh> mitr: ditto 17:07:05 * nirik is still here, but distracted somewhat 17:07:07 <simo> keep going 17:07:15 <simo> I will try to monitor the convo if I can 17:07:22 <mitr> simo: Perhaps a "log and alert aggregator", yes 17:09:14 <mizmo> proposal: add the following use case, "Users must be able to receive notifications about issues regarding the server via whatever communication methods are most convenient for them." 17:09:31 <mizmo> er add timely i guess, and maybe qualified or something 17:09:34 * nirik would prefer some upstream solution to this, not us writing one from scratch 17:10:01 <sgallagh> Yeah, let's leave this out of the use-cases for now 17:10:02 <mitr> mizmo: s/whatever.../a suitable method/ ? We're not including a SMS gateway I think 17:10:19 <sgallagh> I'd love to see a Fedmsg role grow up around this that we could then have other roles depend on and consume 17:10:24 <sgallagh> But that's an implementation topic 17:10:30 <mizmo> well i mean 17:10:39 <mizmo> the server has a notification system now right, the mails to root and the log system 17:10:40 <mitr> (well logging has been invented too many times already, why fedmsg again?) 17:10:42 <mitr> sgallagh: The one thing I'm really misssing is domain configuration integration. 17:10:45 <mizmo> but it is a bit of a mess 17:10:52 <nirik> I'm not sure fedmsg is ideal for this, but something that monitors journald and acts on it could be cool. 17:11:04 <sgallagh> mizmo: I don't like that phrasing because we can't easily guarantee that we can aggregate messages from the roles 17:11:10 <simo> mitr: no, messges are not logs, different thing, more structure and all, but whatever 17:11:12 <sgallagh> Unless we're going to mandate a messaging system 17:11:38 <mizmo> im just thinking of all those times i tried to set X up, and there was an selinux error cuasing hte problem, but i didn't get the message and it was loggedout somewhere i didn't know about 17:11:46 <mizmo> or it was a firewall issue 17:11:47 <mizmo> i dont know 17:11:52 <mizmo> i will drop it :) 17:12:52 <sgallagh> In my mind, a message is "Something important happened!" and logs are "Here's how it went down." 17:13:00 <davidstrauss> The selinux issue is vastly improved with "trusted" logger support in the systemd journal. 17:13:30 <nirik> I think this is an important thing to work on, but not now. ;) 17:13:33 <mitr> proposal: 7. A Server Role *must* automatically use and sufficiently implement $specified system-wide settings (e.g. a LDAP source for account information, CA certificates, and similar domain-originated or system-wide configuration) 17:13:35 <sgallagh> nirik: Ack 17:14:51 <sgallagh> mitr: I considered putting exactly that in, but I was concerned that it also pretty much forces us to standardize on a domain controller out of the door 17:14:59 * davidstrauss has to head off. 17:15:07 <davidstrauss> I'll see you folks in the hackfest. 17:15:13 <sgallagh> davidstrauss: Thanks for your help. See you tomorrow 17:15:16 <davidstrauss> I might not be in the earliest portions, though. 17:15:29 <mitr> sgallagh: I think we'd start with $specified == (getent passwd) and then expanding both the number of roles and $specified simultaneously 17:16:13 <sgallagh> I suppose this might actually get easier very soon. 17:16:33 <sgallagh> SSSD is expanding its responders to be able to work with more than just glibc for data lookups. 17:16:54 <sgallagh> So if we standardize on that, we should get future data sources for free 17:17:00 <sgallagh> But here I am talking implementation again... 17:17:19 <sgallagh> mitr: I'm good with that proposal. Other opinions on it? 17:17:44 <nirik> sure. 17:18:09 <sgallagh> (adjusting it to 8. because I originally forgot to copy in my addendum as well) 17:18:18 <sgallagh> See https://pad.riseup.net/p/serverwg-roles-proposal for current status 17:19:35 <sgallagh> mitr: Hmm, we both copied that into different sections 17:19:41 <sgallagh> Do you see that as Mandatory or Optional? 17:19:55 <sgallagh> I assumed that since you used *must* it belonged in Mandatory 17:19:56 <mitr> sgallagh: Sorry, I'm just stupid 17:20:01 <mitr> Deleted the Optional version 17:20:24 <sgallagh> mistakes happen, doesn't make you stupid 17:21:10 <mitr> ... and that's all I have, except for the controversial suggestion that the UIs and APIs should all be unified 17:21:40 <sgallagh> mitr: I think we'd all *like* that, but I'm just not sure it's achievable enough to make it mandatory 17:22:38 <sgallagh> As we go forward, I don't necessarily see anything wrong with working towards that as a goal. 17:22:52 <sgallagh> mitr: Can you think of a way to phrase it that might fit in the Optional Requirements section? 17:23:11 <mitr> I think that given the amount of work we are required to, and do, expend, on making close to perfect RPM packaging, doing a similar amount of programming ("take $this kickstart-like input, turn it into a config file template and the like) shouldn't be too much of an imposition on a competent maintainer. 17:23:24 <mitr> But that's a lot of assumptions in one sentence 17:23:49 <sgallagh> :) 17:23:51 <mizmo> is an optional reqiurement one that could go into the document but might not? or is it just a suggestion? (optional requirement seems like an oxymoron to me?) 17:24:06 <mitr> mizmo: see the top of the document 17:24:10 <sgallagh> Particularly if we account for the fact that the amount of work we require of RPM maintainers is our number one complaint. 17:24:27 <mizmo> ohhhh thanks mitr, dont know how i missed that 17:25:25 <mitr> sgallagh: "A server role *may* implement all of the other requirements by integrating with the Fedora Server-designated infrastructure (commands, APIs, and the like). This is preferred but not mandatory if the upstream provides a different way to achieve the same objective. 17:25:41 <mitr> sgallagh: Or... somehow take into account current Mandatory 2.bis 17:25:42 <sgallagh> mitr: I like that phrasing. 17:26:23 <mizmo> i like it too 17:27:22 <sgallagh> I added it to the Optional Requirements section 17:27:57 <sgallagh> mizmo: I couldn't think of a better term than "Optional Requirement". Can you? 17:28:03 <sgallagh> (I don't love that choice) 17:28:54 <mitr> sgallagh: just s/requirement/functionality/g ? 17:29:26 <sgallagh> I wish I could think of something that better implied that this is sticky. 17:30:15 <sgallagh> "It's a trap!" ;-) 17:30:51 <mitr> sgallagh: perhaps, in front of the lists: "All of the functionality below, if provided, *must* be sufficiently documented. Documented functionality *must* continue to behave in the documented way in the future." 17:31:27 <sgallagh> mitr: I like the first half. 17:31:41 * tuanta needs to go now 17:31:56 <mizmo> sgallagh, ive been thinking, there's a better word than optional, it keeps dancing out of my brain and i can't catch it 17:32:16 <mizmo> its not provisional.... 17:32:31 <sgallagh> Yeah, it's driving me nuts too 17:32:32 <tuanta> see you tomorrow 17:32:35 <sgallagh> tuanta: Thank you 17:32:36 <mizmo> oh conditional 17:32:46 <mizmo> conditional requirements? e.g. if you meet this conditoin this is also a requirement 17:32:49 <mizmo> but you might not meet it 17:33:12 <sgallagh> hmm 17:34:07 <sgallagh> That's at least *better* 17:35:30 <mizmo> okay i gotta go 17:35:51 <sgallagh> Ok, I'll add all of this to the PRD draft on the Wiki 17:36:02 <sgallagh> We can continue discussion on the mailing lists or the hackfest tomorrow. 17:36:08 <sgallagh> Thanks everyone for participating. 17:36:16 <mitr> sgallagh: there's already a draft? 17:36:28 <sgallagh> mitr: https://fedoraproject.org/wiki/Server/Product_Requirements_Document 17:36:38 <sgallagh> It's a work-in-progress, not really a full draft. 17:36:47 <mitr> Great 17:37:13 <mitr> See you tomorrow 17:37:40 <sgallagh> #endmeeting