15:00:36 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2014-04-29)
15:00:36 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:36 <sgallagh> #chair sgallagh mizmo nirik davidstrauss adamw simo tuanta mitr
15:00:36 <zodbot> Current chairs: adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
15:00:36 <sgallagh> #topic roll call
15:00:50 * nirik is sort of here, but also trying to catch up on the days fires.
15:01:32 <mizmo> 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 <sgallagh> Uh oh. Bad?
15:01:46 <adamw> .hellomynameis adamwill
15:01:50 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
15:01:53 <adamw> mizmo: I didn't think this was THAT kind of a meeting
15:02:28 <davidstrauss> Hi folks.
15:03:59 * twoerner is here to talk about firewalld integration
15:04:07 <sgallagh> twoerner: Thank you for joining us today
15:04:24 <twoerner> sgallagh: thank you for the invite
15:04:48 * stefw says hi
15:05:42 <mitr> Hello, sorry I'm late
15:05:57 <sgallagh> no problem, still gathering the tribe
15:06:47 <simo> hello, sorry for beeing late, stepping out right now from anothe rmeetking
15:06:52 <simo> *meeting
15:07:43 <sgallagh> I think that's everyone but tuanta now
15:07:53 <sgallagh> #info Agenda Item: WG Membership
15:08:20 <sgallagh> As noted on the mailing list, Jim Perrin voluntarily stepped down from the WG
15:08:43 <sgallagh> #info The Server WG thanks Jim Perrin for his service up to this point
15:09:00 <sgallagh> We therefore need to fill his space.
15:09:26 <sgallagh> 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 <simo> oh I missed danofsatx-dt candidacy, was it on the list ?
15:10:17 <sgallagh> simo: He mentioned it during the meeting last week
15:10:29 <simo> ah
15:10:40 <simo> sorry
15:10:50 <adamw> let's have a debate!
15:10:52 <twoerner> I am also interested in taking part in the Server WG
15:11:15 <simo> excellent
15:11:16 <twoerner> I did not know that there is an open seat
15:11:37 <simo> twoerner: it opened a week ago
15:11:40 <nirik> yeah, we didn't really announce it
15:11:44 <simo> it was on the server wg mailing list
15:11:50 <simo> (fedora-server@)
15:12:00 <sgallagh> 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 <simo> err sorry (server@)
15:12:27 <sgallagh> So anyone who is interested in participating should absolutely do so, regardless of a position on the Working Group
15:12:31 <simo> sgallagh: can you recap the competency we selected jim for at the time (if we recorded them anywherE)
15:12:38 <simo> and see what are the one sof the candidates
15:12:41 <simo> just briefly
15:12:51 <simo> so we can get to a decision reasonably quickly ?
15:13:23 <sgallagh> Well, we selected him to represent the needs of downstream distributions
15:13:34 <nirik> 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 <simo> sgallagh: does anywone of the candidates in someway fulfill that role ?
15:14:17 <sgallagh> 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 <mizmo> i thoguht there were 2
15:14:43 <sgallagh> mizmo: stefw, danofsatx-dt, twoerner
15:14:43 <simo> sgallagh: +1, if you are interested enough to find out, it means you are following enough to be a good candidate :)
15:15:42 <nirik> sure, ok with me.
15:15:43 <stefw> fwiw, if there was an eager candidate willing to represent downstream distributions, i think that would be very valuable
15:15:53 <davidstrauss> 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 <davidstrauss> stefw: Is there any major downstream other than RHEL and its clones?
15:16:17 <simo> stefw: it would, but I do not thing we need to hold on to find the perfect representative
15:16:45 <sgallagh> I agree. Highly-motivated individuals should trump "filling a slot", IMO
15:16:54 <simo> 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 <stefw> davidstrauss, hmm, true, not that i know of
15:17:50 <twoerner> so.. what do you expect this candidate to provide exactly?
15:17:51 <sgallagh> I might suggest that stefw has a strong claim due to involvement with Fedora Atomic
15:18:05 <sgallagh> Which could be argued to be a downstream distro :)
15:18:18 <sgallagh> twoerner: It's a fuzzy question.
15:18:42 <sgallagh> 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 <mitr> 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 <sgallagh> And we're burning through our hour at an alarming pace.
15:20:31 <stefw> 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 <simo> sgallagh: stef already sent reason on server@
15:20:45 <simo> so I'd like to hear from twoerner
15:21:13 * sgallagh nods
15:22:46 <twoerner> 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 <twoerner> this was the short version ..
15:24:29 <simo> ok seem you 2 have similar goals and backgrounds
15:24:43 <sgallagh> 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 <simo> sgallagh: do we have anything from danofsatx-dt that we can put together to represent his stance ?
15:24:52 <sgallagh> (obviously he's not here to give a better accounting)
15:25:24 <twoerner> maybe you should then wait to decide this next time, when all are around
15:25:34 <sgallagh> That would probably be fair.
15:25:51 <simo> twoerner: I think you and danofsatx-dt should send a folow up message on the original thread on server@
15:26:03 <sgallagh> #topic Server WG Membership
15:26:03 <simo> then next week the remaining members can take a vote based on that
15:26:07 <sgallagh> (forgot to change the topic...)
15:26:10 <mitr> ... and perhaps explicitly allow for more candidates to step up as well?
15:26:16 <simo> mitr: indeed
15:26:31 <simo> mitr: but I guess, if you re not following server@ you are not already interested enough ?
15:27:06 <mitr> 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 <sgallagh> #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 <simo> mitr: it is not an absolute filter sure
15:27:41 <simo> but if we announce today I think a week time for anyone else to step up sound reasonable
15:27:48 <sgallagh> mitr: If you want to send out a wider announcement, be my guest
15:28:10 <sgallagh> I'm just wary of this getting unwieldy.
15:28:18 <sgallagh> Shall we move on to the API discussion?
15:28:44 <mitr> 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 <sgallagh> #info The candidacy period closes on May 6
15:29:16 <mitr> Thanks :)
15:29:23 <sgallagh> #topic Server Role API
15:29:59 <sgallagh> I've been speaking with twoerner a little about our high-level goals with the Server Role Infrastructure
15:30:26 <sgallagh> He has indicated that he'd be interested in writing the D-BUS service that we need.
15:30:55 <nirik> awesome!
15:30:57 <sgallagh> 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 <sgallagh> 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 <twoerner> ok :-)
15:32:35 <sgallagh> 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 <sgallagh> 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 <sgallagh> 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 <adamw> let me see if tflink'
15:34:50 <adamw> s available to see if there are any particular needs...
15:35:09 <stefw> 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 <davidstrauss> 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 <sgallagh> 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 <sgallagh> davidstrauss: I don't understand the question. Where do you see the discrepancy?
15:36:37 <mitr> 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 <sgallagh> 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 <davidstrauss> mitr: Oh, so the installer *won't* use the D-Bus APIs for roles.
15:37:29 <sgallagh> davidstrauss: The installer will use the D-BUS API to *configure* roles
15:37:48 <sgallagh> 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 <sgallagh> (hence the overlap with comps groups)
15:38:50 <sgallagh> davidstrauss: Does that answer your question or confuse it?
15:39:01 <davidstrauss> 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 <sgallagh> Let me get back to describing the API needs, which may help
15:39:49 <mitr> 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 <sgallagh> 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 <sgallagh> 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 <stefw> sgallagh, when anaconda completes?
15:41:22 <stefw> that's a pretty high bar
15:41:33 <davidstrauss> 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 <davidstrauss> So, we'd go GUI -> KS -> D-Bus -> Roles.
15:41:51 <sgallagh> Maybe I'm misunderstanding you
15:42:04 <davidstrauss> By GUI, I mean installer GUI.
15:42:15 <sgallagh> davidstrauss: At the moment, we are not talking about the GUI
15:42:19 <sgallagh> That's a future goal
15:42:40 <tflink> it sounds like this would be more than just installing packages?
15:42:41 <sgallagh> stefw: I'm modeling this after *your* realmd design :)
15:42:52 <sgallagh> That the resulting system should (when booted) be completely configured
15:42:59 <sgallagh> tflink: Much more, yes.
15:42:59 <stefw> sure, that's joining a domain
15:43:41 <davidstrauss> 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 <twoerner> davidstrauss: yes, I can see your point here..
15:44:47 <sgallagh> 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 <twoerner> ok, with integration into anaconda I can see a fit
15:45:27 <davidstrauss> sgallagh: This isn't about user complexity but rather implementation complexity.
15:45:36 <stefw> davidstrauss, exactly
15:45:58 <stefw> it's possible to make configuration happen on a non-running system. but it's not pretty.
15:46:03 <stefw> the implementation, that is
15:46:36 <davidstrauss> 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 <twoerner> do you have information in an anaconda plugin about package installations steps?
15:46:55 <stefw> 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 <sgallagh> stefw: Acknowledged. If that proves infeasible for F20, we'll drop it.
15:47:26 <stefw> s/anaconda implementation/anaconda configuration/
15:47:30 <nirik> 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 <sgallagh> 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 <sgallagh> For the moment, let's proceed assuming that we're only handling the firstboot config case
15:48:31 <twoerner> nirik: there could be a plugin like for example password or user/groups
15:48:51 <mitr> 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 <davidstrauss> 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 <sgallagh> 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 <sgallagh> It could get complicated quickly
15:50:05 <sgallagh> 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 <davidstrauss> sgallagh: We can move on, but I don't see how this is a bikeshed.
15:51:00 <sgallagh> 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 <sgallagh> The purpose of the discussion is to bring twoerner up to speed on what we want that API to do
15:51:53 <sgallagh> So the API needs to be able to manage a few obvious things:
15:52:10 <davidstrauss> sgallagh: Yes, and whether D-Bus is the primary and only way to access that API affects later implementation complexity.
15:52:12 <sgallagh> 1) Install all the necessary packages to support a role, if they are not already in place
15:52:59 <twoerner> 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 <sgallagh> davidstrauss: I'm not saying it's not an important question.
15:53:08 <sgallagh> I'm saying it's best saved for another day :)
15:53:26 <davidstrauss> sgallagh: Actually, you are. A bikeshed is inherently a question of limited impact.
15:53:36 <sgallagh> twoerner: Sorry, I'm not sure what you mean.
15:53:47 <sgallagh> davidstrauss: Then I chose an ill-advised term. Mea culpa.
15:53:54 <twoerner> sgallagh: ok.. for package installs we can use yum or packagekit
15:54:12 <davidstrauss> sgallagh: Okay, let's move on. :-)
15:54:13 <simo> or dnf :)
15:54:24 <twoerner> simo: yes, right.. I am sorry
15:54:30 <sgallagh> twoerner: In general, I'd prefer that we prefer the use of tools that are platform-independent
15:54:52 <sgallagh> Redundant sentence is redundant...
15:55:02 <mitr> 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 <twoerner> mitr: yum/pok was an example.. everyone knows about them :-)
15:55:55 <simo> twoerner: in general we'll go with whatever the platfrom considers the default, right now that's yum I guess
15:56:05 <mitr> twoerner: Same goes for firewalls, networking, systemd/init.d - look at the tech spec
15:56:53 <twoerner> ok
15:59:15 <adamw> so i wanted to ask quickly if anyone had looked at the 'test outline' i sent and had any thoughts
15:59:32 <sgallagh> https://fedoraproject.org/wiki/Server/Technical_Specification
15:59:32 <sgallagh> (for posterity)
15:59:34 <sgallagh> We're at the hour. Who is turning into a pumpkin vs. can stay a bit longer?
15:59:55 <mitr> adamw: read it, have no comments.
15:59:59 <adamw> 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 <adamw> mitr: rgr
16:00:23 <mitr> sgallagh: I can stay for ~30 minutes
16:00:31 <sgallagh> adamw:  I did read it on Friday and found it to be a sensible 30,000 foot view.
16:00:48 <adamw> 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 <adamw> sgallagh: thanks
16:01:43 <twoerner> I am sorry, but I have to leave now
16:01:47 <sgallagh> twoerner: Do I remember correctly that you had a hard stop?
16:01:50 <sgallagh> I guess "yes"
16:02:08 <sgallagh> twoerner: Let's continue this discussion in #fedora-server over the next couple days, then
16:02:13 <davidstrauss> I have to leave, but I'll check my IRC logs and the mailing list for any follow-ups.
16:02:16 <sgallagh> I don't necessarily want this to wait until next week
16:02:25 <tflink> are there any plans to automate some of the testing?
16:02:29 <twoerner> ok, thank you
16:02:42 * nirik was fine with the testing outline...
16:02:48 <adamw> 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 <davidstrauss> I browsed the testing outline. It looked fine to me, too.
16:03:07 <sgallagh> 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 <simo> I have to leave too, great discussion so far
16:03:08 <nirik> https://fedoraproject.org/wiki/User:Adamwill/Draft_Server_test_outline is the link btw.
16:03:13 <simo> se ey'all next week
16:03:33 <tflink> if the API does what I think it will, that could help
16:03:44 <adamw> 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 <tflink> my concern would also be about verificaiton/validation that the correct things were done
16:04:05 <adamw> tflink: or if you're talking specifically about the role API, sorry.
16:04:20 <tflink> i thought that was the topic of discussion, did I miss something?
16:04:26 <adamw> nope you're fine
16:04:35 <adamw> i thought we'd kinda hit open floor and started a new one, but apparently i was wrong
16:04:59 <sgallagh> #topic Proposed QA Test Plan
16:04:59 <sgallagh> tflink: Then it would probably be a good idea to help us plan it.
16:04:59 <sgallagh> (That may have come across snarky. Not my intent.)
16:05:22 <adamw> sgallagh: actually can we go back to the role API so tflink can ask about that specifically? sorry, my bad
16:05:35 <adamw> i think we're OK on the topic of the broader test outline/plan for now
16:05:36 <sgallagh> #undo
16:05:36 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x19836b90>
16:06:06 <sgallagh> adamw: You kind of hijacked the "who can stick around?" question :)
16:06:47 <adamw> sgallagh: there was three minutes of silence prior to that, and i asked my question right before you asked that ;)
16:07:07 <tflink> 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 <sgallagh> adamw: I think my network connection may be hiccuping today, because I keep getting messages in bursts :-/
16:07:50 <tflink> 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 <tflink> holistic -> run API calls, poke at the test instance to validate that it's behaving within expected parameters
16:08:24 <sgallagh> tflink: For Server Roles, I'd say "holistic"
16:08:49 <sgallagh> The assumption is that the Roles are being built atop other components that have received some reasonable amount of testing already.
16:08:58 <sgallagh> At this layer, we should be testing the integration
16:09:36 <tflink> out of curiosity, are the cloud images going to use this server api as well?
16:09:45 <sgallagh> 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 <tflink> 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 <sgallagh> tflink: They have a feature called "Adopt your cattle" that will allow a server image to *become* a Fedora Server instance
16:10:58 <sgallagh> So the standard instance will not have this API, but an "adopted" instance will
16:11:16 <adamw> 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 <sgallagh> adamw: Define "layer" in that sentence, please?
16:12:14 <adamw> sgallagh: sorry, vague. it's the "Roles are being built atop other components" bit - I'm thinking of the 'other components'
16:12:22 <tflink> how many roles can each server have?
16:12:26 <sgallagh> 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 <adamw> sgallagh: awesome, that's all that's relevant right now.
16:12:54 <sgallagh> tflink: Right now, we're only committed to "supporting" one Role on a server
16:13:24 <sgallagh> (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 <tflink> would each server have to be a VM or could it run in docker?
16:13:46 <sgallagh> tflink: That is an untested question
16:13:50 <tflink> if it's a VM, could the cloud images work or would it have to be installed from scratch?
16:13:59 <sgallagh> Right now we're assuming core Infrastructure, so a VM makes sense.
16:14:05 <tflink> ie, with anaconda (ks or whatever other method)
16:14:33 <sgallagh> tflink: I'd need to consult with the Cloud guys to answer that; I don't know offhand.
16:14:53 <sgallagh> All of our assumptions to date have involved a bare-metal or VM installation.
16:15:15 <sgallagh> With VM being loosely-defined (might be straight KVM, could theoretically be an IaaS instance)
16:15:54 <tflink> any guesses on how soon there might be test cases available to run?
16:16:17 <tflink> ~ a month, 2-3 months, 6 months, a year etc.
16:17:30 <sgallagh> tflink: No later than July 22nd? ;-)
16:17:30 <sgallagh> tflink: We haven't finished designing the API. It'll be hard to say until we get down to it
16:18:09 <tflink> sgallagh: ok, I wasn't looking for specifics. just wondering what kind of timeline it'd be looking at
16:18:20 <sgallagh> tflink: We're looking at "before Alpha freeze"
16:18:28 <sgallagh> Which is July 22nd
16:18:42 <sgallagh> So, damn well better be under three months.
16:19:19 <tflink> 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 <sgallagh> 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 <sgallagh> tflink: Still there?
16:26:37 <tflink> sgallagh: yeah, got distracted. sorry
16:26:54 <sgallagh> tflink: No problem
16:27:08 <sgallagh> Do you have other questions, or shall I close out the meeting and go have lunch? :)
16:27:22 <tflink> 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 <tflink> 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 <sgallagh> #topic Open Floor
16:28:57 <sgallagh> Anyone have anything for Open Floor today?
16:28:57 <tflink> it sounds reasonable and should be do-able. not sure about a timeline, but do-able
16:29:07 <sgallagh> tflink: Thank you
16:29:21 <tflink> sgallagh: np, thanks for answering my questions
16:29:57 <sgallagh> I'll close out the meeting in two minutes if there are no other topics.
16:32:17 <sgallagh> #endmeeting