20:01:30 #startmeeting tc 20:01:31 Meeting started Tue Feb 28 20:01:30 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:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:33 ttx: o/ 20:01:34 The meeting name has been set to 'tc' 20:01:36 good work to ttx and diablo_rojo and erin disney for planning it 20:01:40 sdague has an unexpected family thing to take care of 20:01:49 Our agenda for today is at: 20:01:49 ttx: sdague said he won't be able to make it today 20:01:53 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:58 o/ 20:02:01 heh, I'm too slow :) 20:02:02 mtreinish: yeah, saw that 20:02:17 reordered agenda a bit in consequence 20:02:28 (friendly remember to use #info #idea and #link liberally to make for a more readable summary) 20:02:35 #topic move the UX team to legacy status 20:02:42 #link https://review.openstack.org/437957 20:02:50 Was proposed following the discussion @ http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html 20:02:51 ship it 20:02:55 We'll definitely have a Forum discussion about how to drive future UX efforts 20:03:03 Most likely using a workgroup (like the API WG) if there are enough people interested 20:03:11 In the mean time, should retire the "project team" since it doesn't even have a PTL 20:03:13 ++ working group 20:03:20 ttx: I think UX makes a lot more sense as a WG 20:03:21 * edleafe tiptoes in late 20:03:23 yeah, good plan to discuss at the forum with a working group 20:03:32 well, to create one 20:03:33 ok, approving now 20:03:44 yeah, working group sounds like a better format for UX 20:03:48 done 20:03:53 * flaper87 states what everyone has stated already 20:03:55 #topic PTG postmortem 20:04:00 Any feedback on PTG ? 20:04:04 We already identified a number of potential improvements 20:04:05 AWESOME PTG! 20:04:10 Like doing a smarter split, or making the schedule more globally visible 20:04:17 Overall I was very happy with the format 20:04:17 But need to be careful to not kill what made the event great 20:04:20 * flaper87 calms down 20:04:28 * notmyname wishes we'd had more ops present 20:04:34 notmyname ++ 20:04:39 yeah, something more globaly visible, certainly for the first two days cross project things 20:04:41 the feedback I got was quite positive 20:04:48 flaper87: ++ 20:04:49 I've seen a couple of people suggest a bit more scheduling for cross-project discussions on the first few days, and I think that might help. Especially for the goals rooms. 20:04:49 yeah, more ops would have been nice, although in Nova we were lucky 20:05:00 o/ 20:05:00 I wonder if PTG + Ops meetup would make sense 20:05:08 dhellmann: yeah, I think that would definitely help 20:05:12 johnthetubaguy: i was actually going to ask about that 20:05:13 johnthetubaguy: YES! 20:05:13 ttx : it was great!. 2 items as feedback - 1) shorten the first 2 days to a 1-1/2 days and 2) more structure, better time slots for the first 2 days 20:05:13 combine the ops midcycle? 20:05:17 Last I checked they wanted to keep them separate 20:05:21 dhellmann I would agree 20:05:23 and go local 20:05:28 In general, it'd be great to provide a way for teams to make their agenda public, even if it's not immutable (ethercal?) 20:05:35 dhellmann: we'll fix that next time I guess 20:05:43 ttx: yeah, but that was the same exact thing that individual prject teams said too ;-) 20:05:47 i thought the ptg worked out great, wouldn't change much. maybe small incremental improvements 20:05:48 at one point we did have an idea to potentially colocate, but it seemed like there was some pushback from both dev and ops side. i'm open to having that discussion again though 20:05:49 Yeah, +1 to a clearer schedule 20:05:56 flaper87 : ++, though ethercalc doesn't work on a phone, so it's not great when moving between rooms 20:06:05 fwiw - keystone approached it very similar to how we schedule midcycles and that seemed to work well for us 20:06:07 now... the forum, depending might be the dev + ops thing we need, but hard to tell till we try that I guess 20:06:09 ++ dhellmann 20:06:10 if they're not combined, I'd imagine we'd always hit this problem for people to justify to employers ptg + forum + ops midcycle 20:06:13 dhellmann: good point 20:06:28 i guess some tool like that that would allow for mutable schedules to be published 20:06:30 right, once we have one "forum" the ops+dev feedback loop will be clearer 20:06:30 jbryce : if the point is to have an opportunity for contributor teams to focus internally on their work, I'm not sure colocation helps. Isn't that what the forum is for? 20:06:39 dhellmann: ++ 20:06:40 hearing from the smaller projects was interesting, they had a lot more time, and benefited from that 20:06:42 ttx : jbryce : i saw numbers posted on -ptg channel. repost here for wider audience? :) 20:06:43 that way everyone can know what the heck is going on in each room 20:06:51 there's still a lot of confusion around what the PTG means for the summit or forum (or even what those are) and who should be where 20:07:01 508 registered with 478 on site 20:07:05 dhellmann: but... without operators answering out questions in the Nova room, I am sure we would go way off track 20:07:05 flaper87 : even something that pulled from the ethercalc and presented a scrollable html page might be good enough 20:07:07 dhellmann: i agree, just throwing it out there for discussion 20:07:13 dhellmann: ++ 20:07:22 curious what the drive to add more non-upstream-developer operators into the mix is. i thought we wanted to push operator and user feedback to the forum 20:07:41 Anyway, that's a good cue for the next topic 20:07:45 johnthetubaguy: yah - I liked how we had folks from 'smaller' projects in the importnat conversations 20:07:47 johnthetubaguy : I'm not saying exclude everyone, I'm just not sure turning this into another giant event will solve the problem we said the split was addressing 20:07:51 fungi: its more it was obviously missing, I think once the forum happens, yeah, it might be different 20:08:08 mordred: true, it worked both ways I think 20:08:19 ++ johnthetubaguy 20:08:33 johnthetubaguy: ++ 20:08:37 dhellmann: yeah, it might just be a messaging thing, the 3/4 ops folks in our room was great, but they came to our midcycles anyways, so maybe they don't count 20:08:48 * mordred wonders if there is a difference in pre-incrementing and post-incrementing a johnthetubaguy 20:08:59 heh 20:09:05 johnthetubaguy : some balance with more than 0 ops would be good 20:09:09 Alright -- if you have more feedback, the survey should still be up 20:09:10 it's probably a good idea to get through the full cycle (ptg, ops meetup, forum) and then see if we're getting the right interactions or not 20:09:13 * mordred tweets that johnthetubaguy said some ops people don't count 20:09:19 jbryce: yes 20:09:24 mordred: heh 20:09:24 jbryce: ++ 20:09:27 which brings up to next topic 20:09:28 johnthetubaguy: heh, yeah the nova room looked like the normal midcycle crowd when I was there 20:09:32 #topic Forum is next 20:09:35 mtreinish: yeah, which was nice 20:09:38 Boston Summit is in 10 weeks (!) 20:09:41 jbryce : mid-stream isn't the best time to change horses?! 20:09:51 We need to start building the schedule for the cross-community discussions at the "Forum" there 20:09:54 dhellmann: or replace horses with leopards? 20:10:02 ttx: oy. really? 10 weeks? 20:10:04 The general idea is to start collecting ideas on etherpad(s) 20:10:14 dhellmann: ha...i'm known for being deliberative. especially about my horses = ) 20:10:14 Then to submit the result of that brainstorming to some CFP system (probably good old odsreg system) 20:10:17 ttx: that seems like its too soon :) 20:10:27 And then a group from TC / UC / Staff would select and schedule the discussion topics on available slots 20:10:37 Plan is for 2 of each group to keep the committee small 20:10:43 * mtreinish hasn't even processed all his todos from the ptg yet 20:10:46 So first question, who here would be interested in being part of that selection committee ? 20:10:55 o/ 20:10:56 Better if your term does not finish in April I guess... So mordred sdague stevemar dhellmann emilienM fungi 20:11:01 damn 20:11:06 ttx: I can help with that I think 20:11:10 heh, or not :) 20:11:10 yeah, i'm happy to pitch in on it 20:11:15 lol flaper87 20:11:21 * stevemar sneaks in 20:11:25 just to throw an idea out there, it seems like there are two sets of things: new ideas/requirements and prioritising the current planned things 20:11:41 ttx: I am happy to help, but yeah, my term is closing soon too I think 20:11:51 ttx: I'm interested for sure 20:12:05 are there other bit groups of things we want, rather than those two? I am curious 20:12:25 Then I think the TC should start a brainstorming etherpad, and invite other groups to start thinking about it 20:12:33 johnthetubaguy : some sort of retrospective or issue list for ocata would be good 20:12:35 Should send something along the lines of http://lists.openstack.org/pipermail/openstack-operators/2017-February/012793.html 20:12:38 * fungi wonders why we shouldn't extend the organizing to any tc emeritus and, well, maybe others in the community who are interested in helping 20:12:44 i'd add a 3rd set which i think is slightly different than your first one: more of the strategic higher level thinking for the future 20:12:48 ahh, invite other groups. got it 20:12:50 (priority picking includes feedback on existing ideas) 20:12:58 fungi : anyone can contribute, but we need a small group to make decisions 20:13:07 dhellmann: yep, that seems fine 20:13:15 ack dhellmann 20:13:19 dhellmann: yeah, I guess general feedback, the more typical ops sessions at the summit are a bit like that I guess 20:13:23 dhellmann: I agree 20:13:39 selection committee basically == track chairs 20:13:43 I think we need to get in the habit of discussing things that require ops presence at the Forum, vs. things that are mostly internal-facing at the PTG 20:13:56 which is why a full cycle will help 20:14:02 fungi: yes 20:14:35 ttx: totally, we need to try that before we change course 20:14:47 ttx: I think I like that idea better. 20:14:48 jbryce : I like the idea of near- vs. longer- term for framing it. Something like "how is ocata working out for you?" then "what are you interested in seeing in queens?" then "what about after queens?" 20:15:15 although there will also be sessions on specific things like "how should quotas work?" 20:15:25 dhellmann: yes, that is how the email on the ops list framed it 20:15:36 #link http://lists.openstack.org/pipermail/openstack-operators/2017-February/012793.html 20:15:36 dhellmann: yeah exactly. i think one of the big potential benefits of the forum is actually decoupling some conversations from a release cycle 20:15:38 * dhellmann hasn't looked at that email 20:15:40 dhellmann that would be helpful for projects to determine priority for sure 20:15:51 and the perennial ptl dunking booth, of course 20:16:36 the thing I don't want to miss is direct feedback on current ideas for the future, often the big problem is picking what things should be done first, discarding things that will not really help 20:16:59 ok, so the unquestionable volunteer would be EmilienM (fungi being Foundation staff could use one of the staff helper slots if nobody else takes it), so I'll work with him to get that email sent tomorrow 20:17:04 johnthetubaguy : so a "we're planning X, are we headed in the right direction?" session 20:17:17 thanks EmilienM! 20:17:27 well, I did nothing yet :P 20:17:29 EmilienM: we'll customize http://lists.openstack.org/pipermail/openstack-operators/2017-February/012793.html 20:17:29 dhellmann: yeah, and which of these 10 ideas should be our top 5 for next cycle 20:17:39 if you want to start on that work early 20:17:44 and yeah, don't want too much foundation representation on the committee 20:17:44 ttx: yes, let's work together offline 20:17:46 ttx: apparently I have a lot of opinions on this, too, so I can help if you need another non-staffer 20:17:52 dhellmann: dependencies such of course, so its an interactive debate 20:17:59 dhellmann: you got it. 20:17:59 but i'm happy to be standby 20:17:59 s/such/suck/ 20:18:08 dhellmann: thanks :) 20:18:45 johnthetubaguy : yep. it'll be challenging to organize a session like that for every project team. 20:18:54 getting the ops -> dev feedback working better is close to my heart, but yeah 20:18:55 #action EmilienM to work with ttx to announce the start of Forum brainstorming 20:19:08 dhellmann: agreed, we would need to group stacks of things 20:19:25 we also need to make sure this is ops <-> contrib not just ops -> contrib 20:19:35 so i guess if projects are putting together their roadmaps, this provides a great opportunity to have the community help them filter it down 20:19:38 yeah, I drew the arrow wrong 20:19:51 the problem is ops -> something -> dev always goes wrong 20:19:56 how about the other groups like the LCOO folks? 20:20:00 yeah, I wasn't picking on you, just highlighting how this is a different thing than some of our other feedback sessions 20:20:07 dims: forum is everyone <-> everyone 20:20:15 johnthetubaguy: ^ 20:20:25 yep 20:20:34 flaper87: ? 20:21:15 OK, anything else on that topic ? 20:21:33 biggest problem is turning the feedback we are getting into actionable items for the dev teams. any ideas there to do differently? 20:21:52 dims: I'd like the person who drives the discussion to post something at the end to the ML 20:21:56 dims: my reviewing of existing ideas is where we have seen the most success 20:21:56 to extend the discussion 20:22:05 I see Forum discussions as the start of a long story 20:22:06 yeah, basically what ttx said 20:22:12 ttx: yes 20:22:37 which is why the ops email frames it as "the start of the Queens cycle" 20:22:44 right ttx johnthetubaguy 20:22:45 ttx: that can be transformes in specs in WGs or Community Goals for example 20:22:52 transformed * 20:22:54 yah 20:22:58 EmilienM: ++ 20:22:59 would be especially nice if representatives of the relevant dev teams were there to receive feedback, of course 20:23:06 EmilienM: in time for being prioritized at the start of thde dev cycle 3 months later, yes 20:23:11 yeah, it has to be two way converation 20:23:15 a debate 20:23:22 fungi : right 20:24:14 some of that will probably feel natural too at some point- the api/discovery discussions at the PTG seemed to produce some rough consensus on some topics which should probably get written up as goals at some point - I imagine similar things will emerge from the ops forum stuff 20:24:28 a team which is functioning well should be capable of directly turning that feedback into something actionable on their own, i would think 20:24:38 and the nice part about those is that all of the goals will get to start off with "the operators at the forum all said ..." 20:24:40 :) 20:24:56 Not just ops. I'd like to see API users there too 20:25:08 fungi: yah. being able to synthesize so that the teams have clear communication on what is actually being requested is the fun part 20:25:15 ttx: wait - what? we want to hear from API users? 20:25:21 "the people who actually install and run your software put down their torches and pitchforks for a moment and said..." 20:25:23 mordred: shocking I know 20:25:24 mordred: we can show up with API user hats on 20:25:36 clarkb: we need actual API user hats 20:25:41 that would be awesome 20:25:57 * dtroyer makes a note... 20:26:02 OK, I think we have enough to make process here... proposing we switch to next topic 20:26:03 fungi : let's not get ahead of ourselves by expecting them to put the torches down 20:26:09 fair enough ;) 20:26:11 ttx: I am curious, how are we recruiting those API user folks? 20:26:27 totally want more of that representation 20:26:30 johnthetubaguy: that's a good question, I've very rarely heard from api users directly 20:26:33 johnthetubaguy: there are a number of tracks targeted to app developers at the summit 20:26:35 the infra team is one of the best examples in the world 20:26:36 well except for mordred, but meh :) 20:26:50 johnthetubaguy: dfflanders is trying to find them from the foundation side too 20:26:54 By having a "Forum" that is not specifically branded "ops" or "devs" I hope to attract them 20:26:59 johnthetubaguy: we hear from them occasionally in -sdks 20:27:02 mtreinish : lol 20:27:09 johnthetubaguy: tracking down and engaging with api users turns out to be challenging 20:27:21 dtroyer: ah, good point, not sure that gets down to the project much, some of that is good 20:27:25 One of the issue with the old branding is that it encouraged separation 20:27:29 we mostly just get the ones wo show up to engage with us instead 20:27:40 API users are definitely harder to find and i think they are less knowledgeable finding their way around the summit. if you have any specific sessions that you think would be important for them, we can probably do some direct outreach to some of the ones we know will be there 20:27:41 fungi: +1, I am glad we restarting that effort 20:28:07 jbryce: we should make a big flashing sign "this way lovely API users" 20:28:10 yea, all leads appreciated 20:28:12 OK, we have a bit more to cover, so let's switch topics 20:28:18 #topic Board + TC workshop & TC visioning day in Boston next week 20:28:20 we should have an API users feedback rant session maybe? and direct them there in the keynote? 20:28:21 (clutches as straws) 20:28:32 ttx: +UC, right? 20:28:36 we can come back to Forum brainstorming in open discussion at the end, time permitting 20:28:39 Next week we'll have a board + TC + UC workshop in Boston to try to tackle difficult strategic questions 20:28:45 dhellmann: yes, title typo 20:28:56 ttx: do we have a list of the topic in advance? 20:28:57 I had reservations that a 30+ people workshop could lead to anything useful... 20:29:07 but Allison Randall, Alan Clark and Mark Collier worked on a workshop structure that could lead to constructive results 20:29:29 johnthetubaguy: I can ask Alan to publish something yes 20:29:42 Event logistics @ 20:29:46 #link http://lists.openstack.org/pipermail/openstack-tc/2017-February/001338.html 20:29:55 johnthetubaguy: from what i gather it's at least partly following that etherpad we've all been collaborating on 20:30:10 ttx: that would be awesome, given how I think 20:30:11 fungi: ack 20:30:20 but i agree specific agenda items would be nice 20:30:25 The agenda is on the wiki:https://wiki.openstack.org/wiki/Governance/Foundation/8Mar2017BoardMeeting 20:30:44 that has links to the etherpads that you just referenced 20:30:46 #link https://etherpad.openstack.org/p/ocata-strategic-review-board 20:30:48 * flaper87 is sad to be missing the workshop 20:30:55 * ttx scraps the action he was about to assign himself to 20:31:05 thanks AlanClark 20:31:12 thanks AlanClark! 20:31:13 Colette and I took the opportunity of having a good share of TC members around to tack a "TC visioning" exercise to the event 20:31:23 Makes the travel a bit more worthwhile 20:31:32 It will be driven by instructor(s) from ZingTrain, and Colette should be there too. 20:31:44 If you're looking for a hotel near the event, a number of us will be staying at the Godfrey. Some other(s) are at the Omni. 20:32:00 * dims will be commuting :) 20:32:11 Or we can all crash dims's house 20:32:19 tempting I know 20:32:20 #link https://wiki.openstack.org/wiki/Governance/Foundation/8Mar2017BoardMeeting 20:32:26 :) 20:32:37 i gather the kimpton (zero-nine?) overlooking the burying ground is pretty neat too 20:32:54 neat but slightly more expensive :) 20:33:10 Questions on that event ? 20:33:26 * mordred waves at AlanClark 20:33:34 I'll be arriving on Tuesday afternoon and departing late Thursday 20:34:27 is anyone else going to be around for dinner Thursday evening? 20:34:37 o/ 20:34:39 dhellmann: my plan is to drive up tues. and head out fri morning. I assume sdague is riding with me 20:34:42 dhellmann: o/ 20:34:51 so we'll likely both be around 20:35:03 dhellmann : i should be able to make it 20:35:08 great, it sounds like we'll have several folks 20:35:17 ok, if no more questions let's move on to next topic 20:35:17 i'm around, not departing until friday morning 20:35:49 #topic Deprecate postgresql in OpenStack 20:35:53 #link https://review.openstack.org/427880 20:36:00 sdague is not around, so quick update on that 20:36:09 This was mentioned last week at PTG in the context of the "base services" discussion at the Arch WG 20:36:19 Looks like one good way of approaching base services is to start with a set of viable options 20:36:26 ... delivering basic functionality that happens to be the common denominator 20:36:35 Then once the market picks a winner, we contract to that and start using more advanced features from that specific implementation 20:36:51 This review discussion shows that for databases we may be approaching the point where contraction makes sense 20:37:03 But for it to make sense we'd have to have MySQL-specific features we'd like to take advantage of. 20:37:18 The main issues raised (on the review) are around different defaults and behaviors that the abstraction is not really hiding 20:37:33 My gripe about this is that we have OpenStack distributions at Huawei and SUSE (which arguably are rising rather than declining) using postgresql 20:37:47 So I'm wondering if the key problem is not that postgresql is creating a QA / abstraction gap, a gap that those distros should help filling 20:37:57 And if after this discussion they still don't, then it may make sense to proceed 20:38:18 Thoughts ? 20:38:19 I think the key problem is signalling we need more help to keep PostgresSQL supported 20:38:20 I'm concerned, based on what I've seen so far, that if folks who want PG show up to help maintain support, they'll be turned away. 20:38:44 turned away, why? 20:38:47 dhellmann: I think it may take more now than in the past to convince us that the help is long-term 20:38:57 dhellmann: why ? I still haven't seen a clear feature we'd start suing tomorrow in MySQL 20:38:58 dtroyer: ++ 20:39:01 using* 20:39:19 it seems like there is a very strong voice in favor of dropping support as quickly as possible and not encouraging any support 20:39:19 it's raised a more general concern for me, that any time we mention an alternative solution in official documentation the downstream consumers will assume that's an officially supported solution they can rely on 20:39:33 its not really about using features in mysql, its about keeping postgres working, cause it seems to accidentally break all the time 20:39:42 ttx: no, I haven't seen anything either, that's why I'm concerned 20:39:50 fungi: ++ we're doing a disservice by claiming otherwise 20:39:53 johnthetubaguy: at least it has in the past 20:39:55 fungi : yes, we need to be more careful there 20:40:00 johnthetubaguy: right, so if someone steps up to help and managed to convince us, I don't see why we should proceed 20:40:09 fungi: +1 I think a more general statement on support 20:40:34 ttx: I think deprecating it should never be considered one way, its the flag to get the help we need to change direction, but maybe thats just me 20:40:36 From the people that are using PG w/ openstack, I want to know who is using completely upstream code. Not their hacked together patches on top. 20:40:38 I don't like "support". I prefer to think in terms of base services 20:41:10 thingee: that's a good question 20:41:20 i've seen people fixing pgsql. i think you don't see a pgsql person in community is because quite frankly, it's not broken all the time. 20:41:28 and if there are d/s patches, why those patches have not been pushed upstream 20:41:38 it'd help us understand better the problem 20:41:43 flaper87: always a mind blowing question 20:42:01 who can we ask? -operators ML? how do we reach the downstream folks? 20:42:11 I think the main problem here is, there's two arguments about postgres - some people say we're missing out on mysql-only optimizations, and others say we don't have the hands to do QA upstream 20:42:11 gordc: so it really is not in that bad of shape? just nobody to quickly jump in when things do happen? 20:42:12 flaper87, thingee : you're (a) assuming someone is carrying patches that (b) would be accepted upstream. Are those things true? 20:42:16 some of them have been weighing in on that resolution proposal 20:42:19 dims: sure. we had some public clouds come out and say they're using it 20:42:44 the former group of people will continue to say we should drop it, the latter might accept help 20:43:10 dhellmann: I think the thing is we're not sure about a) 20:43:13 dtroyer: i would say a lot/most of the sql we use is rather generic and works on both. it's just that when it breaks, it's broken on consuming gates since a lot of projects don't test pgsql 20:43:13 jroll: actually 3 sides, as I mention in my review comment 20:43:15 dhellmann: not really assuming, tbh. I'm just saying that if that happens to be the case, I'd be interested to know why they have not been pushed. The answer could be they were already proposed and rejected or that there's been some other discussion 20:43:19 Not going to point fingers, but I have reasons to believe some are possibily not using complete upstream code. Which is why I ask this question 20:43:39 for me its more about timely feedback loops, than extra patches 20:43:40 mtreinish : sure. If gordc is right and it doesn't break all that often, maybe there's not a huge set of patches out there, though. 20:43:42 thingee: that said, we should try to bring them back in the fold, rather than isolate them 20:43:43 right thingee 20:43:46 ttx: ah yes, fair 20:43:51 now the extra patches do slow down the feedback loops 20:43:57 I don't have reasons to believe there are d/s patches but if there happen to be, I'd like to know what drove that decision 20:44:10 and this is based on bug reports I get from things trying to use their clouds. mordred knows exactly what I'm talking about 20:44:12 to understand if we have a technology problem, a community problem or what else 20:44:16 thingee : ok, well, if we can't go on the record here I don't know how we address their concerns. 20:44:18 ansible, shade, etc 20:44:48 dhellmann: i guess that's also an argument for not supporting pgsql. because its rather easy to maintain out of tree since it needs very minor tweaks. 20:45:04 gordc: For now. 20:45:09 mordred: you mentioned at last meeting that we could leverage features only present in MySQL, if we dropped other support. Any example of a feature that projects would like to use ? 20:45:10 I'm guilty of saying "I'm not doing this any more" too (see requirements management), but that's a pretty blunt way to be asking for help. 20:45:12 yeah, that would change quickly 20:45:31 smcginnis: right. :) 20:45:38 gordc , smcginnis : right, that only lasts as long as we don't say "mysql-only is ok" and start having some sort of customizations put into place 20:45:41 ttx: for instance, knowing whether an schema alter can be done online or not varies very specifically by the type of alter that is happening 20:45:54 so... if we create a resolution that says "we have a problem here that needs fixing" rather than mentioning support, would we merge that? 20:46:13 johnthetubaguy : what problem do we have? 20:46:17 ttx: so to handle things _generically_ we have to put in rules that say things like "no column alters" - but in reality there are some that are safe and some that are not - but it's highly dependent on db backend 20:46:19 dhellmann, ttx have we actually verified pg jobs are passing today in gate? If not, and people are making it work somehow, there's your answer. These people that want it to continue should help us upstream continue the support. 20:46:38 mordred: ok 20:46:39 dhellmann: it keeps breaking, and we need help to keep that working and passing 20:46:45 ttx: to the point where making it reasonable to validate the particular schema alter approach in the large is unworkable and we have to resort to always copying 20:46:47 thingee : and I reiterate, would those patches be accepted? because my sense is that some folks would -1 if not -2 them 20:47:11 thingee: we turned off the postgres jobs in the integrated gate a while ago 20:47:20 mtreinish: exactly 20:47:23 assuming it doesn't break the world, they would get accepted, but DB migrations are hard to modify without breaking the world 20:47:26 ttx: similarly, the way DDL works on MySQL+Galera is different than on MySQL+Replicatoin and is different still than how it works with postgres with or without postgres ha modes 20:47:44 dhellmann: I would be in favor of not turning people away that want to help. It's just history has shown in this area people don't stick around to help. 20:47:48 ceilo was still running _a_ job that relied on pgsql until very recently tough, so that much at least was working 20:47:54 as dtroyer has pointed out 20:48:01 s/tough/though/ 20:48:11 ttx: which prevents us from having our services take care of some of theoperations for our operators, because we'd need to know way too much about deployment choice sthey made - even though it's all knowable and actionable 20:48:14 mordred: basically I want to point out direct operational gains, rather than indirect development / maintenance gains 20:48:25 ttx: right. these are direct operational gains 20:48:31 ttx: that we cannot develop as developers 20:48:32 so that the pain we introduce on the operational side is compensated by other operational gains 20:48:50 ttx: It's also making the decision of whether or not OpenStack continues to provide options and not opinions of your deployment. 20:49:07 realize that most folks running postgres are at least one, if not more releases behind. they aren't following trunk and would only fix stuff that would be backportable. Otherwise, maintain private patch 20:49:07 we basically _have_ to punt db ops to our operators rather than being able to aggressively take care of it for our operators 20:49:20 rockyg : good point 20:49:22 well its about where the options really help or not, vs how much we can help folks 20:49:59 as we have decided in the past with dlm, we decided to gate against (not yet) zookeeper. We claim support with other implementations because of tooz 20:50:07 mordred: ok, I think we need to express that more clearly in the review. I don't want this to turn into a "dev convenience vs. ops convenience" debate 20:50:22 ttx: totally. I honestly could not care less about dev convenience here 20:50:27 not that I don't like devs 20:50:44 can we maybe shrink/split review... and start by removing any explicit 'postgresql is supported' text from docs? 20:51:09 I care more that we're literally held back from making more easily operatable things because of the split 20:51:12 yeah, if we're not testing it today, it's disingenuous to have documentation implying it's a supported option 20:51:15 we'll need to re-propose this as a patch to base-services.rst anyway 20:51:22 I don't feel like there's a middle ground here. We either need to say it's supported or say it's not. 20:51:25 fungi: ++ 20:51:38 because if we don't say either, we're just encouraging folks to carry patches on their own 20:51:38 gordc: like johnthetubaguy's recent (~2 hours old) comment splitting into three things? 20:51:39 I would say at this point, we say it's not 20:52:00 and as I said before, I'd personally be just as happy if the move were to only support postgres - my point is mostly that in being able to understand the real-world operational characteristics of the persistence layer, we can make operators lives easier 20:52:06 thingee : so what's the migration story for all of those deployments currently using it? 20:52:18 dtroyer: didn't read patch recently. will take a look 20:52:29 dhellmann: "openstack services can assume the presence of a MySQL-family database through oslo.db" -- doesn't mean it can't work with anything else, but just means you can take advantage of MySQL-specific optimizations 20:52:31 (albeit at a very real cost to a subset of the existing operators - which is why it's a difficult conversation) 20:52:34 Since it's at least partly a resource problem, why not consider a third-party type of testing with the interested community members providing the hw and monitoring resources? 20:52:55 ttx: the moment any application introduces mysql-specific logic somewhere, they will break all postgresql deployments. 20:52:57 dhellmann: they can continue doing their outside patches to keep it working. 20:52:59 * dims googles "migrate from postgres to mysql" 20:53:01 If the community doesn't come forward, well, they don't want it all that much 20:53:03 rockyg: because the problem I'm trying to solve is actually not a resource problem at all, it's a structural problem 20:53:14 dhellmann: I think it sucks from our perspective too that there is no support 20:53:15 dhellmann: yes. And those will (like today) need patching to continue to work 20:53:25 * jroll returns "gl;hf" to dims 20:53:32 today they likely already do 20:53:39 since they are not CI-tested 20:53:48 they can be broken at any time 20:54:18 (not saying I agree, just unfolding the decision completely) 20:54:22 rockyg: we can't make openstack do more advanced things to manage itself (which is a complaint I get _constantly_ from the people who complain to me) because the semantics of data persistence layers are only marginally similar 20:54:50 Anyway, sounds like a great side topic for our meeting next week :) Please continue debate on the review / ML thread 20:54:51 that we could stop installing postgres in the gate is not really a win that is worth anyone's pain 20:55:06 #topic Open discussion 20:55:25 We'll skip TC meeting next week as most will be traveling to Boston 20:55:27 imho, what is not Ci-tested shouldn't be supported 20:55:43 ttx: sounds good 20:55:57 EmilienM: I think we need to stop saying "supported" as it is a bit misleading 20:56:10 ttx: also that yes :) 20:56:17 ttx: we totally need to define what we mean by that (or not as the case maybe) 20:56:21 I prefer to reuse the language in base services. "Components can assume the presence of..." 20:56:34 which is the same without the implications of commercial support 20:56:41 people use the phrase either way, I think we need to say what it means 20:56:45 (or even volunteer support) 20:56:51 EmilienM : rockyg : if we do have third party CI which project(s) will they report success/failures to? 20:56:58 fungi: yeah, thats a good way to say what we have 20:57:00 ttx: in this case, mordred seems to be making the case for "Components can assume the absence of Postgresql" 20:57:28 dhellmann: I think we'd keep oslo.db as the abstraction 20:57:53 oslo.db just gives you a connection, right? it doesn't prevent you from then doing db-specific things with it. 20:57:56 i don't know that having postgresql absent prevents projects from using mysql given they can assume _that_ will always be present 20:58:01 dhellmann : so if they want to code their own migrations online or offline without using our migration scripts we should be ok? 20:58:02 it's not a full abstraction layer 20:58:06 we also should not reject patches that make postgresql work, if that doesn't break MySQL 20:58:23 ttx : until when? 20:58:36 dims : I'm just asking that we be honest, and not imply that it's going to be easy or possible for anyone to support postgresql in 6-12 months after we've done MySQL-specific things in applications. 20:58:52 agree dhellmann 20:58:53 ttx: the problem is understanding and validating those patches without CI 20:58:56 dims: It provides a useful abstraction for narrow use cases that want to plug another DB type (at their own risk) 20:59:15 third-party testing aside, it's also a bit much to ask projects not to "turn away" postgresql fixes they can't test reliably 20:59:23 dhellmann: +1 for the more honest statement 20:59:36 fungi: +1 20:59:39 so we need to be honest with them that we're dropping support, and honest with ourselves that the change is going to be a big one with need for tools to help those existing contributors who have deployed with PG already. 20:59:41 johnthetubaguy types faster than i do ;) 20:59:42 fungi : indeed 20:59:58 fungi : +1, we also don't want some projects accepting them and others rejecting them 21:00:01 we get to rid the bandaid slowly... 21:00:07 at least not arbitrarily 21:00:18 s/rid/rip/ 21:00:45 if a team wants to keep supporting pg, that's fine 21:00:48 alright, time is up 21:00:49 I don't see how you stop projects from accepting pg patches -- some of us still have pg in our gates, so we *have* to keep it working 21:01:02 ttx: thanks for chairing! 21:01:05 #endmeeting