20:01:23 #startmeeting tc 20:01:24 Meeting started Tue Feb 14 20:01:23 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:27 The meeting name has been set to 'tc' 20:01:28 * edleafe pulls up a chair 20:01:29 I just want to say you guys are the worst valentine's date I've ever had. 20:01:39 no offense, though 20:01:41 :D 20:01:49 * mordred slyly puts his arm around flaper87's shoulder 20:01:54 flaper87: I think I had other TC meetings on Valentine's day Tuesday, so maybe not 20:02:03 * dhellmann sprinkles rose petals at flaper87's feet 20:02:05 Our agenda for today is at: 20:02:09 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:18 #topic Update projects.yaml with results of the PTL elections 20:02:19 LOL 20:02:23 * flaper87 stfu 20:02:25 #link https://review.openstack.org/430481 20:02:33 Looks like I can approve this now unless someone screams 20:02:48 ttx: go for it 20:02:53 done 20:02:57 * stevemar is happy to be off that list hehe 20:03:16 stevemar: offciially relieved from that particular duty 20:03:20 #topic PTG organization 20:03:24 stevemar: +1 :) 20:03:28 So we have the PTG coming next week, was wondering if you had questions 20:03:30 * mordred hands stevemar a pie 20:03:31 Random bits of information: 20:03:37 mordred: better be apple 20:03:37 We'll be communicating / synchronizing via #openstack-ptg, so join that 20:03:44 And we have a number of reservable rooms for inter-project discussions which you can book via 20:03:44 o/ 20:03:48 #link https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms 20:03:56 We'll do 9am - 5pm every day (although the rooms will stay accessible until 6pm) 20:04:00 Lunch will be served between noon and 1:30pm 20:04:10 it's ok to cut it short 20:04:22 There will be a happy hour on Tuesday 5-7pm, and a feedback fishbowl session at 5pm on Thursday 20:04:34 Otherwise you should self-organize 20:04:53 We should have some email today(?) with pointers to group-friendly restaurants in the area 20:05:02 in case you want to set up dinners 20:05:05 lbragstad: ^ 20:05:12 sounds fantastic 20:05:18 Other questions ? 20:05:27 5pm? I scheduled sessions until 6 20:05:33 EmilienM: it's fine 20:05:36 EmilienM: rooms available till 6 20:05:47 we don't want to miss parties though :-P 20:05:53 The bar should not be empty yet 20:05:55 EmilienM: then stop working 20:05:57 :P 20:05:59 lol 20:06:01 is there a separate lunch location, and if so then is it still allowed to bring lunch back to the team rooms instead? 20:06:11 EmilienM: it's on Tuesday, your sessions for TripleO start on Wed ? 20:06:20 ttx: right 20:06:35 I'll make sure flaper87 doesn't go at bar before 20:06:35 fungi: no idea 20:06:43 probably ok 20:06:45 * fungi will "wing it" 20:06:47 EmilienM: move your last session to the bar 20:06:57 edleafe: that's the spirit 20:07:25 ok, feel free to hit me or diablo_rojo if you have questions, we'll do our best to extract knowledge from the events team and answer 20:07:28 apparently there's a bar in the same hotel, so easy to move any session you like to it probably ;) 20:07:31 we'll be releasing final ocata in our case, we'll need strong drinks 20:07:58 ttx: thanks of all the infos! 20:08:00 #topic Document current base services 20:08:09 #link https://review.openstack.org/430965 20:08:20 This is introducing the concept of "base services" 20:08:30 which are things that OpenStack projects can reasonably assume will be present in any OpenStack installation and may therefore freely leverage the features of 20:08:38 It's not really a new concept, but we never actually listed the things that are OK to assume will be present 20:08:45 Currently: a database, a message queue and Keystone 20:09:02 which kind of made it harder for us from having discussions on how to grow or limit that set 20:09:12 So I think this will really help us, by providing a base framework for future necessary debates 20:09:20 (debates like ending the postgres support, or adding a DLM, or being able to assume Barbican will be present) 20:09:28 Questions, comments ? 20:10:02 ttx: well this doesn't really effect the postgres discussion. You said an oslo.db compatible db in there 20:10:10 postgres fits that 20:10:26 I just had one comment on it but not a blocker for sure 20:10:26 mtreinish: it doesn't affect indeed, describves status quo 20:10:41 flaper87: yeah, we can rename after the merge if necessary 20:11:06 feels like we have enough votes to pass it, then we'll evolve from there 20:11:08 i think the wording is loose enough around the DB that if we can approve that aside from the postgres discussion 20:11:15 ttx: yup, voted 20:11:28 ttx: I can do the follow-up one if you want, since I brought it up 20:11:39 * dims_ many apologies for showing up tardy 20:11:53 ok approved 20:12:02 the intent seems to be (with databases for example) that you only rely on features of the rdbms exposed through oslo.db, which at least allows us to tune for a common featureset between multiple backends 20:12:08 flaper87: sure -- dtroyer's proposed title sounds good 20:12:51 fungi: yes. If we want to not support postgres anymore, we can eiether block it at oslo.db level or replace that oslo.db statement by something stronger 20:13:17 though the way it's written, i could see people interpreting it such that you can depend on the advanced features of a single database which happens to be a supported oslo.db backend, even if you're not using oslo.db to leverage it (and so may use features not provided by oslo.db) 20:13:41 We'll get back to that later in the meeting when we cover postgresql 20:13:49 wfm 20:13:54 It's a living doc so feel free to propose updates :) 20:14:05 I think it accurately describes the current situation 20:14:11 #topic Glance: Changing response status code. What's the best path forward? 20:14:13 agree 20:14:15 ++ 20:14:17 #link https://review.openstack.org/#/c/420038/ 20:14:19 #link https://review.openstack.org/#/c/425487/ 20:14:22 flaper87, rosmaita: o/ 20:14:25 o/ 20:14:33 o/ 20:14:37 So, I've been talking with rosmaita about this and digging into the topic 20:14:45 I'll let rosmaita do all the talking, though 20:14:49 ok 20:15:00 Glance has proposed to fix a bug, an API call that returns a 200 whereas a 204 (No Content) is more appropriate, by changing the software to return the correct code. Ordinarily, this would be a questionable move, but we've argued that in this particular case because the documents have always stated this call returns a 204 and all the other related calls in fact return 204s. However, representatives of the QA team saw the change, and did not li 20:15:18 The Glance team consulted the API-WG Guidelines which state that this kind of thing is generally not acceptable, but the details of this case seemed to make it an exception. So the Glance team met with the API-WG to see what they thought, and they agreed this was a legitimate exception. Unfortunately, the QA team merged a tempest test that covers this call and expects a 200 in the response, before the discussion was resolved, and now we can't 20:15:39 We're bringing this up at the TC because we'd like a solution to this particular situation and we feel the need of a non biased body to provide guidance. This issue is also related to the ongoing discussion about the proposed api-compatability tag 20:15:47 * rosmaita takes a deep breath 20:15:49 rosmaita: I think your IRC client cut some of the pastes :P 20:16:46 shoot, i'm using irssi, but looks ok to me 20:16:55 Wearing my API-WG hat, we felt that it was indeed a reasonable change 20:17:04 is that tempest test part of what's used for defcore? 20:17:10 did not li.. 20:17:14 ke it ? 20:17:17 I believe making the changes, in this case, are improvements to the user 20:17:18 don't think so, it's metadefs 20:17:24 ok, good 20:17:33 The return code doesn't change the meaning. 200->204 is not the same as, say, 400-404 20:17:35 Based on how the discussions on this topic have evolved and the parties involved, I think I'd be good with this change happening. The API-WG was part of the discussion and it's not part of defcore 20:17:39 I'm curious to understand why the QA team thought adding that test on their own was appropriate. 20:18:06 well, they were expanding test coverage of glance to metadefs 20:18:12 actually, they reported the bug 20:18:12 are the tempest reviewers objecting to a change that will accept either of 200 or 204 for that call? 20:18:22 OK, but this change was in progress, right? 20:18:41 dhellmann: yes 20:18:41 I guess I'm trying to understand how this turned into a blocking situation instead of an opportunity for a conversation. 20:18:58 fungi: https://review.openstack.org/#/c/432611/ 20:19:01 sounds to me like the process is working ... the QA team found a bug where the code didn't do what the docs say it should and the dev team fixed it 20:19:17 yes, the disagreement is on how the fix should go 20:19:23 And why it had to come to the TC for a decision. Not that asking us to make one is wrong, just we'd like I think to avoid having to do that when possible. 20:19:25 fungi: normally that's not how things like this are handled. But they can be in edge cases 20:19:36 tempest likes the api to work the same on all releases 20:19:56 so does mordred 20:20:01 dhellmann: Glance did come to the API-WG for a discussion, but our conclusions didn't seem to sway QA 20:20:10 mtreinish: yeah, looks like oomichi has objected to 432611 on the grounds that tempest is used for defcore (though sounds like the test in question actually isn't) 20:20:20 it sounds like the argument for changing the response code is the new value is more accurate and more consistent, and the argument for not changing it is that we don't change response codes? 20:20:22 _but_ - also sometimes we find things that are just bugs - and low-impact bugs too 20:20:24 dhellmann: I think the current issue is that the discussion has hit a deadlock 20:20:34 mostly the issue here stems from a lot of precedence that changes like this need to be handled in a way that things don't change between releases without a versioning mechanism of some sort 20:20:37 flaper87: bingo 20:20:38 and escalation was the only solution 20:20:40 flaper87 : right, and I would like to know why we have two teams deadlocked 20:21:24 we can deal with the immediate issue of deciding how to proceed, but we should also deal with the issue of getting deadlocked in the first place 20:21:30 dhellmann: I suspect one of the dimensions of this issue is that the tempest tests live in tempest in that case 20:21:31 dhellmann: one reason is that the API-WG is simply advisory, whereas the TC has a little more power to resolve such issues 20:21:52 I mean - I think the urge to be conservative here is a good one, and I honestly would not mind the process for things like this be to get a TC greenlight - just so that we don't slippery slope back into the world of making brekaing changes across releases 20:21:54 i.e. the QA team has authority on one part of the fix and Glance on the other 20:21:57 fungi: I think oomichi is referring to the nature of tempest being used against any cloud and using defcore as an example 20:22:14 but I could be wrong 20:22:20 guess folks who are relying on current behavior will break. folks who read the docs will just scratch their heads. so we lean towards the not-breaking-people direction? 20:22:21 so if they don't agree on the fix and nobody yields... escalation is the right process 20:22:39 i would have hoped to see rosmaita follow up to the -1 on 432611 with appropriate counterarguments rather than just assuming the opinion of any reviewer is immutable, but maybe there was other subsequent discussion which isn't reflected in that review? 20:22:46 the only way to avoid that in the future is to put all tempest tests in project-specific repo but we rules the other way recently 20:22:54 dims_: they'll break in theory. in practice, the chances someone has code that is explicitly checking for 200 vs 204 and making different actions based on it is none 20:22:57 In case anyone wants my POV on this: https://blog.leafe.com/api-longevity/ 20:22:57 ruled* 20:22:59 ttx: only for defcore tests 20:23:07 fungi: I think that's the cae, although probably not ideal 20:23:11 dhellmann: apparently for that one as well 20:23:22 because theonly different action you'd make from 200 to 204 is to not look at the payload - but there is no payload anyway,so there is literally no legitimate consumption difference 20:23:23 that policy only applies to tests intended for use by defcore 20:23:24 well, my point is the test could just be moved 20:23:26 fungi: see the other patches ttx linked for the arguments about this 20:23:27 though that doesn't solve the collaboration problem 20:23:49 mordred: well unless you have a poorly written client that assumes a specific response code to measure success 20:23:59 dhellmann: you are correct in pointing out that there are two problems here 20:24:00 mordred: in the past we've asserted that's a thing we've cared about 20:24:01 mordred: do we anticipate someone looking at the specific error code at all? 20:24:02 mordred: yeh, I think it's mostly the difference of opinion of "is not really broken, why fix this" 20:24:36 dhellmann: people do stuff all the time where they just == KNOWN_GOOD_THING 20:24:39 mordred: ++ 20:25:12 so yes, (1) how do we solve that disagreement and (2) how do we avoid similar situations in the future 20:25:19 yah. it's a jugement call. I'm saying I come down fairly strongly on "just fix the bug" - because someone who wrote a client that is _specifically_ coding against the 200 and not the 204 coded to a specific success code that is in contradiction to the api docs so holy crap what were they doing? 20:25:21 right, we've got 2 camps here. QA) don't change things unless it's really hurting people. 20:25:22 also, KNOWN_GOOD_THING is often defined by what it does, not what the docs say 20:25:37 mordred : they were coding against how a cloud they use actually works? 20:25:38 Glance) lets make this more compliant 20:25:41 rosmaita: yeah, skimmed and it looks like the pushback from oomichi was that there should be thorough discussion before changing that behavior. now that it's been discussed is he still unwilling to budge? 20:25:43 right dtroyer 20:26:04 and seems like the TC call is really where we want that slider to be 20:26:15 I do know if i was writing a client for something, and the docs disagreed with the actual response, I would just throw my hands up, and code it to what worked 20:26:20 fungi: yes, but as you can see, both sides of this have support 20:26:20 sdague: and I think it's appropriate for the TC to make that call, tbh 20:26:26 mugsie : right 20:26:38 mugsie: right. but this is a different _success_ code - coding against a specific code is crazy in teh first place 20:26:40 because I think that after the recommendation, the teams will most likely run with it 20:26:52 mugsie: but I wouldn't be shocked if later the behavior changed to match the docs - especially when it is consistent with everything else 20:26:52 can there be intermitent fix when documentation gets adjusted to highlight both behabiours (200 and 204) and then queue real fix for later release? 20:27:01 the _only_ reason I could _possibly_ think of to check the specific 200 vs. 204 is if you were coding to a spec - in which case you would have been wrong 20:27:06 mordred: sure - but in some APIs different succes codes mean different things 20:27:07 mugsie: what edleafe said 20:27:08 otherwise you'll be coding to 2xx 20:27:24 one is "its done" anther is "come back and check" 20:27:38 in the 204 case its not as clear cut 20:27:49 mordred: IIRC thats what triggered the keystone patch to change things from 200 -> 204 20:27:49 right - but this is "it's done" and "it's done and I don't have a payload" 20:27:51 mordred: I'm not sure we have previously applied any expectation that users will be rational when we limit changes of this nature. :-) 20:27:58 dhellmann: :) 20:28:00 dhellmann: yeh, that's really the crux 20:28:01 this is probably the closest we will come to this sort of exception being mostly harmless 20:28:07 dtroyer: ++ 20:28:19 dtroyer: true 20:28:19 so... just to be warned 20:28:29 I really don't think we are in danger of setting precedent we will eventually regret here 20:28:36 me either 20:28:37 mugsie: if I saw docs = 204 and behavior = 200, I'd code 200 <= response < 300 and be done with it. :) 20:28:42 OK, let's make some progress here -- (1) which approach would you rather take, Glance or QA ? And (2) how would you avoid such disagreement in the future ? 20:28:45 fwiw, in this case, I'd prefer to take the API-WG's advice and go with it 20:28:45 edleafe: ++ 20:28:52 there have been individuals across multiple projects wanting to change up all the success codes to match the api-wg recommendations 20:28:59 ttx: I explicitly do not want this to be about a general response 20:29:01 because probably about 30% of succes is wrong 20:29:06 ttx: to be clear, it's a choice between correcting the docs and between changing the code? 20:29:09 by strict http standards 20:29:10 this is a very specific case with a very specific set of tradeoffs 20:29:16 dtroyer: there is a simple middle ground here just version the api. So it matches the docs moving forward but maintains backwards compat for older clients 20:29:16 dhellmann: yes 20:29:18 that I think rosmaita has done a great job of enumerating 20:29:24 sdague: sure, and much of that will cause much more heartburn… are the docs wrong (different) in those cases too? 20:29:26 dhellmann: or between changing the documented behavior and correcting the code ;) 20:29:27 so, if this slider moves, that all comes into play 20:29:28 which is what I always recommend for an api change 20:29:29 we absolutely do not need to make any larger decisions on policies 20:29:33 fungi : yes 20:29:58 mordred: so you would explicitly not provide an answer for (2) (how to avoid such disagreement in the future) 20:30:05 ttx: yes. very much so 20:30:09 and rule case by case 20:30:09 dtroyer: where the docs have been wrong on the nova side, we've been just fixing the docs 20:30:10 mtreinish: assuming clients ever actually pay attention to API versions… it's more of a "notice a break" and reactively deal with it situation 20:30:11 this is not a precedent-needing problem 20:30:12 but, now the docs will be wrong for one release, and right for one - where as if the docs are fixed, they are right for all versions 20:30:13 yes 20:30:21 mordred: wfm 20:30:23 sdague: perfectly good option too 20:30:34 ttx: I understood 2) to mean "why don't teams cooperate"? 20:30:35 i like flaper87's position. we have the api working group for a reason, and the glance team did consult with them to get an answer. i see no reason to disagree with them on api-behavior-specific topics 20:30:35 dtroyer: right, by versioning it you don't break anyone 20:31:01 mugsie: right, I view this as more a doc bug then anything 20:31:01 mtreinish: now if only Glance supported microversions... :) 20:31:03 versioning just shifts the complexity to a different place 20:31:10 for this 20:31:10 fungi: ++ 20:31:13 mordred: yeah 20:31:16 fungi: ++ 20:31:21 mordred: +1 20:31:32 mordred: ++ 20:31:45 versioning needs to be done, but I don't think this is a zero-sum situation 20:31:50 fungi : ++ 20:32:04 edleafe: right, this issue has come up before with glance more than once in the past few weeks, and it's why I proposed that tag 20:32:05 also, the tc contradicting the api working group on a topic like this feels like a vote of "no confidence" in them 20:32:07 fix the friggin bug, and get up to date with versioning…we really need both 20:32:23 dtroyer: +1 20:32:24 dtroyer: totes. versioning needs to be done. but punting to versioning for this one I think is overkill 20:32:25 OK, it feels like there is a majority agreeing to take Glance's side on this one ? And no majority to make that a precedent 20:32:41 * ttx prepares a #startvote 20:32:43 ttx: you may want to have an actual IRC vote, just for logging purposes 20:32:44 ttx: if there is any precedent, it's that the teams all acted appropriately 20:32:44 i can go with that ttx 20:32:48 ttx: that 20:32:50 :D 20:32:57 ttx: glance talked to the API-WG - the QA team was appropriately conservative 20:33:11 ++ mordred 20:33:14 mordred: ++ 20:33:15 mordred: ++ 20:33:17 if the same situation arises again and all of the teams follow this pattern I don't think it'll be bad for openstack 20:33:22 mordred: no versioning should have been done for the other breaking change glance made a few weeks ago where they completely changed the membership api 20:33:23 so, I don't actually understand how you can reject the precident though 20:33:25 mordred: good summary 20:33:30 i definitely don't see this as setting any precedent for anything other than agreeing with the api-wg on their assessment of effectively non-impactful minor changes 20:33:34 #startvote Should that conflict be solved by taking Glance's or QA's approach? Glance, QA, abstain 20:33:35 Begin voting on: Should that conflict be solved by taking Glance's or QA's approach? Valid vote options are Glance, QA, abstain. 20:33:36 Vote using '#vote OPTION'. Only your last vote counts. 20:33:38 fungi: ++ 20:33:49 #vote Glance 20:33:51 #vote Glance 20:33:55 #vote Glance 20:33:56 #vote Glance 20:34:03 #vote QA 20:34:06 #vote Glance 20:34:09 #vote Glance 20:34:17 #vote abstain 20:34:24 #vote abstain 20:34:41 #vote Glance 20:34:51 (would rather come up with a precedent but understand why its not necessarily desirable here) 20:35:09 ttx: you can't not though 20:35:34 sdague: sure, the precedent includes the amount of (non)breakage potential too 20:35:38 ok, 30 more seconds 20:35:58 dtroyer: that's fine, like I said a rather large amount of success codes are non HTTP pure 20:36:28 * mugsie will bet this *will* be used as an example of a change that was allowed in the future 20:36:36 sdague: right. and a large number of thouse would be painful, so any precedent doesn't apply 20:36:39 we've had specs in Nova to go clean those up, which we've kept pushing back on because it's a lot of churn for not much clear value 20:36:39 #endvote 20:36:39 Voted on "Should that conflict be solved by taking Glance's or QA's approach?" Results are 20:36:40 QA (1): mtreinish 20:36:41 Glance (7): dims_, fungi, mordred, dhellmann, dtroyer, flaper87, EmilienM 20:36:42 abstain (2): ttx, sdague 20:36:48 mugsie: doesn't prevent anyone from re-raising it to TC 20:36:55 ttx: it doesn't 20:36:57 but it won't be 20:37:14 it sets a precedent that backward compatibility rules are open to interpretation in some cases 20:37:22 it's fine that was the decision, but please don't pretend teams won't self censor on it 20:37:35 fungi: which I think is a step in the wrong direction 20:37:37 and that the API-WG should be consulted when they are open to interp as well 20:37:40 fungi: the apis change enough as it is 20:38:11 #info ttx: glance talked to the API-WG - the QA team was appropriately conservative 20:38:23 ok, next topic 20:38:27 #topic Deprecate postgresql in OpenStack 20:38:32 #link https://review.openstack.org/427880 20:38:49 On this one I was wondering if we can really use that 8% figure to say that "the ecosystem has settled on MySQL as the backend" 20:38:57 that user survey metric is a bit weird, since 24% say they use MongoDB 20:39:12 ttx: because of ceilometer, right? 20:39:17 ttx: telemetry? 20:39:19 and also of that 8% only half were apparently describing production environments? 20:39:24 Also Xen/Xenserver represents 6% of Nova deployments... has the ecosystem settled on KVM ? 20:39:33 sdague: 24% of deployments using ceilometer ? 20:39:40 * ttx looks 20:40:05 i'm more concerned that we have fairly major distributions (suse and huawei) deploying with postgresql by default instead of mysql 20:40:28 it feels like the backlash is not coming from a vocal minority as much as I expected it 20:40:28 and curious to know what impact this would have on them 20:41:03 fungi: I'm curious what they've seen when there has been so little testing as it is on pg 20:41:06 sdague: you're right, probably comes from Ceilometer 60% 20:41:31 dtroyer: yeah, I'm curious about that too 20:41:33 in TripleO, we use MongoDB with Zaqar messaging 20:41:34 fungi: yeh, it seems like products by suse, huawei, and windriver are based on pg, but I've never seen an organic instance in the operator community based on that 20:41:34 While not an API, this also seems like a breaking change 20:41:46 dtroyer: tbh, there isn't much breakage. the rare times we notice issues, we'll just patch it upstream. 20:42:05 does anyone know what CERN is using ? Tim sounded like he would rather keep pg 20:42:06 fungi : we will need some time to find the dev teams in there and ask them 20:42:14 gordc: how hard is it to identify that as a DB issue? or are you good enough at it by now to see it quickly? 20:42:19 ttx: galera I was pretty sure 20:42:30 ttx: mysql AFIK 20:42:35 sdague: ftr, i understand there is a very large telco in europe basing their public cloud on huawei's distribution at least (they said as much in either a keynote or a board meeting, maybe both) 20:42:46 anyway, I think that shouldn't block our decision -- but I think it calls for a deprecation period 20:42:48 It's interesting that patching issues like this are acceptable, but patching a minor API success code change causes so much concern 20:42:52 fungi: yes. I have an account on it 20:43:05 dtroyer: i don't actually manage the product stuff so i can't give you accurate details on how quickly it gets identified 20:43:08 at the very minimum 20:43:26 I think the step of deprecating pg is necessary to either move forward with officially unsupporting it or to rally (again) the support required to properly maintain it 20:43:33 dtroyer: we're not tracking master so we really only notice things when we start pulling in update for next version 20:43:35 i.e. we would not intentionally scrap pg-compatibilty code until +1year 20:43:59 ttx: but we should definitely ensure it's not really in docs and the like 20:44:12 yah. I don't think removal without a full and conservative deprecation cycle is an option 20:44:26 because right now there is implied support from upstream 20:44:27 gordc: ok, so given the lag from master to distro, the removal of most pg jobs early in Ocata(-ish) only now gets to you? 20:44:34 sdague: well, if the other is "deprecated" it should not look good in docs indeed 20:44:41 dtroyer: we had pgsql test in ceilometer gate and we were noticed a pg break every 8 months or so... majority the db stuff we do in openstack is really generic. 20:45:03 gordc: ok, thx 20:45:18 dtroyer: I would not assume that it would even on the radar of some distros yet 20:45:18 sdague: I agree the mismatch between support upstream and usage is distro is a bit weird 20:45:24 is the problem with supporting it the lack of folks to fix breaks, or is there a pressing technical need for something only available in mysql? 20:45:35 dtroyer: i can't recall how many issues reached downstream. when i asked, they gave me 3 examples of them patching upstream to fix pgsql 20:45:42 dhellmann: the former 20:45:53 edleafe : ok, because I've heard both arguments 20:45:54 edleafe: I'd say both actually 20:45:58 I think the reason I'm advocating for us to consider this is so that we can consider _not_ doing really generic database stuff 20:46:02 mordred : "pressing"? 20:46:06 Theoretical: if someone shows up and fixes PG support and works in QA team to support it, would we reverse the decision ? 20:46:07 nothing is pressing 20:46:11 openstack has worked for years 20:46:18 dhellmann: from my point of view the problem is the extra overhead of "oh, we'd like to do utf8 right on these fields" 20:46:23 right, ttx phrased my question more directly 20:46:31 "oh, wth does pg do there? do we have to care?" 20:46:33 feature dies 20:46:35 yup 20:46:37 sdague: ++ 20:46:50 there's a ton of db improvement that dies on the vine 20:46:57 I am surprised that unicode is even something we have to deal with. Doesn't sqlalchemy do that? 20:46:58 ttx: we've seen that for short periods before, how do we gauge long-term commitment? 20:47:00 mordred: the impetus was lack of support. Once we consider dropping it, then the possibilities of MySQL-centric stuff start to bloom 20:47:02 dhellmann: no 20:47:08 ffs 20:47:09 dtroyer: unicode is execptionally difficult to get right 20:47:11 gah 20:47:13 dhellmann: ^^ sorry 20:47:24 the db engine is really important 20:47:32 especially if you are trying to index things for search 20:47:38 happens that databses are hard to abstract after all 20:47:39 ++ 20:47:49 there is this assumption that sqla and oslo.db abstract the db 20:47:51 they do not 20:47:55 edleafe: ++ 20:48:02 they provide some convenience functions 20:48:18 i mention this on patch... but breaking something that works for some hypothetical improvements is kinda sketchy. 20:48:20 and if you write some thing in ormish ways, some common 80% cases are made to look the same 20:48:49 gordc: devil's advocate: in openstack we say that what's not tested is broken 20:48:54 gordc : I'm hearing a very specific improvement in non-ascii text support 20:49:12 I'm more concerned about the lack of testing or resources to work on it 20:49:18 ttx: fair enough. 20:49:27 gordc: would you object to proposed model/schema changes that improved performance in mysql but worsened performance in postgresql (or vice versa)? 20:49:41 ttx: right, it seems like a very few (1 or 2) people actually maintain it 20:49:57 ttx: the question in my mind is whether we phrase the deprecation as reversible if support shows up, or if we say it's settled once and for all 20:50:02 fungi: nope. i think that'd be good. 20:50:04 gordc: I'm saying "devil's advocate" because my personal preference on this is that we should find a way to make it work 20:50:07 just curious whether we need some actual examples of beneficial changes we've avoided/abandoned because they'll impair one specific backend 20:50:24 how much deprecation period are we looking at? 20:50:57 ttx: i'd prefer a periodic check to see actually validate pgsql is unmaintained 20:51:03 this is a *very* liberal use of our deprecation policy :\ 20:51:06 dhellmann: well... deprecation will not actively break, it's more of a statement that we'll start actively breaking pG by removing code or adding MySQl-specific stuff by one year 20:51:11 fungi: I would think that would help some decision makers somewhere know (and work on their upstream mgmt) if they want to fund support 20:51:12 or if it's just working and nothing pgsql is being done. 20:51:18 so it's easily reversed if we can be convinced 20:51:45 but as dtroyer said, would take a lot to convince it's strategic involvement and not purely tactical 20:51:46 ttx: right, but if someone comes along offering to do support and their work is going to be turned away because we don't want that work, we should just say that up front 20:51:48 my concern about all of this, is the same bind we get into with "this does't work" "oh we need people to support it" 20:51:49 ttx: I think that's a great way to phrase it - it would also give folks a time to work up things like what fungi is talking about 20:51:55 because it's not really true, we need maintainers 20:52:01 people that are proactively on top of things 20:52:16 sdague: ++ 20:52:20 sdague: ++ 20:52:29 because, what happens with just the "raise hands to support" is someone else already burdened in the community has to own the maintenance 20:52:32 and this is one way to let our contributing companie know where they need to pay attention 20:52:32 One concern would be if pg goes away, we add some mysql specific functionality, then someone shows up and wants to maintain and add back in pg support. 20:52:34 sdague: yes as I said it would take a lot to convince us that PG is actually maintained 20:52:39 It will be much more difficult then. 20:52:47 smcginnis: it will be 20:53:00 because we decided not to burden existing contributors with it 20:53:07 so that they could focus on more important things for users 20:53:10 it's all trade offs 20:53:10 smcginnis: will be too late by then 20:53:23 sdague: Yep, fair point. Just pointing that out with talk of keeping the door open for it. 20:53:24 i'm also curious what "deprecation" would look like. should we rip out any postgresql deployment examples in master branches of install documentation at the start of the deprecation period, or at the end of it? 20:53:24 smcginnis : right, that's another reason for us being clear if what we're really saying is that we are going to drop pg and not accept maintenance work 20:53:28 smcginnis: we can only reverse that decision during the deprecation period, while we don't touch anything 20:53:33 smcginnis: I second you. Also some companies might need to fork some projects to maintain pg support ... which wouldn't be cool either. 20:53:34 dhellmann: +1 20:53:35 and, it's fine to say that our resources should be spent on a db that is rarely used 20:53:45 just curious, but how are we certain it's not maintained? 20:54:03 gordc : because people were not showing up to deal with breaks in the gate? 20:54:20 and that led to teams dropping the postgresql jobs from their gate 20:54:32 I think deprecation here means a) documenting the current state (untested), and b) waiting a period, sya a year, for the situation to change, and c) re-evaluating at the end of that period before allowing mysql-specific bits 20:54:32 and now it's probably broken but noone knows 20:54:36 dhellmann: i see. i didn't realise there were more. the pgsql we found was patched within 12 hours 20:54:39 yah - postgres has _consistently_ been ignored for YEARS 20:54:43 this isn't like a recent thing 20:54:55 from our projects perspective, every now and again, someone comes in to fix pg, gets a gate and leaves. 20:54:55 gordc : at this point only the telemetry team was gating, iiuc 20:54:58 yeh, pretty clear the fact that we dropped pg from the gate an no one was there building alternative testing around it, means it's not maintained 20:55:04 mugsie: ++ 20:55:10 then 6 months later something breaks, and we just drop the gate 20:55:10 mordred: so it's been deprecated, but we're now just owning up to it? 20:55:20 dhellmann: neutron i mentinoed they have periodic postgresql 20:55:26 edleafe: the openstack community has literallky never actually cared about postgres 20:55:27 ok, I think we made progress. Let's discuss this F2F next week and I think we'll be able to make a call for Pike 20:55:31 gordc : a periodic job is not a gate job, though, right? 20:55:55 and a periodic job is only as good as the people watching the results 20:56:02 mordred: it seems that enough people cared to create the tests in the first place 20:56:06 and, more importantly, no one is getting ahead of things 20:56:12 sdague: ++ 20:56:13 mordred: once they left, no one picked up the slack 20:56:17 just having a test job isn't maintaining anything 20:56:18 It's reactive rather than proactive 20:56:18 dhellmann: right. i forgot what question was... if it's being gated on? it's not. :) 20:56:23 edleafe: that's how I define "community doesn't care" 20:56:24 gordc : right 20:56:41 i'm just wondering if it's actually broken. :) 20:56:42 mordred: and that's how I define effectively deprecated 20:56:43 edleafe: a random human helicoptering in to do work once and then going away does not equate to overall care and feeding 20:56:47 we (designate) actually do have a voting pg gate job right now 20:56:48 edleafe: totes 20:56:49 gordc: I don't see any periodic jobs with postgres in the name: http://status.openstack.org/openstack-health/#/?groupKey=build_name&searchProject=postgres 20:56:57 edleafe: oh - sorry - yes, I agree with you - I was just trying to agree more strongly 20:57:03 mordred: :) 20:57:12 #topic Open discussion 20:57:16 mtreinish: just going by what neutron said. 20:57:16 Quick couple of topics 20:57:18 We'll skip the TC meeting next week due to PTG 20:57:21 Yeah, I'm just saying let's be honest about it 20:57:24 and amrith raised the issue of the "OpenStack Clean" bot posting comments on unworthy changes 20:57:28 #link http://lists.openstack.org/pipermail/openstack-tc/2017-February/001333.html 20:57:34 While I generally agree with what it says, it feels like a slippery slope to have anonymous bots trolling on reviews 20:57:40 Any opinion on that one ? 20:57:50 ttx: I think the account has been disabled 20:57:56 mtreinish: we dropped ours recently. 20:57:59 yes, that doesn't seem like the right answer there and I agree with disabling the bot 20:58:03 yes, but in a legal vacuum -- should we have a nobot policy ? 20:58:10 or only vetted bots ? 20:58:17 the comments are really useless but don't hurt anyone though I agree with disabling the bot. 20:58:21 vetted only seems resonable 20:58:22 only infra approved bots 20:58:36 dims_: sounds good 20:58:36 dims_: yes, +1 20:58:36 gordc: that link is going back a month 20:58:42 gordc: you can change the period 20:58:45 vetting bots that post seems like a reasonable standard 20:58:51 similar to the 3rd party CI requirements? 20:58:57 #agreed Only infra-approved bots are allowed on Gerrit 20:58:59 ttx: are we sure that's a bot? It's review here seems like a human: https://review.openstack.org/#/c/430164/ 20:59:13 mtreinish: it's a human that repeats itself very often then 20:59:15 how is that done? sounds like a "Real Name" policy 20:59:24 mtreinish : maybe it was a bulk update 20:59:34 * fungi isn't sure he wants the infra team burdened with vetting every single automated system which comments on reviews... there are hundreds already 20:59:36 also, bots aren't supposed to vote in CR 20:59:39 notmyname: Turing test ? 20:59:45 bots are only supposed to vote in V 20:59:49 notmyname: we kind of have that with the CLA 20:59:57 fungi : ++ 21:00:04 stackalytics ranking improvement bot? 21:00:08 notmyname: if the bot can convince us it's human, it's probably good enough 21:00:17 smcginnis: ha! 21:00:23 mugsie: no idea how the cla has anything to do with code review comments though 21:00:25 and we are out of time... 21:00:40 ttx: thx for chairing! 21:00:40 See you all next week ? 21:00:43 o/ 21:00:46 or almost all 21:00:48 See you in Atlanta! 21:00:56 thanks everyone! 21:01:00 #endmeeting