20:01:30 <ttx> #startmeeting tc
20:01:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:33 <mtreinish> ttx: o/
20:01:34 <openstack> The meeting name has been set to 'tc'
20:01:36 <thingee> good work to ttx and diablo_rojo and erin disney for planning it
20:01:40 <ttx> sdague has an unexpected family thing to take care of
20:01:49 <ttx> Our agenda for today is at:
20:01:49 <mtreinish> ttx: sdague said he won't be able to make it today
20:01:53 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:58 <dhellmann> o/
20:02:01 <mtreinish> heh, I'm too slow :)
20:02:02 <ttx> mtreinish: yeah, saw that
20:02:17 <ttx> reordered agenda a bit in consequence
20:02:28 <ttx> (friendly remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:35 <ttx> #topic move the UX team to legacy status
20:02:42 <ttx> #link https://review.openstack.org/437957
20:02:50 <ttx> Was proposed following the discussion @ http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
20:02:51 <EmilienM> ship it
20:02:55 <ttx> We'll definitely have a Forum discussion about how to drive future UX efforts
20:03:03 <ttx> Most likely using a workgroup (like the API WG) if there are enough people interested
20:03:11 <ttx> In the mean time, should retire the "project team" since it doesn't even have a PTL
20:03:13 <thingee> ++ working group
20:03:20 <mtreinish> ttx: I think UX makes a lot more sense as a WG
20:03:21 * edleafe tiptoes in late
20:03:23 <johnthetubaguy> yeah, good plan to discuss at the forum with a working group
20:03:32 <johnthetubaguy> well, to create one
20:03:33 <ttx> ok, approving now
20:03:44 <flaper87> yeah, working group sounds like a better format for UX
20:03:48 <ttx> done
20:03:53 * flaper87 states what everyone has stated already
20:03:55 <ttx> #topic PTG postmortem
20:04:00 <ttx> Any feedback on PTG ?
20:04:04 <ttx> We already identified a number of potential improvements
20:04:05 <flaper87> AWESOME PTG!
20:04:10 <ttx> Like doing a smarter split, or making the schedule more globally visible
20:04:17 <dtroyer> Overall I was very happy with the format
20:04:17 <ttx> 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 <lbragstad> notmyname ++
20:04:39 <johnthetubaguy> yeah, something more globaly visible, certainly for the first two days cross project things
20:04:41 <flaper87> the feedback I got was quite positive
20:04:48 <thingee> flaper87: ++
20:04:49 <dhellmann> 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 <johnthetubaguy> yeah, more ops would have been nice, although in Nova we were lucky
20:05:00 <mordred> o/
20:05:00 <johnthetubaguy> I wonder if PTG + Ops meetup would make sense
20:05:08 <mtreinish> dhellmann: yeah, I think that would definitely help
20:05:12 <jbryce> johnthetubaguy: i was actually going to ask about that
20:05:13 <notmyname> johnthetubaguy: YES!
20:05:13 <dims> 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 <thingee> combine the ops midcycle?
20:05:17 <ttx> Last I checked they wanted to keep them separate
20:05:21 <lbragstad> dhellmann I would agree
20:05:23 <ttx> and go local
20:05:28 <flaper87> 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 <EmilienM> dhellmann: we'll fix that next time I guess
20:05:43 <notmyname> ttx: yeah, but that was the same exact thing that individual prject teams said too ;-)
20:05:47 <fungi> i thought the ptg worked out great, wouldn't change much. maybe small incremental improvements
20:05:48 <jbryce> 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 <edleafe> Yeah, +1 to a clearer schedule
20:05:56 <dhellmann> flaper87 : ++, though ethercalc doesn't work on a phone, so it's not great when moving between rooms
20:06:05 <lbragstad> fwiw - keystone approached it very similar to how we schedule midcycles and that seemed to work well for us
20:06:07 <johnthetubaguy> 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 <dims> ++ dhellmann
20:06:10 <thingee> 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 <flaper87> dhellmann: good point
20:06:28 <flaper87> i guess some tool like that that would allow for mutable schedules to be published
20:06:30 <ttx> right, once we have one "forum" the ops+dev feedback loop will be clearer
20:06:30 <dhellmann> 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 <ttx> dhellmann: ++
20:06:40 <johnthetubaguy> hearing from the smaller projects was interesting, they had a lot more time, and benefited from that
20:06:42 <dims> ttx : jbryce : i saw numbers posted on -ptg channel. repost here for wider audience? :)
20:06:43 <flaper87> that way everyone can know what the heck is going on in each room
20:06:51 <notmyname> 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 <ttx> 508 registered with 478 on site
20:07:05 <johnthetubaguy> dhellmann: but... without operators answering out questions in the Nova room, I am sure we would go way off track
20:07:05 <dhellmann> flaper87 : even something that pulled from the ethercalc and presented a scrollable html page might be good enough
20:07:07 <jbryce> dhellmann: i agree, just throwing it out there for discussion
20:07:13 <flaper87> dhellmann: ++
20:07:22 <fungi> 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 <ttx> Anyway, that's a good cue for the next topic
20:07:45 <mordred> johnthetubaguy: yah - I liked how we had folks from 'smaller' projects in the importnat conversations
20:07:47 <dhellmann> 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 <johnthetubaguy> fungi: its more it was obviously missing, I think once the forum happens, yeah, it might be different
20:08:08 <johnthetubaguy> mordred: true, it worked both ways I think
20:08:19 <dims> ++ johnthetubaguy
20:08:33 <mordred> johnthetubaguy: ++
20:08:37 <johnthetubaguy> 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 <johnthetubaguy> heh
20:09:05 <dhellmann> johnthetubaguy : some balance with more than 0 ops would be good
20:09:09 <ttx> Alright -- if you have more feedback, the survey should still be up
20:09:10 <jbryce> 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 <ttx> jbryce: yes
20:09:24 <johnthetubaguy> mordred: heh
20:09:24 <mordred> jbryce: ++
20:09:27 <ttx> which brings up to next topic
20:09:28 <mtreinish> johnthetubaguy: heh, yeah the nova room looked like the normal midcycle crowd when I was there
20:09:32 <ttx> #topic Forum is next
20:09:35 <johnthetubaguy> mtreinish: yeah, which was nice
20:09:38 <ttx> Boston Summit is in 10 weeks (!)
20:09:41 <dhellmann> jbryce : mid-stream isn't the best time to change horses?!
20:09:51 <ttx> We need to start building the schedule for the cross-community discussions at the "Forum" there
20:09:54 <mordred> dhellmann: or replace horses with leopards?
20:10:02 <mordred> ttx: oy. really? 10 weeks?
20:10:04 <ttx> The general idea is to start collecting ideas on etherpad(s)
20:10:14 <jbryce> dhellmann: ha...i'm known for being deliberative. especially about my horses = )
20:10:14 <ttx> Then to submit the result of that brainstorming to some CFP system (probably good old odsreg system)
20:10:17 <mtreinish> ttx: that seems like its too soon :)
20:10:27 <ttx> And then a group from TC / UC / Staff would select and schedule the discussion topics on available slots
20:10:37 <ttx> 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 <ttx> So first question, who here would be interested in being part of that selection committee ?
20:10:55 <flaper87> o/
20:10:56 <ttx> Better if your term does not finish in April I guess... So mordred sdague stevemar dhellmann emilienM fungi
20:11:01 <flaper87> damn
20:11:06 <mtreinish> ttx: I can help with that I think
20:11:10 <mtreinish> heh, or not :)
20:11:10 <fungi> yeah, i'm happy to pitch in on it
20:11:15 <dims> lol flaper87
20:11:21 * stevemar sneaks in
20:11:25 <johnthetubaguy> 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 <johnthetubaguy> ttx: I am happy to help, but yeah, my term is closing soon too I think
20:11:51 <EmilienM> ttx: I'm interested for sure
20:12:05 <johnthetubaguy> are there other bit groups of things we want, rather than those two? I am curious
20:12:25 <ttx> Then I think the TC should start a brainstorming etherpad, and invite other groups to start thinking about it
20:12:33 <dhellmann> johnthetubaguy : some sort of retrospective or issue list for ocata would be good
20:12:35 <ttx> 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 <jbryce> 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 <fungi> ahh, invite other groups. got it
20:12:50 <johnthetubaguy> (priority picking includes feedback on existing ideas)
20:12:58 <dhellmann> fungi : anyone can contribute, but we need a small group to make decisions
20:13:07 <fungi> dhellmann: yep, that seems fine
20:13:15 <dims> ack dhellmann
20:13:19 <johnthetubaguy> dhellmann: yeah, I guess general feedback, the more typical ops sessions at the summit are a bit like that I guess
20:13:23 <EmilienM> dhellmann: I agree
20:13:39 <fungi> selection committee basically == track chairs
20:13:43 <ttx> 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 <ttx> which is why a full cycle will help
20:14:02 <ttx> fungi: yes
20:14:35 <johnthetubaguy> ttx: totally, we need to try that before we change course
20:14:47 <flaper87> ttx: I think I like that idea better.
20:14:48 <dhellmann> 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 <dhellmann> although there will also be sessions on specific things like "how should quotas work?"
20:15:25 <ttx> dhellmann: yes, that is how the email on the ops list framed it
20:15:36 <ttx> #link http://lists.openstack.org/pipermail/openstack-operators/2017-February/012793.html
20:15:36 <jbryce> 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 <lbragstad> dhellmann that would be helpful for projects to determine priority for sure
20:15:51 <fungi> and the perennial ptl dunking booth, of course
20:16:36 <johnthetubaguy> 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 <ttx> 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 <dhellmann> johnthetubaguy : so a "we're planning X, are we headed in the right direction?" session
20:17:17 <fungi> thanks EmilienM!
20:17:27 <EmilienM> well, I did nothing yet :P
20:17:29 <ttx> EmilienM: we'll customize http://lists.openstack.org/pipermail/openstack-operators/2017-February/012793.html
20:17:29 <johnthetubaguy> dhellmann: yeah, and which of these 10 ideas should be our top 5 for next cycle
20:17:39 <ttx> if you want to start on that work early
20:17:44 <fungi> and yeah, don't want too much foundation representation on the committee
20:17:44 <EmilienM> ttx: yes, let's work together offline
20:17:46 <dhellmann> ttx: apparently I have a lot of opinions on this, too, so I can help if you need another non-staffer
20:17:52 <johnthetubaguy> dhellmann: dependencies such of course, so its an interactive debate
20:17:59 <ttx> dhellmann: you got it.
20:17:59 <fungi> but i'm happy to be standby
20:17:59 <johnthetubaguy> s/such/suck/
20:18:08 <EmilienM> dhellmann: thanks :)
20:18:45 <dhellmann> johnthetubaguy : yep. it'll be challenging to organize a session like that for every project team.
20:18:54 <johnthetubaguy> getting the ops -> dev feedback working better is close to my heart, but yeah
20:18:55 <ttx> #action EmilienM to work with ttx to announce the start of Forum brainstorming
20:19:08 <johnthetubaguy> dhellmann: agreed, we would need to group stacks of things
20:19:25 <dhellmann> we also need to make sure this is ops <-> contrib not just ops -> contrib
20:19:35 <fungi> 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 <johnthetubaguy> yeah, I drew the arrow wrong
20:19:51 <johnthetubaguy> the problem is ops -> something -> dev always goes wrong
20:19:56 <dims> how about the other groups like the LCOO folks?
20:20:00 <dhellmann> 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 <ttx> dims: forum is everyone <-> everyone
20:20:15 <flaper87> johnthetubaguy: ^
20:20:25 <dims> yep
20:20:34 <johnthetubaguy> flaper87: ?
20:21:15 <ttx> OK, anything else on that topic ?
20:21:33 <dims> 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 <ttx> dims: I'd like the person who drives the discussion to post something at the end to the ML
20:21:56 <johnthetubaguy> dims: my reviewing of existing ideas is where we have seen the most success
20:21:56 <ttx> to extend the discussion
20:22:05 <ttx> I see Forum discussions as the start of a long story
20:22:06 <johnthetubaguy> yeah, basically what ttx said
20:22:12 <EmilienM> ttx: yes
20:22:37 <ttx> which is why the ops email frames it as "the start of the Queens cycle"
20:22:44 <dims> right ttx johnthetubaguy
20:22:45 <EmilienM> ttx: that can be transformes in specs in WGs or Community Goals for example
20:22:52 <EmilienM> transformed *
20:22:54 <mordred> yah
20:22:58 <mordred> EmilienM: ++
20:22:59 <fungi> would be especially nice if representatives of the relevant dev teams were there to receive feedback, of course
20:23:06 <ttx> EmilienM: in time for being prioritized at the start of thde dev cycle 3 months later, yes
20:23:11 <johnthetubaguy> yeah, it has to be two way converation
20:23:15 <johnthetubaguy> a debate
20:23:22 <dims> fungi : right
20:24:14 <mordred> 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 <fungi> 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 <mordred> 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 <mordred> :)
20:24:56 <ttx> Not just ops. I'd like to see API users there too
20:25:08 <mordred> 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 <mordred> ttx: wait - what? we want to hear from API users?
20:25:21 <fungi> "the people who actually install and run your software put down their torches and pitchforks for a moment and said..."
20:25:23 <ttx> mordred: shocking I know
20:25:24 <clarkb> mordred: we can show up with API user hats on
20:25:36 <mordred> clarkb: we need actual API user hats
20:25:41 <mordred> that would be awesome
20:25:57 * dtroyer makes a note...
20:26:02 <ttx> OK, I think we have enough to make process here... proposing we switch to next topic
20:26:03 <dhellmann> fungi : let's not get ahead of ourselves by expecting them to put the torches down
20:26:09 <fungi> fair enough ;)
20:26:11 <johnthetubaguy> ttx: I am curious, how are we recruiting those API user folks?
20:26:27 <johnthetubaguy> totally want more of that representation
20:26:30 <mtreinish> johnthetubaguy: that's a good question, I've very rarely heard from api users directly
20:26:33 <ttx> johnthetubaguy: there are a number of tracks targeted to app developers at the summit
20:26:35 <jbryce> the infra team is one of the best examples in the world
20:26:36 <mtreinish> well except for mordred, but meh :)
20:26:50 <fungi> johnthetubaguy: dfflanders is trying to find them from the foundation side too
20:26:54 <ttx> By having a "Forum" that is not specifically branded "ops" or "devs" I hope to attract them
20:26:59 <dtroyer> johnthetubaguy: we hear from them occasionally in -sdks
20:27:02 <dims> mtreinish : lol
20:27:09 <fungi> johnthetubaguy: tracking down and engaging with api users turns out to be challenging
20:27:21 <johnthetubaguy> dtroyer: ah, good point, not sure that gets down to the project much, some of that is good
20:27:25 <ttx> One of the issue with the old branding is that it encouraged separation
20:27:29 <fungi> we mostly just get the ones wo show up to engage with us instead
20:27:40 <jbryce> 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 <johnthetubaguy> fungi: +1, I am glad we restarting that effort
20:28:07 <mordred> jbryce: we should make a big flashing sign "this way lovely API users"
20:28:10 <fungi> yea, all leads appreciated
20:28:12 <ttx> OK, we have a bit more to cover, so let's switch topics
20:28:18 <ttx> #topic Board + TC workshop & TC visioning day in Boston next week
20:28:20 <johnthetubaguy> we should have an API users feedback rant session maybe? and direct them there in the keynote?
20:28:21 <johnthetubaguy> (clutches as straws)
20:28:32 <dhellmann> ttx: +UC, right?
20:28:36 <ttx> we can come back to Forum brainstorming in open discussion at the end, time permitting
20:28:39 <ttx> Next week we'll have a board + TC + UC workshop in Boston to try to tackle difficult strategic questions
20:28:45 <ttx> dhellmann: yes, title typo
20:28:56 <johnthetubaguy> ttx: do we have a list of the topic in advance?
20:28:57 <ttx> I had reservations that a 30+ people workshop could lead to anything useful...
20:29:07 <ttx> but Allison Randall, Alan Clark and Mark Collier worked on a workshop structure that could lead to constructive results
20:29:29 <ttx> johnthetubaguy: I can ask Alan to publish something yes
20:29:42 <ttx> Event logistics @
20:29:46 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2017-February/001338.html
20:29:55 <fungi> johnthetubaguy: from what i gather it's at least partly following that etherpad we've all been collaborating on
20:30:10 <johnthetubaguy> ttx: that would be awesome, given how I think
20:30:11 <johnthetubaguy> fungi: ack
20:30:20 <fungi> but i agree specific agenda items would be nice
20:30:25 <AlanClark> The agenda is on the wiki:https://wiki.openstack.org/wiki/Governance/Foundation/8Mar2017BoardMeeting
20:30:44 <AlanClark> that has links to the etherpads that you just referenced
20:30:46 <dhellmann> #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 <dims> thanks AlanClark
20:31:12 <fungi> thanks AlanClark!
20:31:13 <ttx> 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 <ttx> Makes the travel a bit more worthwhile
20:31:32 <ttx> It will be driven by instructor(s) from ZingTrain, and Colette should be there too.
20:31:44 <ttx> 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 <ttx> Or we can all crash dims's house
20:32:19 <ttx> tempting I know
20:32:20 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Governance/Foundation/8Mar2017BoardMeeting
20:32:26 <dims> :)
20:32:37 <fungi> i gather the kimpton (zero-nine?) overlooking the burying ground is pretty neat too
20:32:54 <ttx> neat but slightly more expensive :)
20:33:10 <ttx> Questions on that event ?
20:33:26 * mordred waves at AlanClark
20:33:34 <ttx> I'll be arriving on Tuesday afternoon and departing late Thursday
20:34:27 <dhellmann> is anyone else going to be around for dinner Thursday evening?
20:34:37 <dtroyer> o/
20:34:39 <mtreinish> dhellmann: my plan is to drive up tues. and head out fri morning. I assume sdague is riding with me
20:34:42 <thingee> dhellmann: o/
20:34:51 <mtreinish> so we'll likely both be around
20:35:03 <dims> dhellmann : i should be able to make it
20:35:08 <dhellmann> great, it sounds like we'll have several folks
20:35:17 <ttx> ok, if no more questions let's move on to next topic
20:35:17 <fungi> i'm around, not departing until friday morning
20:35:49 <ttx> #topic Deprecate postgresql in OpenStack
20:35:53 <ttx> #link https://review.openstack.org/427880
20:36:00 <ttx> sdague is not around, so quick update on that
20:36:09 <ttx> This was mentioned last week at PTG in the context of the "base services" discussion at the Arch WG
20:36:19 <ttx> Looks like one good way of approaching base services is to start with a set of viable options
20:36:26 <ttx> ... delivering basic functionality that happens to be the common denominator
20:36:35 <ttx> Then once the market picks a winner, we contract to that and start using more advanced features from that specific implementation
20:36:51 <ttx> This review discussion shows that for databases we may be approaching the point where contraction makes sense
20:37:03 <ttx> But for it to make sense we'd have to have MySQL-specific features we'd like to take advantage of.
20:37:18 <ttx> The main issues raised (on the review) are around different defaults and behaviors that the abstraction is not really hiding
20:37:33 <ttx> 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 <ttx> 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 <ttx> And if after this discussion they still don't, then it may make sense to proceed
20:38:18 <ttx> Thoughts ?
20:38:19 <johnthetubaguy> I think the key problem is signalling we need more help to keep PostgresSQL supported
20:38:20 <dhellmann> 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 <johnthetubaguy> turned away, why?
20:38:47 <dtroyer> dhellmann: I think it may take more now than in the past to convince us that the help is long-term
20:38:57 <ttx> dhellmann: why ? I still haven't seen a clear feature we'd start suing tomorrow in MySQL
20:38:58 <thingee> dtroyer: ++
20:39:01 <ttx> using*
20:39:19 <dhellmann> 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 <fungi> 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 <johnthetubaguy> 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 <dhellmann> ttx: no, I haven't seen anything either, that's why I'm concerned
20:39:50 <thingee> fungi: ++ we're doing a disservice by claiming otherwise
20:39:53 <mtreinish> johnthetubaguy: at least it has in the past
20:39:55 <dhellmann> fungi : yes, we need to be more careful there
20:40:00 <ttx> 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 <johnthetubaguy> fungi: +1 I think a more general statement on support
20:40:34 <johnthetubaguy> 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 <thingee> 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 <ttx> I don't like "support". I prefer to think in terms of base services
20:41:10 <mtreinish> thingee: that's a good question
20:41:20 <gordc> 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 <flaper87> and if there are d/s patches, why those patches have not been pushed upstream
20:41:38 <flaper87> it'd help us understand better the problem
20:41:43 <thingee> flaper87: always a mind blowing question
20:42:01 <dims> who can we ask? -operators ML? how do we reach the downstream folks?
20:42:11 <jroll> 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 <dtroyer> gordc: so it really is not in that bad of shape?  just nobody to quickly jump in when things do happen?
20:42:12 <dhellmann> flaper87, thingee : you're (a) assuming someone is carrying patches that (b) would be accepted upstream. Are those things true?
20:42:16 <fungi> some of them have been weighing in on that resolution proposal
20:42:19 <thingee> dims: sure. we had some public clouds come out and say they're using it
20:42:44 <jroll> the former group of people will continue to say we should drop it, the latter might accept help
20:43:10 <mtreinish> dhellmann: I think the thing is we're not sure about a)
20:43:13 <gordc> 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 <ttx> jroll: actually 3 sides, as I mention in my review comment
20:43:15 <flaper87> 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 <thingee> 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 <johnthetubaguy> for me its more about timely feedback loops, than extra patches
20:43:40 <dhellmann> 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 <ttx> thingee: that said, we should try to bring them back in the fold, rather than isolate them
20:43:43 <dims> right thingee
20:43:46 <jroll> ttx: ah yes, fair
20:43:51 <johnthetubaguy> now the extra patches do slow down the feedback loops
20:43:57 <flaper87> 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 <thingee> 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 <flaper87> to understand if we have a technology problem, a community problem or what else
20:44:16 <dhellmann> thingee : ok, well, if we can't go on the record here I don't know how we address their concerns.
20:44:18 <thingee> ansible, shade, etc
20:44:48 <gordc> 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 <smcginnis> gordc: For now.
20:45:09 <ttx> 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 <dhellmann> 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 <johnthetubaguy> yeah, that would change quickly
20:45:31 <gordc> smcginnis: right. :)
20:45:38 <dhellmann> 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 <mordred> 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 <johnthetubaguy> 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 <dhellmann> johnthetubaguy : what problem do we have?
20:46:17 <mordred> 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 <thingee> 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 <ttx> mordred: ok
20:46:39 <johnthetubaguy> dhellmann: it keeps breaking, and we need help to keep that working and passing
20:46:45 <mordred> 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 <dhellmann> 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 <mtreinish> thingee: we turned off the postgres jobs in the integrated gate a while ago
20:47:20 <thingee> mtreinish: exactly
20:47:23 <johnthetubaguy> 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 <mordred> 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 <thingee> 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 <fungi> ceilo was still running _a_ job that relied on pgsql until very recently tough, so that much at least was working
20:47:54 <thingee> as dtroyer has pointed out
20:48:01 <fungi> s/tough/though/
20:48:11 <mordred> 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 <ttx> mordred: basically I want to point out direct operational gains, rather than indirect development / maintenance gains
20:48:25 <mordred> ttx: right. these are direct operational gains
20:48:31 <mordred> ttx: that we cannot develop as developers
20:48:32 <ttx> so that the pain we introduce on the operational side is compensated by other operational gains
20:48:50 <thingee> 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 <rockyg> 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 <mordred> 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 <dhellmann> rockyg : good point
20:49:22 <johnthetubaguy> well its about where the options really help or not, vs how much we can help folks
20:49:59 <thingee> 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 <ttx> 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 <mordred> ttx: totally. I honestly could not care less about dev convenience here
20:50:27 <mordred> not that I don't like devs
20:50:44 <gordc> can we maybe shrink/split review... and start by removing any explicit 'postgresql is supported' text from docs?
20:51:09 <mordred> I care more that we're literally held back from making more easily operatable things because of the split
20:51:12 <fungi> yeah, if we're not testing it today, it's disingenuous to have documentation implying it's a supported option
20:51:15 <ttx> we'll need to re-propose this as a patch to base-services.rst anyway
20:51:22 <dhellmann> 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 <thingee> fungi: ++
20:51:38 <dhellmann> because if we don't say either, we're just encouraging folks to carry patches on their own
20:51:38 <dtroyer> gordc: like johnthetubaguy's recent (~2 hours old) comment splitting into three things?
20:51:39 <thingee> I would say at this point, we say it's not
20:52:00 <mordred> 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 <dhellmann> thingee : so what's the migration story for all of those deployments currently using it?
20:52:18 <gordc> dtroyer: didn't read patch recently. will take a look
20:52:29 <ttx> 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 <mordred> (albeit at a very real cost to a subset of the existing operators - which is why it's a difficult conversation)
20:52:34 <rockyg> 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 <dhellmann> ttx: the moment any application introduces mysql-specific logic somewhere, they will break all postgresql deployments.
20:52:57 <thingee> 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 <rockyg> If the community doesn't come forward, well, they don't want it all that much
20:53:03 <mordred> 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 <thingee> dhellmann: I think it sucks from our perspective too that there is no support
20:53:15 <ttx> 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 <ttx> today they likely already do
20:53:39 <ttx> since they are not CI-tested
20:53:48 <ttx> they can be broken at any time
20:54:18 <ttx> (not saying I agree, just unfolding the decision completely)
20:54:22 <mordred> 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 <ttx> Anyway, sounds like a great side topic for our meeting next week :) Please continue debate on the review / ML thread
20:54:51 <mordred> that we could stop installing postgres in the gate is not really a win that is worth anyone's pain
20:55:06 <ttx> #topic Open discussion
20:55:25 <ttx> We'll skip TC meeting next week as most will be traveling to Boston
20:55:27 <EmilienM> imho, what is not Ci-tested shouldn't be supported
20:55:43 <EmilienM> ttx: sounds good
20:55:57 <ttx> EmilienM: I think we need to stop saying "supported" as it is a bit misleading
20:56:10 <EmilienM> ttx: also that yes :)
20:56:17 <johnthetubaguy> ttx: we totally need to define what we mean by that (or not as the case maybe)
20:56:21 <ttx> I prefer to reuse the language in base services. "Components can assume the presence of..."
20:56:34 <ttx> which is the same without the implications of commercial support
20:56:41 <johnthetubaguy> people use the phrase either way, I think we need to say what it means
20:56:45 <fungi> (or even volunteer support)
20:56:51 <dims> EmilienM : rockyg : if we do have third party CI which project(s) will they report success/failures to?
20:56:58 <johnthetubaguy> fungi: yeah, thats a good way to say what we have
20:57:00 <dhellmann> ttx: in this case, mordred seems to be making the case for "Components can assume the absence of Postgresql"
20:57:28 <ttx> dhellmann: I think we'd keep oslo.db as the abstraction
20:57:53 <dhellmann> oslo.db just gives you a connection, right? it doesn't prevent you from then doing db-specific things with it.
20:57:56 <fungi> 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 <dims> 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 <dhellmann> it's not a full abstraction layer
20:58:06 <ttx> we also should not reject patches that make postgresql work, if that doesn't break MySQL
20:58:23 <dims> ttx : until when?
20:58:36 <dhellmann> 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 <dims> agree dhellmann
20:58:53 <johnthetubaguy> ttx: the problem is understanding and validating those patches without CI
20:58:56 <ttx> dims: It provides a useful abstraction for narrow use cases that want to plug another DB type (at their own risk)
20:59:15 <fungi> 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 <johnthetubaguy> dhellmann: +1 for the more honest statement
20:59:36 <johnthetubaguy> fungi: +1
20:59:39 <dhellmann> 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 <fungi> johnthetubaguy types faster than i do ;)
20:59:42 <dims> fungi : indeed
20:59:58 <dhellmann> fungi : +1, we also don't want some projects accepting them and others rejecting them
21:00:01 <dims> we get to rid the bandaid slowly...
21:00:07 <dhellmann> at least not arbitrarily
21:00:18 <dims> s/rid/rip/
21:00:45 <dhellmann> if a team wants to keep supporting pg, that's fine
21:00:48 <ttx> alright, time is up
21:00:49 <bswartz> 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 <EmilienM> ttx: thanks for chairing!
21:01:05 <ttx> #endmeeting