15:00:36 #startmeeting Server Working Group Weekly Meeting (2014-04-29) 15:00:36 Meeting started Tue Apr 29 15:00:36 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:36 #chair sgallagh mizmo nirik davidstrauss adamw simo tuanta mitr 15:00:36 Current chairs: adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta 15:00:36 #topic roll call 15:00:50 * nirik is sort of here, but also trying to catch up on the days fires. 15:01:32 my name is mizmo and im here to say, i'm ready for the server wg meeting in a special kind of way 15:01:35 Uh oh. Bad? 15:01:46 .hellomynameis adamwill 15:01:50 adamw: adamwill 'Adam Williamson' 15:01:53 mizmo: I didn't think this was THAT kind of a meeting 15:02:28 Hi folks. 15:03:59 * twoerner is here to talk about firewalld integration 15:04:07 twoerner: Thank you for joining us today 15:04:24 sgallagh: thank you for the invite 15:04:48 * stefw says hi 15:05:42 Hello, sorry I'm late 15:05:57 no problem, still gathering the tribe 15:06:47 hello, sorry for beeing late, stepping out right now from anothe rmeetking 15:06:52 *meeting 15:07:43 I think that's everyone but tuanta now 15:07:53 #info Agenda Item: WG Membership 15:08:20 As noted on the mailing list, Jim Perrin voluntarily stepped down from the WG 15:08:43 #info The Server WG thanks Jim Perrin for his service up to this point 15:09:00 We therefore need to fill his space. 15:09:26 We haven't sent out a formal request for volunteers, but we have had two individuals - stefw and danofsatx-dt - come forward and express an interest. 15:10:01 oh I missed danofsatx-dt candidacy, was it on the list ? 15:10:17 simo: He mentioned it during the meeting last week 15:10:29 ah 15:10:40 sorry 15:10:50 let's have a debate! 15:10:52 I am also interested in taking part in the Server WG 15:11:15 excellent 15:11:16 I did not know that there is an open seat 15:11:37 twoerner: it opened a week ago 15:11:40 yeah, we didn't really announce it 15:11:44 it was on the server wg mailing list 15:11:50 (fedora-server@) 15:12:00 Just as a reminder: participation in the Server SIG does not require a seat on the WG. The WG serves mostly as a decision-making organization 15:12:04 err sorry (server@) 15:12:27 So anyone who is interested in participating should absolutely do so, regardless of a position on the Working Group 15:12:31 sgallagh: can you recap the competency we selected jim for at the time (if we recorded them anywherE) 15:12:38 and see what are the one sof the candidates 15:12:41 just briefly 15:12:51 so we can get to a decision reasonably quickly ? 15:13:23 Well, we selected him to represent the needs of downstream distributions 15:13:34 should we drop a devel-announce post that we have a open seat and give a week for any other candidates? or do we have enough now? ;) 15:14:13 sgallagh: does anywone of the candidates in someway fulfill that role ? 15:14:17 Proposal: Given that three candidates are involved enough to have announced candidacy without a formal announcement, we shall select from that group. 15:14:32 i thoguht there were 2 15:14:43 mizmo: stefw, danofsatx-dt, twoerner 15:14:43 sgallagh: +1, if you are interested enough to find out, it means you are following enough to be a good candidate :) 15:15:42 sure, ok with me. 15:15:43 fwiw, if there was an eager candidate willing to represent downstream distributions, i think that would be very valuable 15:15:53 sgallagh: +1 15:16:14 * nirik thinks all 3 candidates would be great. I hope whichever we choose the other 2 stay involved in any case. ;) 15:16:14 stefw: Is there any major downstream other than RHEL and its clones? 15:16:17 stefw: it would, but I do not thing we need to hold on to find the perfect representative 15:16:45 I agree. Highly-motivated individuals should trump "filling a slot", IMO 15:16:54 anyone can take task to be liaison, but of course someone involved in both for real tend to have a better perspective 15:17:43 davidstrauss, hmm, true, not that i know of 15:17:50 so.. what do you expect this candidate to provide exactly? 15:17:51 I might suggest that stefw has a strong claim due to involvement with Fedora Atomic 15:18:05 Which could be argued to be a downstream distro :) 15:18:18 twoerner: It's a fuzzy question. 15:18:42 Maybe we should turn it around: Candidates: give us a one- or two-sentence reason why you feel you would be a good fit for the Server WG. 15:19:35 sgallagh: That's kind of lazy :) Though more practical. 15:19:51 * sgallagh also notes that danofsatx-dt appears not to be around this week. 15:20:10 And we're burning through our hour at an alarming pace. 15:20:31 sure. i'm very involved in Cockpit, the server UI, which we hope to deliver for Fedora Server 21. Cockpit isn't just a pretty face. to make it work well often needs integration with other parts of the server, an sane underlying architecture. hence the interest in the Server WG. 15:20:33 sgallagh: stef already sent reason on server@ 15:20:45 so I'd like to hear from twoerner 15:21:13 * sgallagh nods 15:22:46 I have long term experience with Linux, Red Hat and Fedora systems. I am the lead maintainer of firewalld and part of the security team. The integration into the server is a very important task. 15:24:03 this was the short version .. 15:24:29 ok seem you 2 have similar goals and backgrounds 15:24:43 danofsatx-dt's statement last week was "I'll volunteer to fill any empty spots if needed. I'm running F20 servers now, so I do have some experience ;)" 15:24:46 sgallagh: do we have anything from danofsatx-dt that we can put together to represent his stance ? 15:24:52 (obviously he's not here to give a better accounting) 15:25:24 maybe you should then wait to decide this next time, when all are around 15:25:34 That would probably be fair. 15:25:51 twoerner: I think you and danofsatx-dt should send a folow up message on the original thread on server@ 15:26:03 #topic Server WG Membership 15:26:03 then next week the remaining members can take a vote based on that 15:26:07 (forgot to change the topic...) 15:26:10 ... and perhaps explicitly allow for more candidates to step up as well? 15:26:16 mitr: indeed 15:26:31 mitr: but I guess, if you re not following server@ you are not already interested enough ? 15:27:06 simo: It's a good indication, but not that overwhelming to make me _entirely_ happy with closing the roster immediately. I would be reasonably happy with either decision though. 15:27:23 #info Candidates will present their arguments for their selection on the mailing list. We will vote next week on who to bring aboard. 15:27:27 mitr: it is not an absolute filter sure 15:27:41 but if we announce today I think a week time for anyone else to step up sound reasonable 15:27:48 mitr: If you want to send out a wider announcement, be my guest 15:28:10 I'm just wary of this getting unwieldy. 15:28:18 Shall we move on to the API discussion? 15:28:44 sgallagh: I think I'd be perfectly fine with a #info the candidacy period closes on May 6, in our meeting minutes. 15:29:13 #info The candidacy period closes on May 6 15:29:16 Thanks :) 15:29:23 #topic Server Role API 15:29:59 I've been speaking with twoerner a little about our high-level goals with the Server Role Infrastructure 15:30:26 He has indicated that he'd be interested in writing the D-BUS service that we need. 15:30:55 awesome! 15:30:57 To that end, I thought it would be wise to talk through our needs (again) with him around so that he will be able to design it 15:31:30 twoerner: I'll be working closely with you on this as well, so don't assume you are taking on all the burden alone :) 15:31:41 ok :-) 15:32:35 So at a high-level, we want to build a low-level service that fulfills the requirements noted at https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Mandatory_Requirements 15:33:34 The intent is for this API to be consumable by the Cockpit Project, OpenLMI and also to provide a local client tool (which should also be usable by QA to test the API) 15:33:59 I also asked stefw to join us to represent the needs of this API from the Cockpit side of things. 15:34:01 * nirik nods. local command line tool... 15:34:40 let me see if tflink' 15:34:50 s available to see if there are any particular needs... 15:35:09 in addition to the general low level api, it's likely cockpit will want to talk (or implement) some per service configuration dbus api as well 15:35:20 Considering that this is for roles and running as DBus, how will this happen? "Package selection will be supplementary. There will be no option in the installer to install less than the Fedora Server standard installation. Options to install Fedora Server Roles will be provided, as well as a UI to install other software from the Fedora Project repositories." 15:35:21 The intention is for us to use existing services as much as possible, so that we are providing an abstraction and convergence layer, rather than a huge amount of new logic 15:36:04 davidstrauss: I don't understand the question. Where do you see the discrepancy? 15:36:37 davidstrauss: IIRC the installation will be done through comps groups (i.e. the role definition and comps groups contain duplicates of the same information) 15:37:03 Also, we will be developing https://fedoraproject.org/w/index.php?title=Changes/AnacondaServerRoleSupport to be able to deploy roles in Kickstart. 15:37:08 mitr: Oh, so the installer *won't* use the D-Bus APIs for roles. 15:37:29 davidstrauss: The installer will use the D-BUS API to *configure* roles 15:37:48 It will be able to install them and leave them unconfigured until post-install if we don't finish the Anaconda plugin 15:37:59 (hence the overlap with comps groups) 15:38:50 davidstrauss: Does that answer your question or confuse it? 15:39:01 It just seems like a lot of added installer complexity to have it launch a D-Bus service in order to accomplish configuration goals. 15:39:19 Let me get back to describing the API needs, which may help 15:39:49 davidstrauss: It makes the common case simple, and the uncommon installation case more complex, which is, I think, generally the right balance. 15:39:50 Classically, we've (Fedora) only enabled package installation in Anaconda, but many packages are not useful without configuration 15:39:55 * nirik notes there's still questions around if we have a seperate server installer tree composed or not. I sure hope we can avoid it... but it may be needed to make non server things not appear in the installer. 15:41:01 The Server Role API must be able to provide sufficient information to a Role (a holistic collection of packages that serves a purpose, such as a "Domain Controller") that it will be running and usable when complete. 15:41:12 sgallagh, when anaconda completes? 15:41:22 that's a pretty high bar 15:41:33 So, presumably, we'll need Kickstart config that maps to the calls to the D-Bus API. 15:41:37 * stefw has a hard time thinking of anyone else who tries to pull that off in a general purpose OS. 15:41:51 So, we'd go GUI -> KS -> D-Bus -> Roles. 15:41:51 Maybe I'm misunderstanding you 15:42:04 By GUI, I mean installer GUI. 15:42:15 davidstrauss: At the moment, we are not talking about the GUI 15:42:19 That's a future goal 15:42:40 it sounds like this would be more than just installing packages? 15:42:41 stefw: I'm modeling this after *your* realmd design :) 15:42:52 That the resulting system should (when booted) be completely configured 15:42:59 tflink: Much more, yes. 15:42:59 sure, that's joining a domain 15:43:41 sgallagh: I'm just emphasizing how the complexity will layer if we do it the way (1) Anaconda handles config plus (2) a D-Bus API. 15:44:07 davidstrauss: yes, I can see your point here.. 15:44:47 davidstrauss: We'd be doing this via an anaconda plugin. I see no reason why we couldn't let Anaconda present this information to the user in a way consistent with other config 15:45:20 ok, with integration into anaconda I can see a fit 15:45:27 sgallagh: This isn't about user complexity but rather implementation complexity. 15:45:36 davidstrauss, exactly 15:45:58 it's possible to make configuration happen on a non-running system. but it's not pretty. 15:46:03 the implementation, that is 15:46:36 I guess this is a rather roundabout way for me to ask if it's sensible for the Roles API service to support configuration directly from Kickstart without running as a D-Bus-accessed daemon. 15:46:41 do you have information in an anaconda plugin about package installations steps? 15:46:55 anyway, as long as anaconda implementation doesn't become a constraining factor, i'm not against it. just cautioning that it's going to add lots of work 15:47:22 stefw: Acknowledged. If that proves infeasible for F20, we'll drop it. 15:47:26 s/anaconda implementation/anaconda configuration/ 15:47:30 I guess the alternative would be only install in anaconda, and try and do some kind of configure on firstboot? thats bad for unattended folks tho. 15:47:55 nirik: Yeah, but that might just be "This is for F20, we'll fix that in F21" answer. 15:48:26 * nirik nods. I'd defer to those actually doing the work as to whats feasable. 15:48:27 For the moment, let's proceed assuming that we're only handling the firstboot config case 15:48:31 nirik: there could be a plugin like for example password or user/groups 15:48:51 davidstrauss: It seems possible to factor the D-Bus server code in such a way that it can also be run in one-shot command-line mode, but then writing a little shell to start dbus and the ordinary server and the ordinary CLI client seems so much simpler. 15:49:44 mitr: I'm less concerned about starting the D-Bus server than managing the serialization of configuration options through GUI -> KS -> D-Bus -> Roles. 15:50:03 mitr: It does, but I see the concern if it also means we have to start N other services for the D-BUS service to talk to 15:50:04 It could get complicated quickly 15:50:05 Let's defer this bikeshed until later; we're running out of our hour and I know that some people have a hard stop 15:50:37 sgallagh: We can move on, but I don't see how this is a bikeshed. 15:51:00 davidstrauss: Because even if we decide not to deal with config in kickstart, we STILL need the post-install API to work 15:51:14 The purpose of the discussion is to bring twoerner up to speed on what we want that API to do 15:51:53 So the API needs to be able to manage a few obvious things: 15:52:10 sgallagh: Yes, and whether D-Bus is the primary and only way to access that API affects later implementation complexity. 15:52:12 1) Install all the necessary packages to support a role, if they are not already in place 15:52:59 sgallagh: ok.. one major question about the service: do you have backends, for for things you want to be able to tune, that the service can use? 15:53:02 davidstrauss: I'm not saying it's not an important question. 15:53:08 I'm saying it's best saved for another day :) 15:53:26 sgallagh: Actually, you are. A bikeshed is inherently a question of limited impact. 15:53:36 twoerner: Sorry, I'm not sure what you mean. 15:53:47 davidstrauss: Then I chose an ill-advised term. Mea culpa. 15:53:54 sgallagh: ok.. for package installs we can use yum or packagekit 15:54:12 sgallagh: Okay, let's move on. :-) 15:54:13 or dnf :) 15:54:24 simo: yes, right.. I am sorry 15:54:30 twoerner: In general, I'd prefer that we prefer the use of tools that are platform-independent 15:54:52 Redundant sentence is redundant... 15:55:02 twoerner: Each "role" will probably need to provide some (Python) code; we don't need to support any "backends" implementing the underlying functionality (yum/polkit) not required by the Server tech spec 15:55:35 mitr: yum/pok was an example.. everyone knows about them :-) 15:55:55 twoerner: in general we'll go with whatever the platfrom considers the default, right now that's yum I guess 15:56:05 twoerner: Same goes for firewalls, networking, systemd/init.d - look at the tech spec 15:56:53 ok 15:59:15 so i wanted to ask quickly if anyone had looked at the 'test outline' i sent and had any thoughts 15:59:32 https://fedoraproject.org/wiki/Server/Technical_Specification 15:59:32 (for posterity) 15:59:34 We're at the hour. Who is turning into a pumpkin vs. can stay a bit longer? 15:59:55 adamw: read it, have no comments. 15:59:59 i'm kind of hoping to combine it with test outlines for desktop and cloud and do a very early skeleton 'test plan' for fedora 21 / fedora next in general whose primary purpose would be to graphically illustrate "HEY WE SOMEHOW NEED TO TEST ALL THIS STUFF" 16:00:02 mitr: rgr 16:00:23 sgallagh: I can stay for ~30 minutes 16:00:31 adamw: I did read it on Friday and found it to be a sensible 30,000 foot view. 16:00:48 if anyone sees issues with that approach, do yell, otherwise i'll just keep on trucking and at some point next month a Giant Adam Mail will descend to ask the question of who the heck's gonna do all this work. ;) 16:01:15 sgallagh: thanks 16:01:43 I am sorry, but I have to leave now 16:01:47 twoerner: Do I remember correctly that you had a hard stop? 16:01:50 I guess "yes" 16:02:08 twoerner: Let's continue this discussion in #fedora-server over the next couple days, then 16:02:13 I have to leave, but I'll check my IRC logs and the mailing list for any follow-ups. 16:02:16 I don't necessarily want this to wait until next week 16:02:25 are there any plans to automate some of the testing? 16:02:29 ok, thank you 16:02:42 * nirik was fine with the testing outline... 16:02:48 tflink: i'm kind of assuming we're going to have to, but i was sort of planning to ask you that :P 16:03:04 I browsed the testing outline. It looked fine to me, too. 16:03:07 tflink: One of the arguments in favor of developing much of this as an API is so that hopefully it makes automation easier :) 16:03:08 I have to leave too, great discussion so far 16:03:08 https://fedoraproject.org/wiki/User:Adamwill/Draft_Server_test_outline is the link btw. 16:03:13 se ey'all next week 16:03:33 if the API does what I think it will, that could help 16:03:44 tflink: in my very fuzzy crystal ball it involves doing a proper test plan with at least some detail about what precisely we can / need to test, and then mapping that against our actual capabilities for automated testing via taskotron and (anything else?) and our capacity to develop the tests. 16:03:48 my concern would also be about verificaiton/validation that the correct things were done 16:04:05 tflink: or if you're talking specifically about the role API, sorry. 16:04:20 i thought that was the topic of discussion, did I miss something? 16:04:26 nope you're fine 16:04:35 i thought we'd kinda hit open floor and started a new one, but apparently i was wrong 16:04:59 #topic Proposed QA Test Plan 16:04:59 tflink: Then it would probably be a good idea to help us plan it. 16:04:59 (That may have come across snarky. Not my intent.) 16:05:22 sgallagh: actually can we go back to the role API so tflink can ask about that specifically? sorry, my bad 16:05:35 i think we're OK on the topic of the broader test outline/plan for now 16:05:36 #undo 16:05:36 Removing item from minutes: 16:06:06 adamw: You kind of hijacked the "who can stick around?" question :) 16:06:47 sgallagh: there was three minutes of silence prior to that, and i asked my question right before you asked that ;) 16:07:07 I'm sure my terminology is off but would the goal be for atomic validation or more holistic validation? (defs to follow) 16:07:50 adamw: I think my network connection may be hiccuping today, because I keep getting messages in bursts :-/ 16:07:50 atomic -> every single step of the action in the api call(s) is verified. file /etc/foo/bar.cfg contains the correct info, rpms A,B and C were installed etc. 16:08:19 holistic -> run API calls, poke at the test instance to validate that it's behaving within expected parameters 16:08:24 tflink: For Server Roles, I'd say "holistic" 16:08:49 The assumption is that the Roles are being built atop other components that have received some reasonable amount of testing already. 16:08:58 At this layer, we should be testing the integration 16:09:36 out of curiosity, are the cloud images going to use this server api as well? 16:09:45 So less "Does the PostgreSQL pgsql.conf have the following entries?" and more "Can I connect to it and perform a search?" 16:10:17 ok, that should be a bit easier in some ways. i wasn't sure how we would parse the api code for validation 16:10:23 tflink: They have a feature called "Adopt your cattle" that will allow a server image to *become* a Fedora Server instance 16:10:58 So the standard instance will not have this API, but an "adopted" instance will 16:11:16 sgallagh: i'm starting to worry about that assumption in general, and I kinda feel like it'd be nice if each layer could 'export' its tests such that they can be run in wider scopes. obviously not our problem to fix that for yum, but I do think it'd be nice if, say, things are set up so we could run the server role API test suite easily in taskotron whenever a Server nightly is built (he said, building castles in the sky) 16:11:49 adamw: Define "layer" in that sentence, please? 16:12:14 sgallagh: sorry, vague. it's the "Roles are being built atop other components" bit - I'm thinking of the 'other components' 16:12:22 how many roles can each server have? 16:12:26 But yes, I intend for us to build our test suite such that it should be easy to have a CI build run it 16:12:36 sgallagh: awesome, that's all that's relevant right now. 16:12:54 tflink: Right now, we're only committed to "supporting" one Role on a server 16:13:24 (We will eventually put together a list of known roles that don't work together, but that's down the road a piece) 16:13:27 would each server have to be a VM or could it run in docker? 16:13:46 tflink: That is an untested question 16:13:50 if it's a VM, could the cloud images work or would it have to be installed from scratch? 16:13:59 Right now we're assuming core Infrastructure, so a VM makes sense. 16:14:05 ie, with anaconda (ks or whatever other method) 16:14:33 tflink: I'd need to consult with the Cloud guys to answer that; I don't know offhand. 16:14:53 All of our assumptions to date have involved a bare-metal or VM installation. 16:15:15 With VM being loosely-defined (might be straight KVM, could theoretically be an IaaS instance) 16:15:54 any guesses on how soon there might be test cases available to run? 16:16:17 ~ a month, 2-3 months, 6 months, a year etc. 16:17:30 tflink: No later than July 22nd? ;-) 16:17:30 tflink: We haven't finished designing the API. It'll be hard to say until we get down to it 16:18:09 sgallagh: ok, I wasn't looking for specifics. just wondering what kind of timeline it'd be looking at 16:18:20 tflink: We're looking at "before Alpha freeze" 16:18:28 Which is July 22nd 16:18:42 So, damn well better be under three months. 16:19:19 I also suspect that the kinds of tests you're talking about may be a good fit for beaker 16:19:40 * sgallagh nods 16:20:00 Yes, we'll have to use something like Beaker for running them, I think 16:22:28 * sgallagh wonders if it got quiet or his network connection hiccuped again 16:25:39 tflink: Still there? 16:26:37 sgallagh: yeah, got distracted. sorry 16:26:54 tflink: No problem 16:27:08 Do you have other questions, or shall I close out the meeting and go have lunch? :) 16:27:22 no more questions for now 16:27:42 * tflink is trying to brace himself for the incoming feature requests that he thinks will be coming soon 16:28:33 I think I understand what you're looking to do for automated testing of the server role api 16:28:56 * sgallagh nods 16:28:57 #topic Open Floor 16:28:57 Anyone have anything for Open Floor today? 16:28:57 it sounds reasonable and should be do-able. not sure about a timeline, but do-able 16:29:07 tflink: Thank you 16:29:21 sgallagh: np, thanks for answering my questions 16:29:57 I'll close out the meeting in two minutes if there are no other topics. 16:32:17 #endmeeting