15:00:39 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-03-10)
15:00:39 <zodbot> Meeting started Tue Mar 10 15:00:39 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:39 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
15:00:39 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:00:39 <sgallagh> #topic roll call
15:00:49 <adamw> ahoy
15:00:59 * nirik is here, but also watching the alpha release, so might be distracted. ;)
15:01:17 <sgallagh> #info Alpha is released. Hurray!
15:01:44 * jsmith lurks while participating in the ARM meeting
15:02:06 <mitr> Hello
15:04:01 <adamw> not that it works, but let's paper over that hurriedly!
15:04:16 <sgallagh> adamw: Paper over what?
15:04:29 <adamw> all the bugs that require you to install from the repos to make stuff work :P
15:04:53 <sgallagh> s/all/both/
15:05:10 <simo> .hello simo
15:05:10 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
15:05:27 <sgallagh> Yeah, the situation with the Domain Controller role in Alpha is sub-optimal.
15:05:41 <sgallagh> Anyway...
15:05:46 <sgallagh> #topic Agenda
15:05:55 <sgallagh> #info Agenda Item: Fedora 22 Beta Planning
15:06:06 <sgallagh> #info Agenda Item: GSoC Involvement
15:06:14 <sgallagh> Any other items for the agenda?
15:06:53 <sgallagh> *crickets*
15:07:06 <sgallagh> ok
15:07:14 <adamw> db role?
15:07:14 <sgallagh> #topic Fedora 22 Beta Planning
15:07:20 <adamw> er, db role criteria and  test cases
15:07:22 <sgallagh> #undo
15:07:22 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x4cf8b590>
15:07:34 <sgallagh> #info Agenda Item: DB Role Criteria and Test Cases
15:07:41 <sgallagh> #topic Fedora 22 Beta Planning
15:08:29 <sgallagh> So we need to figure out what needs doing before we feel comfortable calling it Beta-ready.
15:08:59 <sgallagh> A reminder is that technically, it's expected that all features are fundamentally finished at Beta and that only bug-fixes should go in after that.
15:09:08 <sgallagh> We should strive to honor this.
15:09:49 * nirik nods
15:09:59 <sgallagh> From the engineering side, this is pretty much limited to rolekit and Cockpit finishing touches.
15:10:26 <sgallagh> For rolekit, we need to finish the DB role. It's deployable (and arguably deplorable), but cannot be decommissioned at this time.
15:10:38 <sgallagh> #info Rolekit Database Role needs to support decommissioning.
15:11:09 <sgallagh> Ideally, it also needs to support creation of multiple DB instances, but we may end up deferring that to F23 due to resource limitations.
15:11:55 <sgallagh> Is that acceptable, or do we want to block on that?
15:12:07 <adamw> there is a proposal on the list for the requirements which i didn't get around to replying to yet...
15:12:22 <sgallagh> Yes, let's cover that in detail in the other agenda item
15:12:26 <adamw> not sure i have a good feel for the multiple instance question
15:12:49 <sgallagh> adamw: Sorry, could you clarify?
15:13:22 <nirik> I think it would be good, but I don't think we should block on it...
15:13:54 <mitr> sgallagh: A DB instance can have multiple databases (in the SQL sense), right?
15:14:05 <adamw> sgallagh: i'm saying i don't have an opinion. :)
15:14:10 <sgallagh> mitr: Yes and no
15:14:18 <sgallagh> mitr: PostgreSQL is fully capable of it.
15:14:30 <sgallagh> And we want to be able to create those databases via the rolekit API
15:14:52 <sgallagh> Right now we can only create one.
15:15:09 <sgallagh> (via rolekit)
15:15:21 <sgallagh> We can create others using traditional tools without involving rolekit.
15:15:24 <mitr> Then I suppose I will follow adamw to the “no opinion” camp
15:15:43 <sgallagh> "No opinion" translates to "non-blocking" in my interpretation.
15:15:57 <mitr> sure
15:16:07 <adamw> yeah, on the one hand it's not like you can't use it, on the other hand it sounds like it's hard to use it for anything practical without going outside the role framework.
15:16:28 <sgallagh> adamw: Define "it" please?
15:16:31 <adamw> the role.
15:17:01 <sgallagh> Well, no. We are still covering the "one [virtual] machine == one database instance" case
15:17:05 <sgallagh> And that reasonably well.
15:17:07 <adamw> you can deploy the role and then do useful db stuff, but you're going to have to know how to create extra DBs manually. still, i suppose the role is still saving you the not-inconsiderable pain of getting f**king pgsql setup out of the box.
15:17:15 <adamw> oh, true.
15:17:36 <sgallagh> Multiple instantiation of DBs was more common prior to the advent of virtualization.
15:17:46 <sgallagh> Nowadays, many deployments isolate them for security
15:18:20 <adamw> yeah, i was mostly figuring on the 'big complicated central server' deployment case.
15:18:47 <sgallagh> Yeah, the Fedora Infra case is not well-served by the current implementation
15:19:09 <nirik> yeah, but it's not like we are set on the current setup at all we have. ;)
15:19:36 <nirik> it's just the way it is now, and change is hard.
15:19:52 <sgallagh> So, I think I'm hearing that we should try to support multiple instances, but it's not blocking. Agreed?
15:19:58 <nirik> +1
15:20:14 <mitr> +1
15:20:28 <jsmith> +1 from me
15:20:55 <sgallagh> #info Non-blocking: Rolekit Database Role support for multiple DB instances.
15:21:25 <sgallagh> For Cockpit, I attended their public meeting yesterday and discussed the F22 Beta target, so I'll just report out.
15:21:47 <simo> +1
15:21:48 <sgallagh> #info Cockpit will have branding reintroduced to the Fedora builds in time for Beta Freeze
15:22:18 <sgallagh> #info Cockpit is aiming upstream to achieve API stability as of Fedora 22 Beta (and further releases)
15:22:20 <adamw> +1
15:22:29 <adamw> whoopsie, bit late.
15:22:47 <sgallagh> This should mean that F22 will be able to get upstream updates, unlike F21.
15:23:16 <sgallagh> #info Cockpit will make PCP support optional before F22 Beta, because it's not finished.
15:23:27 <simo> sgallagh: you mean updates from upstream? or you mean wecan package updates as they won't break stuff ?
15:23:46 <sgallagh> simo: We'll be able to package updates as they are released upstream.
15:23:55 <sgallagh> Because they'll maintain backwards compatibility.
15:24:35 <sgallagh> adamw: Would you like to raise any statements about QA needs between now and Beta Freeze? (Such as pleas for early testing)
15:24:46 <adamw> why, it's funny you should ask! ;)
15:25:09 <adamw> ideally we should run all the beta tests on alpha (...plus the fixes needed to make freeipa actually run, in freeipa's case)
15:25:17 <adamw> for the db role this would of course be contingent on *having some tests*.
15:25:22 <adamw> so, we also kinda need that.
15:25:32 <adamw> (as i type this, why do i get the sinking feeling i'm going to be writing more test cases?)
15:26:19 <adamw> so basically it'd be good to fill in all the Beta tests (and, really, all the tests) at https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_RC3_Server so we know what we're blocking on well ahead of time
15:26:19 <sgallagh> Right, I think it would be beneficial to set a goal for, say, next meeting that the Beta criteria need to have been tested with Alpha+the tomcat and SELinux update.
15:26:55 <sgallagh> I think that's a reasonable target goal, assuming we approve the DB role cases later in the meeting.
15:27:00 <adamw> we will get nightlies between here and Beta TC1, but we probably won't have results pages for them because, er, all my ridiculous tools have assumptions that we only do nightlies before Alpha.
15:27:09 <sgallagh> heh
15:27:28 <sgallagh> adamw: Did we get a nightly since approving Alpha?
15:27:36 <sgallagh> If so, we should use that one for the early Beta testing
15:28:04 <nirik> do we do the server iso nightly?
15:28:04 <adamw> sgallagh: yeah, but as the selinux fix was only pushed yesterday that won't have been in the 03-09 one.
15:28:07 * nirik didn't think so?
15:28:13 <adamw> nirik: no, but the nightly boot.iso is close enough for government work.
15:28:18 <nirik> alrighty
15:28:41 <sgallagh> ok, so we'll hope that tonight's nightly will work and focus our efforts there, yes?
15:28:51 <adamw> we have an 03-10 nightly and it has selinux 166
15:29:09 <adamw> although of course when you use a nightly it just installs the latest from the repos. as does using the alpha netinst.
15:29:10 <nirik> todays should have it.
15:29:17 <sgallagh> right
15:29:21 <adamw> so aside from issues in the installer itself, using a nightly vs. using alpha netinst is pretty close for the deployed system.
15:29:33 <sgallagh> /me reminds folks that we probably want to disable the updates-testing repo while doing validation testing
15:30:07 <sgallagh> (or better, try it once without it enabled and once with, to see if any new updates break crap)
15:30:29 <nirik> indeed.
15:30:40 <adamw> soooo anyhoo - use the Alpha Server netinst image, or grab a nightly. to find nightlies: fedfind images --release 22 --date YYYYMMDD --type boot
15:30:50 <sgallagh> #info Please run through the Beta release criteria for Fedora Server 22 by next week's meeting (2015-03-17)
15:30:53 <adamw> sgallagh: yeah, that's a good call
15:31:12 <adamw> i'd say run with it enabled (the default) first and if you find any stuff busted try without it and see if that works, but either way around.
15:31:35 <sgallagh> Good point.
15:31:59 <sgallagh> #info use the Alpha Server netinst image, or grab a nightly. to find nightlies: fedfind images --release 22 --date YYYYMMDD --type boot
15:32:13 <adamw> (/me should really provide some way to just use today's date from the commandline...)
15:32:33 <sgallagh> adamw: `date +YYYYMMdd` :)
15:32:38 <sgallagh> Anyway.
15:32:42 <jsmith> adamw: --today :-)
15:33:00 <nirik> just assume today? ;)
15:33:01 <sgallagh> Anything else for F22 Beta, or shall we move on?
15:33:03 <adamw> so, turn sgallagh's answer into python and have jsmith's answer trigger it and that's what i meant. :P
15:33:10 <adamw> nirik: can't, --release 22 means '22 Stable'.
15:33:20 <adamw> er, 22 Final, whatever.
15:33:39 <adamw> anyhoo ,sidetrack
15:33:57 <adamw> sgallagh: did you do a action / info / whatever for 'review the DB role requirements and write test cases'?
15:34:19 <sgallagh> adamw: No, because that's an upcoming #topic :)
15:34:26 <adamw> sigh, more coffee required
15:34:50 <sgallagh> I'll skip to that one and come back to GSoC
15:35:06 <sgallagh> #topic DB Role Criteria and Test Cases
15:35:24 <sgallagh> #link https://fedoraproject.org/wiki/User:Dmossor/DBRoleReqs
15:36:12 <sgallagh> So, one open question that I'd meant to discuss with the Workstation group (and failed to):
15:36:32 <sgallagh> Do we want to make the use of pgadmin3 to manage the resulting DB role a criterion?
15:37:01 <sgallagh> It's a desktop app, but it's pretty much the de-facto standard in PG admin clients
15:37:31 <sgallagh> If we want to make this official, we probably need to do some work to make it available in GNOME Software.
15:37:48 <mitr> sgallagh: A criterion for the Workstation product, or for server?
15:37:49 <nirik> is that a gui?
15:38:06 <nirik> so it is.
15:38:07 <jsmith> nirik: Yes, it's a GUI program
15:38:25 <sgallagh> mitr: For Server, a criterion that it must accept connections from pgadmin3 and respect basic functionality.
15:38:29 <adamw> what's the data behind it being the 'de-facto standard in PG admin clients'?
15:38:47 <adamw> and do you mean 'people who use a client tend to use pgadmin3' or do you mean 'pgsql server admins tend to use pgadmin3'?
15:38:48 <sgallagh> (I'm not even remotely suggesting that we create a full test plan there)
15:39:16 <mitr> sgallagh: A criterion for Server would make sense to me; I don’t see how availability in GNOME Software follows from that, though that would of course be useful.
15:39:21 <sgallagh> adamw: It's the only one I can find on Google that anyone is using, but that one gets hit a LOT and on many Q&A sites.
15:39:53 * nirik hasn't used it.
15:40:48 <sgallagh> Proposal: table this and consider it in the F23 timeframe.
15:40:59 <adamw> so again i'm not sure i have a good enough feeling. would we actually be able to hold up a Fedora release because you couldn't talk to pgsql with a GUI client?
15:41:00 <nirik> I'd be worried about us adding too much critera around it... since we don't know much about it and don't maintain it, etc.
15:41:00 <sgallagh> I was mostly thinking that it might be easier to write test cases against it
15:41:09 <adamw> would we ever hit a case where it couldn't be fixed with an update?
15:41:15 <sgallagh> unlikely
15:41:31 <adamw> we can have test cases for things that aren't criteria requirements.
15:41:36 <adamw> that's what the test cases marked 'Optional' are.
15:41:42 <sgallagh> Right
15:41:42 <nirik> I suppose this could be a critera/test case against the db role thats more generic?
15:42:03 <nirik> ie, 'must allow a remote management tool, like pgadmin3 to connect and see the database'
15:42:03 <sgallagh> "3. Must allow external software to edit the DB"
15:42:14 <sgallagh> nirik: I'm okay with that as well
15:42:58 <nirik> seems to have a problem in rawhide right now: [1]    27674 abort (core dumped)  pgadmin3
15:43:37 <nirik> it's c++ abi changes. :) I'll fix it.
15:43:41 <sgallagh> hahaha
15:44:10 <sgallagh> OK, so remaining questions: are we happy (enough) with the proposed requirements?
15:44:20 <sgallagh> Do we want to adjust them?
15:44:40 <sgallagh> They're pretty generic right now; should we try to make them more specific or leave that to the test cases?
15:45:44 <mitr> Should any kind of IPA integration be in there?
15:46:25 <sgallagh> mitr: PostgreSQL doesn't support LDAP or KRB5 auth as far as I've been able to discover
15:46:29 <mitr> (And is having database client service accounts in IPA even a desirable long-term feature?)
15:46:41 <sgallagh> I'm not sure what other integration is useful
15:46:41 <mitr> That’s that then.
15:46:41 * adamw has another quick read through
15:47:08 <mitr> sgallagh: file:///usr/share/doc/postgresql/html/auth-methods.html#GSSAPI-AUTH ?
15:47:18 <sgallagh> I'd like very much to see GSSAPI support added. Maybe simo would like to mentor a GSoC student to work on that? :)
15:48:01 <mitr> http://www.postgresql.org/docs/9.4/static/auth-methods.html#GSSAPI-AUTH rather
15:48:08 <sgallagh> mitr: Hmm, maybe I need to take another look at that.
15:48:36 * danofsatx is here finally
15:48:44 <danofsatx> sorry folks, really late start today
15:48:44 <sgallagh> I'm fairly confident I won't have time to implement it before Beta though
15:48:55 <sgallagh> And as I'm currently the only person working on rolekit...
15:48:59 <adamw> it seems a bit odd that " The Database must be capable of serving requests through port 5432. " is a requirement not a core requirement...
15:49:16 <simo> sgallagh: I can mentor
15:49:18 <sgallagh> danofsatx: ^^
15:49:27 <sgallagh> Why was that in the "Requirements" section?
15:49:50 <sgallagh> simo: It may be that I was mistaken and some GSSAPI support is already there.
15:49:54 <adamw> i think the reqs were mostly modeled on the domain controller reqs, where the situation is a bit different because we kinda decided client authentication is the absolute fundamental requirement of freeipa. (though i still think the domain controller reqs are a bit weird and clashing in style and keep meaning to proposed revisions Real Soon Now.)
15:49:55 <sgallagh> I need to investigate.
15:50:13 <danofsatx> hmmm.....I didn't quite catch tht one. junland produced that bullet, and I just ran with it
15:50:18 <simo> sgallagh: there is some but it is bad
15:50:26 <simo> sgallagh: it does only auth and not secure channel
15:50:29 <sgallagh> Ahh
15:50:31 <simo> it's stupid really
15:50:47 <sgallagh> simo: In that case, you'd be willing to mentor a student to enhance that if we found one?
15:50:52 <sgallagh> That would be really nice for F23
15:52:04 <simo> sgallagh: I could, but I suspect the main issue is that to do it properly you have to mneddle with postregql tcp handling code, so it may be hard
15:52:10 <danofsatx> I was assuming he was intending to require that the DB accept remote connections, and that was the default communications port for postgresql
15:52:19 <simo> you basically would ahve to implement something like START TLS
15:52:19 <adamw> ah, hum. i see
15:52:50 * danofsatx looks into postgres reql quick like
15:52:55 <adamw> and " Multiple clients must be able connect to the DB Server " is kind of intended to cover local socket connections at alpha
15:53:14 <adamw> or are we using tcp/ip connections ootb? /me hasn't actually looked at the config yet.
15:53:39 <sgallagh> adamw: We have TCP/IP out of the role-created box
15:53:54 <adamw> with remote access or no?
15:54:09 <sgallagh> Remotely as well
15:54:15 <adamw> it's hard to feel out ahead of actual testing what we really want from the roles :/
15:54:21 <sgallagh> Though realize we're talking about *criteria*, not implementation.
15:54:30 <sgallagh> It's *supposed* to all work out of the box.
15:54:39 <sgallagh> This is defining when it's a blocker if it doesn't :)
15:55:20 <adamw> sure. but you need to know what the implementation is to know which bits of it to require...
15:55:37 <adamw> so we're kinda running short on time but i think the requirements might need a few tweaks
15:55:40 <adamw> i'll try and get a mail to the list today
15:55:51 <sgallagh> adamw: Thanks
15:56:04 * adamw uses the fork model :)
15:56:09 <sgallagh> #action adamw to send email today about DB role use cases
15:56:22 <sgallagh> #topic GSoC Involvement
15:56:22 <danofsatx> http://www.postgresql.org/docs/9.4/static/auth-methods.html
15:56:45 <sgallagh> So, I have one Server SIG-related opening listed: support for the Domain Controller Role in Cockpit.
15:56:59 <sgallagh> Do we have other items in our wheelhouse that we might want to solicit candidates for?
15:57:26 <sgallagh> Student application period opens on Monday, so we need to have our list ready ASAP
15:57:32 <danofsatx> might be a bit much for GSoC, but a definitive GUI interface for postgres would be nice ;)
15:57:47 <sgallagh> danofsatx: That might be a bit much for a graduate degree thesis :)
15:59:16 <sgallagh> simo: So you think the GSSAPI/PGSQL thing is out of scope?
16:00:02 <mitr> I would expect that server admins need UI at the level of databases and access permissions only; delving deeper into table contents is application development territory
16:00:43 <simo> sgallagh: no, I am just saying it may be hard to get it upstream, but it is worth a shot IMO
16:00:57 <sgallagh> simo: OK, I'll add it to the list
16:01:26 <sgallagh> Anything else? We're out of time for this week
16:01:52 <sgallagh> /me lights the fuse.
16:02:01 <sgallagh> 3...
16:02:05 * danofsatx runs
16:02:19 <sgallagh> 2...
16:02:25 * danofsatx trips adamw
16:02:39 <sgallagh> 1...
16:03:02 <sgallagh> #endmeeting