16:02:57 #startmeeting Server Working Group Weekly Meeting (2014-12-16) 16:02:57 Meeting started Tue Dec 16 16:02:57 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:57 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:57 #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx 16:02:57 Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta 16:02:57 #topic roll call 16:03:40 does meetbot see identifiers, or only nicks? 16:03:52 danofsatx is on my laptop at home ;) 16:03:56 * mizmo here 16:04:03 danofsatx-work: nicks 16:04:09 #chair danofsatx-work 16:04:09 Current chairs: adamw danofsatx danofsatx-work mitr mizmo nirik sgallagh simo stefw tuanta 16:04:32 * danofsatx-work really needs to figure out znc...adds to long to-do list 16:04:33 .hellomynameis 16:04:34 kushal: (hellomynameis ) -- Return brief information about a Fedora Account System username. Useful for things like meeting roll call and calling attention to yourself. 16:04:38 .hellomynameis kushal 16:04:39 kushal: kushal 'Kushal Das' 16:04:48 .hello dmossor 16:04:49 danofsatx-work: dmossor 'Dan Mossor' 16:04:59 .hellomynameis 16:04:59 hanthana: (hellomynameis ) -- Return brief information about a Fedora Account System username. Useful for things like meeting roll call and calling attention to yourself. 16:05:16 hanthana: Use your FAS account name 16:05:21 .hellomynameis snavin 16:05:22 hanthana: snavin 'Danishka Navin' 16:05:27 Thanks :) 16:05:28 hanthana, I pressed enter too soon 16:05:36 .hello adamwill 16:05:37 adamw: adamwill 'Adam Williamson' 16:05:43 .hello sgallagh 16:05:44 sgallagh: sgallagh 'Stephen Gallagher' 16:06:01 kushal, :) 16:06:19 Nice to see you here, Danishka 16:06:25 .hello simo 16:06:26 simo: simo 'Simo Sorce' 16:06:55 mitr is still on PTO, I believe 16:07:09 I think tuanta said he would be absent as well 16:07:22 I recall that, also 16:07:53 #topic Agenda 16:08:04 #info Agenda Item: Database Server Role Design 16:08:41 Other items for the agenda? 16:08:55 This is likely to be our last meeting this year. I'll be around next Tuesday, but I expect many people will not. 16:09:27 yeah last meeting for me this year 16:09:28 Next Tuesday I will be driving back to SA from Galveston. 16:09:35 so HAppy New Year everyone! :) 16:09:53 And to you, simo ;) 16:10:17 we have a Fedora 21 launch tomorrow morning, during the Red Hat Challenge, Singapore 16:10:20 i'll probably try and get a proposal for defining/documenting server role capabilities and requirements outside of the release criteria done by end of year, but doesn't need much pre-discussion 16:10:30 adamw: Thanks 16:10:46 #info adamw will work on a proposal for defining/documenting server role capabilities and requirements outside of the release criteria 16:11:21 sgallagh: so I have been thinking about the Database Role thing a little 16:11:36 Hang on. 16:11:46 I'm still waiting to see if there are other topics 16:11:50 Then we'll discuss the DB 16:11:53 ah sorry 16:12:04 Anything else for the agenda? 16:12:30 /me assumes that to be a "no" 16:12:44 * hanthana thinking about Fedora Server Training Guide 16:12:54 hanthana: That would be very useful 16:13:03 hanthana: that's an awfully big project (IMHO) 16:13:26 Sure, nothing wrong with big projects 16:13:33 have to start somewhere 16:13:39 hanthana: Do you want to discuss it today? 16:13:48 the main issue is how to make sure it is easily reusable for new versions so it doesn't rot 16:13:50 Or take your initial thoughts to the mailing list and discuss it there? 16:14:20 simo: there's exactly one answer to that: have someone motivated enough to keep updating it. either of the usual forms of motivation. :P 16:14:20 this is my first time in fedora-server SIG meetings, but I don't know how do you guys continue 16:14:29 but I just wanted to pointed it 16:14:39 adamw: well one thing is that you tie the thing to a specific version 16:14:45 hanthana: Right now we're just deciding what things to discuss today. 16:14:53 so people don;t try to use the guide for 15 on 25 :) 16:14:53 ok 16:15:05 If you have nothing specific to discuss so far, let's talk about it on the mailing list first. 16:15:19 #topic Database Server Role Design 16:15:54 I sent out another round of things to consider and requirements to achieve 16:15:57 #link https://lists.fedoraproject.org/pipermail/server/2014-December/001694.html 16:16:09 simo: You had some thoughts? 16:16:21 (On this subject; I'm sure you have plenty of thoughts!) 16:18:22 OK, simo appears to have vanished. 16:18:27 I'm here 16:18:37 sorry, 4 convcersations at the same time is not healthy 16:18:46 ok so 16:18:47 So in general, I'm looking for the group to help settle on one of the approaches so I can start hacking on it 16:18:58 I have this feeling that what you described are really 2 roles 16:19:05 one a monolitic database on bare metal 16:19:15 and one a more dynamic role using containers 16:19:52 the thing I do not understand really well is why you link roles with databases (as in pg internal namespaces) 16:20:27 Well, they are definitely two implementations. And yeah, we could do it as separate roles, but I'd like to pick one to work on for F22. 16:20:28 I mean if you want to use separate servers .. you are probably also going to put them on different metal no ? 16:20:44 why would you install different postgres database instances on the same machine ? 16:21:05 simo: Plenty of people are doing that today, actually. The reason is that the databases may have different usage patterns 16:21:19 So they aren't loaded at the same time, and you can get better performance out of a single machine 16:21:28 s/loaded/under load/ 16:21:42 s/performance/value/ 16:21:55 (man, I can't convert thoughts to words well today) 16:22:53 Also, there are plenty of cases where the same beefy server is used to handle the DB for multiple applications 16:23:01 Fedora Infrastructure does this, for example 16:23:07 with multiple instances ? 16:23:10 nirik: ^^ I'm remembering correctly, yes? 16:23:18 simo: I think we've overloaded the term "instances" 16:23:34 They're not running separate postgres processes 16:23:34 by instances I mean separate postgres sql installations 16:23:54 and although it is possible to do so, it would probably not be very wise 16:24:02 That's not what I'm describing 16:24:08 (Except in the containerized case, of course) 16:24:18 unless you use additional features like cgroups and other isolatrion features to avoid one to interrfere with the other 16:24:39 then you are talking about namespaces 16:24:39 I feel like we're talking past one another 16:24:50 which are called "databases" within postgres 16:25:00 again "namespaces" are overloaded :) 16:25:03 yes 16:25:17 point is single postgres install and data and control process 16:25:22 vs multiple of them 16:25:28 that's the 1) and 2) examples in the email 16:25:37 and multiple ones would be 4) 16:25:44 * adamw nods intelligently 16:25:45 right 16:25:52 sorry, 3) and 4) 16:26:49 Anyway I think the issue is in you trying to deal with the datbases in postgres from rolekit 16:26:53 So as I noted in the email, I'd prefer to implement either 1) or 3), with a slight preference for 1) 16:27:00 How so? 16:27:21 I guess what I am saying 1) is fine 16:27:23 :) 16:27:31 2) is weird 16:27:43 3) is too much (not enough infrastructure for now) 16:28:01 4) nice but it is a different project altogether 16:28:16 /me nods 16:28:53 sgallagh: and of the list of requirements 16:29:11 I think our main concern should be to provide an easy way to: backup and create replicas 16:29:28 but I would de-emphasize the need to manage users/database via rtolekit 16:30:18 Would you mind explaining? We need to at minimum set up a user that can create other users, right? 16:30:22 it would be nice to be able to do something about that via a UI for sure, but I think rolekit should enable more the server life-cycle then trying to manage the single roles internal functionality 16:30:34 sgallagh: well you do not have interfaces in rolekit to manage freeipa users 16:30:41 (rightly so) 16:30:51 so I do not see why you would for the DB role 16:30:51 simo: No, but I *do* have an interface for creating the admin account during setup. 16:31:01 sgallagh: ok, but that is a special case 16:31:05 Which is the parallel I'm trying to draw here 16:31:09 you'd have the same for the DB role 16:31:21 so just an admin account makes sense, for the overall management 16:31:22 no different than the rollout of the DB - it has it's own "root" user 16:31:27 Right, and that would satisfy that requirement. I perhaps described it too generically 16:31:36 anything more IMO is a little bit out of what rolekit should do 16:31:48 That's a fair assessment. I'll narrow the phrasing of that 16:31:58 precisely, rolekit is to manage the server, not the application. 16:32:09 #info rolekit should support creating an admin account when creating the DB, but stay out of user management otherwise 16:33:11 danofsatx-work: TBH it would be really nice to have some generic interface to create stuff when deploying apps ... but generally most apps do that themselves as long as you provide a user with necessary privileges 16:33:22 Do we have a rough consensus on proceeding with approach 1) by the way? (Which was a single DB process running on the system, with rolekit instances maintaining the databases within it) 16:33:25 exactly 16:34:06 Does anyone here want to make a strong case in favor of one of the other approaches (or offer one I didn't think of)? 16:36:30 sgallagh: sounds the answer is no :) 16:36:42 OK, lazy consensus it is, then :) 16:36:46 (add a 'like' in there somewhere) 16:37:28 #agreed The Database Server Role will be built with a single local process, with rolekit instances maintaining the databases within it. (lazy consensus) 16:38:32 lazy consensus aka holidays consensus :) 16:38:39 I'd still like for us to provide an optional web-based management tool to go along with it, but the only one we've been able to find is the PHP one, and that doesn't sound like it has much support. 16:38:58 and doesn't really manage the bits we want to manage 16:40:35 simo: OK, there's a setup for an obvious question: "Which are the bits we want to manage?" :) 16:41:12 * adamw is OK with 1) 16:41:14 I think you want a UI to manage the users, the database the replication, etc... 16:41:18 low level tasks 16:41:31 A UI to make SQL queries is not particularly interesting 16:41:38 Sure, agreed 16:43:54 #info If we select a graphical tool for managing PostgreSQL, it must be able to manage user rights, replication and other system-level tasks 16:44:04 #info A UI for SQL queries is a non-requirement 16:45:12 * mclasen randomly throws in the expectation that that ui should be in cockpit 16:45:18 mclasen: +1 16:45:30 mclasen: I'm not sure we can commit to that. 16:45:35 It's a lot of new engineering work 16:45:39 or easily integrabl;e with it at any rate 16:45:47 I'd prefer to find a reasonable UI and allow cockpit to link to it 16:45:57 (Which is how we're handling the Domain Controller integration) 16:46:06 yes 16:46:17 i suppose it depends on what the meaning of the word 'in' is 16:46:20 as long as it is easy to go from one to the other I think it is fine 16:46:39 adamw: I think as long as transitioning is somewhat seamless it is "in" :) 16:46:56 * mclasen doesn't want to derail this meeting 16:47:07 #info Any UI we employ for the Database Server Role must be integrated with Cockpit in some reasonable way 16:47:11 but if you are serious about cockpit being 'the ui' for the server, there's really no choice... 16:47:26 mclasen: No, it's a perfectly reasonable statement (and one I had planned on, but not publicly articulated) 16:47:35 mclasen: does the freeipa integration meet your expectations ? 16:47:50 simo: There isn't a cockpit<->freeipa integration yet 16:47:53 simo: I admit that I haven't seen it 16:48:01 We (andreasn, stefw and I) just started on it this morning :) 16:48:01 sgallagh: well the plan 16:48:11 There should be some mockups by next week 16:48:19 I didn't mean it was "integrated" yet 16:48:59 but it is clear the freeipa UI is technically external to cockpit, with some linkage between the 2 16:50:18 It is *nice* that they share the PatternFly theming though 16:50:24 It'll make them feel much more cohesive 16:50:49 I doubt we'll get that for Postgres, unless someone from the Red Hat DB team decides to write a new UI ;-) 16:51:37 sgallagh: well yeah the patternfly theme thing was done precisely so multiple webapps have the same look&feel :) 16:52:10 simo: It's also much better than the old, sickly green 16:52:16 but I digress 16:52:35 OK, is there anything else we want to discuss on this topic? 16:52:44 I think I have a pretty good idea where to start, now 16:54:05 * danofsatx-work found a new topic 16:54:12 Let's hear it 16:54:18 (We have five minutes...) 16:54:20 cantas 16:54:32 *A wolf howls in the distance* 16:54:36 #topic Cantas 16:54:42 * adamw googles hastily 16:54:54 damnit, fashion companies 16:55:08 Ok, sgallagh has set up an open-sourced collaboration tracking system called cantas. 16:55:26 http://cantas-fedoraserver.rhcloud.com/ 16:55:57 A while ago, I went and set up Trello to track Fedora Server high-level goals 16:56:02 It looks a lot like the Trello stuff we started with, but it has a couple, well, issues. 16:56:07 I got plenty of feedback that using a closed-source tool was a bad idea 16:56:15 https://github.com/xychu/cantas ? 16:56:18 So I dug out and got Cantas set up 16:56:21 oh, that's a fork. 16:56:24 https://github.com/onepiecejs/nodejs-cantas 16:57:04 danofsatx-work: Mind #info-ing the issues? 16:57:14 I haven't played with it much yet. 16:57:17 * adamw doesn't see what's wrong with trac, and emacs, and would like you to get off his lawn. 16:57:19 I imported the Trello data and that's it 16:57:39 As noted in your email, the authentication does not work with openId. 16:57:51 anything we can hack on ourselves ? 16:57:55 #info Cantas authentication does not integrate with fedoauth (yet) 16:58:18 how do we log in, then? 16:58:29 Right, that one the upstream is going to work on. They want to see that added as well 16:58:32 adamw: sgallagh sent out a note you can use a google account 16:58:33 Google account. 16:58:38 oh blergh. 16:58:44 well I do not have one for work (I think) 16:59:04 #info Current authentication is only through Google or Kerberos. 16:59:21 #info Fedora Infrastructure does not support Kerberos 16:59:27 (yet?) 16:59:48 i'm sure they could get it up and running in a weekend with the freeipa role ;P 16:59:59 just what I was thinking, adamw 17:00:11 adamw: That's another topic and one that is under discussion, actually. 17:00:15 More on that another day 17:01:28 Anyhow, I filed https://github.com/onepiecejs/nodejs-cantas/issues/70 17:01:42 They proposed it for their next release (1.1) 17:01:42 I've also noticed that links do not work within the system. For example, links that point to http://cantas-fedoraserver.rhcloud.com/board/548f10f5cca1fb0000000002 don't actually go anywhere. 17:01:46 I don't know the schedule on that 17:01:55 danofsatx-work: Hmm? 17:01:57 it is supposed to redirect to http://cantas-fedoraserver.rhcloud.com/board/548f10f5cca1fb0000000002/Fedora_Server 17:02:14 which, as I was typing this, it finally did. 17:02:32 so, what was the topic? 17:02:35 just 'hey we have this thing'? 17:03:00 Well, it is currently populated with 7 tickets. 17:03:10 4 of which are assigned to you, adamw 17:03:38 make that 6...the vacant seat was filled ;) 17:03:56 eeeexcellent, expect them to be done right around the fourth of never. 17:04:04 :) 17:05:32 Just as a quick note; https://github.com/onepiecejs/nodejs-cantas/milestones indicates that 1.1 has a target date of Dec. 28th. 17:05:46 So if we're lucky, the auth situation will just be resolved and out of the way when we return 17:05:54 great 17:06:49 danofsatx-work: Please file a bug upstream about the links 17:07:02 Otherwise, let's take another look at this in January and see if it's usable in 1.1 17:07:14 We're over time, so if there's nothing urgent, I'm going to end the meeting. 17:07:20 /me sets the metaphorical fuse 17:08:22 bye bye\ 17:08:26 I have to run too 17:08:48 OK, thanks for joining, folks. 17:08:58 Happy Holidays and New Year. 17:09:01 #endmeeting