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