20:00:59 <smcginnis> #startmeeting tc
20:01:00 <openstack> Meeting started Tue Jun  6 20:00:59 2017 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:03 <openstack> The meeting name has been set to 'tc'
20:01:06 <mriedem> o/
20:01:08 <EmilienM> o/
20:01:17 <dims> o/
20:01:18 <mriedem> so, DB2...
20:01:25 * edleafe finds a comfy seat
20:01:26 <smcginnis> Welcome to the special PostgreSQL edition of the TC meeting. :)
20:01:31 * edleafe smack mriedem
20:01:31 * smcginnis laughs at mriedem
20:01:32 * dims kicks mriedem out
20:01:36 <sdague> o/
20:01:41 <smcginnis> Agenda is here:
20:01:44 <smcginnis> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:46 <fungi> fun stuff
20:01:52 <smcginnis> Scroll down to Next Meeting
20:02:06 <cdent> o/
20:02:12 <smcginnis> #topic Declare the current state of Postgresql in OpenStack
20:02:15 <dtroyer> o/
20:02:49 <sdague> are we at quorum?
20:03:14 <dtroyer> I count 7
20:03:29 * rockyg hands mriedem a lollipop and says "there, there"
20:03:32 <smcginnis> Yep, looks like we've reached quorum, right?
20:03:47 <sdague> dtroyer: mriedem isn't TC, though his opinion is valued
20:03:56 <smcginnis> Welll...
20:04:01 <smcginnis> :)
20:04:02 <dtroyer> I didn't count him
20:04:08 <sdague> ok, I'm failing at math
20:04:25 <dhellmann> o/
20:04:28 <sdague> sdague, dtroyer, smcginnis, fungi, cdent, EmilienM
20:04:34 <sdague> ah, dhellmann == quorum :)
20:04:41 <dtroyer> dims
20:04:42 <smcginnis> And dims
20:04:45 <dims> sdague : am here too, fighting network issues
20:04:45 * dhellmann feels useful
20:04:47 <sdague> oh, damn
20:04:49 <smcginnis> :)
20:04:54 * dhellmann feels less useful now
20:04:59 <sdague> I should go back to camping
20:05:10 <dtroyer> ++ moar camping for everyone
20:05:15 <smcginnis> sdague: Good life lesson in general.
20:05:15 <sdague> ok, shall we begin?
20:05:18 <rockyg> ++
20:05:26 <smcginnis> SO cdent pulled together a nice post with links
20:05:29 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/117921.html
20:05:48 <smcginnis> We've have had a few lengthy discussions on the ML
20:05:57 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html
20:06:09 <fungi> sdague: i had already piped up earlier, but yes, here
20:06:16 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117148.html
20:06:42 <smcginnis> And we have a couple proposals up to how we want to approach this:
20:06:44 <smcginnis> #link https://review.openstack.org/#/c/427880/
20:06:53 <smcginnis> #link https://review.openstack.org/#/c/465589/
20:07:19 <smcginnis> I am your impartial moderator today ss, go....
20:07:27 <smcginnis> *so
20:07:57 <dhellmann> before we start on the proposals, can someone clarify for me whether we have answered the question of if we *want* to support postgresql?
20:08:15 <dtroyer> after a bit of a break, I think dhellmann's question in todays last comment on https://review.openstack.org/#/c/465589/ would be a good place to start
20:08:16 <sdague> dhellmann: I don't think that's a settled question
20:08:21 <dtroyer> and hetypes faster than I do :)
20:08:26 <dhellmann> right, so I think that's where we need to start
20:08:31 <sdague> dhellmann: is it?
20:08:55 <mriedem> we talked about that at the summit,
20:08:56 <smcginnis> dhellmann: There certainly are some who *want* it supported. So maybe discuss around what that means in this context.
20:08:58 <dhellmann> well, we could do the "this isn't well supported" comment thing, but the rest of the stuff about asking for help doesn't make sense if we're going to reject it
20:09:03 <dtroyer> a) we don't support is not up to mysql-par; b) we should document that; c) then what?
20:09:20 <mriedem> i think at the summit we could all agree on actually documenting the current state of htings
20:09:21 <mriedem> *things
20:09:26 <mriedem> which is why we have the two proposals to do that
20:09:29 <sdague> dhellmann: I agree that asking the board for assistance here seems like a weird ask (from cdent's proposal)
20:09:40 <dhellmann> so even cdent's draft would have to change to drop that part
20:09:54 <dhellmann> and if that's all we're going to do now, someone could just go write the doc patch
20:10:00 <sdague> because even if we did want to support this, I don't think it would be in the top 20 things we'd ask board support for
20:10:06 <dhellmann> right
20:10:14 <cdent> the reason I included that is because my understanding, from summit, was that _if_ we want to indicate a path forward, then we need to indicate that getting support from "vendors" is something we need
20:10:29 <smcginnis> How about this - 1) do we agree we should document the current state, then 2) discuss what the future state should be?
20:10:37 <fungi> deciding whether we (who is "we" in this sense) want to support it first assumes we know what we mean when we say "support"
20:10:37 <dhellmann> yeah, but we don't want to ask for help on this if we don't want it, so we should decide about that before we ask for help
20:10:48 <cdent> I think sdague's most recent comment about "top 20" is essentially the same as dhellmann's question: do we want it
20:10:53 <smcginnis> I'd like to focus on 1 first here, as I think leaving its state ambiguous isn't helpingn anyone.
20:11:00 <sdague> smcginnis: I agree
20:11:01 <dirk> sdague: but are we really talking about postgresql specifically or "any sqlalchemy/oslo.db supported sql vs mysql family only" ?
20:11:03 <dhellmann> smcginnis : +1
20:11:06 <cdent> I wrote the alternative as a way of saying "if we want it, here's a way to say that"
20:11:11 <fungi> like does it mean that there are some set of people who have volunteered to be postgresql subject matter experts within the community?
20:11:18 <sdague> so in the proposal https://review.openstack.org/#/c/427880/7/resolutions/20170201-postgresql-status.rst there are 3 concrete actions
20:11:23 <dirk> sdague: isn't postgresql the guinea pig of making sure that the stuff is reasonably portable accross no-matter-what db?
20:11:35 <sdague> 1) document that it is less supported
20:11:47 <dhellmann> fungi : we need to say something clearly like "projects should accept patches to maintain postgresql support" or "projects do not need to maintain postgresql support after they have provided a migration path off of postgresql onto mysql"
20:11:48 <sdague> 2) see what a transition would look like / cost (as there is a team doing that)
20:12:12 <dims> good plan of attack
20:12:13 <sdague> 3) figure out how the board can give us vendor based usage data that's not coming through in the survey
20:12:37 <sdague> so, I guess I want to figure out if those 3 actions are +1/-1 from folks
20:12:48 <sdague> then, there is disagreement about preamble
20:13:00 <sdague> and we can figure out what's the deal breakers there
20:13:01 <mriedem> i'm +1 on those 3 actions fwiw
20:13:06 <mriedem> but just a lowly pawn
20:13:19 <mriedem> and was my takeaway from the summit session
20:13:20 <fungi> dhellmann: thanks. i'm squarely in the "we (the tc) should not require projects to accept or maintain patches which implement support for databases they don't feel like using" camp
20:13:27 <dhellmann> mriedem : well, you rep a vendor that uses postgresql, right?
20:13:31 <EmilienM> +1
20:13:35 <smcginnis> SO can we get a show of hands - who backs 1 above?
20:13:38 <mriedem> dhellmann: i do
20:13:48 <dims> o/
20:13:58 <dhellmann> smcginnis : do you want to use #vote to keep track?
20:14:00 <fungi> #1 seems fine to me
20:14:08 <smcginnis> dhellmann: Would that be better?
20:14:11 <dtroyer> ++ #1
20:14:13 * dhellmann shrugs
20:14:25 <dhellmann> I support option 1
20:14:50 <dtroyer> at this point I think we're looking for opposition to any of those three?
20:14:50 <sdague> we're pretty light in terms of TC membership today, so this is more about sorting out what we think the final proposal should look like
20:14:51 <mriedem> +1 to #1 (documenting the <first class support)
20:15:00 <smcginnis> dhellmann: Was thinking just semi-informal, but maybe that would help make it more official.
20:15:01 <dhellmann> sdague : good point
20:15:10 <dhellmann> smcginnis : oh, no, I just meant so you didn't have to count :-)
20:15:25 <sdague> so, right, I think the important point is to figure out if anyone objects to any of 1, 2, 3 that's in attendance
20:15:29 <smcginnis> sdague: Final proposal as far as pg support, or final proposal as to hwo we are going to document it?
20:15:30 <dhellmann> sifting through the usual level of chatter might have been hard, but we seem to be well-behaved today
20:15:40 <sdague> smcginnis: final version of whatever this is
20:15:45 <cdent> I half-object to #2
20:15:59 <sdague> cdent: ok, because?
20:16:09 <fungi> #2 just seems like collecting data
20:16:12 <dims> sdague : i support all 3 points above
20:16:17 <dims> and options fungi
20:16:45 <mriedem> cdent: isn't #2 also in yours?
20:16:49 <fungi> though i guess collecting information on an option could imply that we consider it a possibility and give false hope where there maybe should be none
20:16:56 <cdent> I think we should do #1 but not do #2 because it implies that we don't want postgres and I think that's a backwards step, from my perspective. I can live with it, so I won't vote against it or anything, but I do think it represents a contrary to what we're trying to do
20:17:18 <cdent> mriedem: yes, but I don't really want that one
20:17:19 <sdague> cdent: that seems very odd to me
20:17:29 <cdent> I would have written a much string alternative if it was just me
20:17:32 <dhellmann> fungi : I believe the SUSE folks are planning to migrate regardless of the outcome, and they're doing that research.
20:17:43 <mriedem> cdent: confused - it's your change :)
20:17:43 <sdague> because I can't imagine actually deciding to deprecate and remove pg without knowing the cost to current users
20:17:47 <fungi> dhellmann: right, i knew what it was a reference to
20:18:10 <cdent> I think I've made it pretty clear throughout this process that I think supporting multi-dbs is a first class goal: a sign of correctness and maturity
20:18:33 <rockyg> cdent, ++
20:18:44 <sdague> cdent: ok, so because of that it's not possible to understand alternatives?
20:18:51 <cdent> I wrote the shortened version of the document to see how people would react to a simpler expression of what was effectively the goals that sean expressed, but without all the stuff about mysql itself
20:19:11 <mriedem> #2 is all fact finding i thought - if it's prohibitively expensive to migrate from pg to mysql
20:19:24 <fungi> but i can understand if officially seeking input on the costs of transitioning and then deciding to stick by the lack of support anyway in light of that information could lead some to think that we didn't really want the information and were simply paying lip service
20:19:29 <cdent> sdague: it is fine to investigate the path, but it is wasted effort if we never choose to take it
20:19:32 <cdent> and I don't think we should take it
20:19:37 <sdague> cdent: it's not even our effort
20:19:42 <sdague> the suse team is already doing it
20:19:43 <cdent> so why waste the effort when there is so much else to do?
20:19:54 <cdent> the suse team is as much as anyone else
20:19:55 <sdague> basically it's just whether or not we want to supress the info
20:19:58 <dhellmann> what if we phrase that one as "do nothing else until the suse team reports back"
20:20:07 <cdent> and if they do it, we can still benefit from the info without having legislated it
20:20:17 <cdent> legislating it indicates encouragement
20:20:26 <dtroyer> suse made a business decision to spend $$$/time on that, ignoring that information seems a waste
20:20:26 <cdent> dhellmann: as i said: I'm okay with that
20:20:33 <fungi> and/or implies that it will influence the decision when it may not
20:20:37 <cdent> I don't think we should ignore the information
20:20:58 <cdent> I simply think that these resolutions shape future direction: they are politics
20:21:02 <sdague> well, it wasn't until we asked about it did they volunteer that they were doing it anyway, and could do it in the open
20:21:24 <smcginnis> I do think it's a good data point to have, but I agree with the direction cdent is going in that we should decide, regardless of that effort, if we should strive for DB abstraction as a tenet.
20:21:25 <cdent> and I think our politics should say: we would like to support many databases, but right now it is hard, halp
20:21:26 <rockyg> Why not "accept info from outside sources on costs of transitioning, etc?
20:22:06 <cdent> rockyg: I'd be fine with that too
20:22:11 <sdague> cdent: right, and I think that's where we disagree about that being a priority in OpenStack
20:22:16 <sdague> which was dhellmann's question
20:22:17 <cdent> sdague: yes
20:22:18 <dtroyer> so then re-work #2 and #3 to be about collecting information about transition, usage, cost of support, whatever...
20:22:19 <cdent> yes
20:22:23 <dhellmann> now we're back to where i suggested we start
20:22:25 <cdent> yes
20:22:26 <cdent> :)
20:22:28 <sdague> dhellmann: right
20:22:32 <sdague> dhellmann: but we aren't going to agree there
20:22:42 <rockyg> and along with transition costs, if anyone wants to provide costs of maintaining the abstraction would be nice.
20:22:43 <sdague> like, litterally aren't going to get to concensus
20:23:07 <sdague> rockyg: right, that's what I tried to put into the preamble
20:23:10 <cdent> we are already maintaining the abstraction, we just don't test enough to be confident
20:23:19 <cdent> so the one single thing we need to do, and then we could stop, is adjust the docs
20:23:25 <cdent> we don't _need_ to do more
20:23:29 <cdent> but we have an opportunity to do so
20:23:30 <dhellmann> so then I guess we do 1 and 3 and drop 2? or will people who want to retain pg support sign off on option 2?
20:23:40 <cdent> to answer the question about what we want
20:24:43 <fungi> i'm still unclear on what "support" means in this context. as the tc we're not going to insist that projects work with specific databases right? (or do we already say that they must support mysql even if it makes no sense for their particular data model?)
20:24:57 <fungi> memories of mongodb debates from years past
20:25:19 <mordred> we have forced projects to have a sqla driver
20:25:25 <dhellmann> I think the idea is for us to clearly say whether postgresql counts as "a database" in our base layer
20:25:35 <dhellmann> or "a relational database"
20:25:47 <mriedem> base layer? whoa whoa whoa, that sounds too much like core to me...
20:25:49 <mriedem> alert alert
20:25:59 <dhellmann> or if we're going to contract that, to just say mysql-like databases
20:26:08 <dhellmann> mriedem : you're reading my lines
20:26:13 <dims> :)
20:26:14 <fungi> mriedem: the base services list (database, message queue, et cetera)
20:26:15 <mordred> mriedem: I think he means "the things we assert all openstack services can depend on being there"
20:26:35 <dhellmann> https://governance.openstack.org/tc/reference/base-services.html?highlight=base
20:26:37 <dhellmann> #link https://governance.openstack.org/tc/reference/base-services.html?highlight=base
20:26:54 <mriedem> i'm not really serious, sorry about that one
20:26:56 <sdague> dhellmann: and I don't think that there is concensus there. There is one camp that believes that sqla should be a good enough abstraction for everything.
20:27:01 <dims> dhellmann : don't think we are ready to state that right now
20:27:07 <mordred> I'd go one further
20:27:27 <sdague> There is another camp that would like to be pushing what we do with the db for user experience, like the zero downtime keystone story
20:27:36 <sdague> those are trade offs
20:27:55 <mordred> there is a camp that believes an abstraciton layer is a positive goal that is a mark of maturity and quality (what cdent said) and a camp that maintains that large systems tend to target one backend
20:28:01 <mriedem> sdague: but can that be done for mysql and if you don't use mysql and are willing to tolerate not having 0-downtime upgrades with postgresql, that's on you?
20:28:04 <dhellmann> there isn't consensus there now, but I thought that was the whole point of this even coming up?
20:28:07 <mordred> we don't even have consensus on that
20:28:17 <sdague> mriedem: that's where I'd be fine being
20:28:22 <mriedem> sdague: me too
20:28:30 <mriedem> there is all sorts of crap you can't do with nova api if you're not using libvirt
20:28:34 <sdague> in which case we need to be ok that not all dbs are equal
20:28:42 <dhellmann> that seems ok to me
20:28:42 <sdague> as steady state
20:28:47 <dhellmann> maybe we have more of a consensus than we thought?
20:28:52 <cdent> mordred: i'm only saying that in terms of using an rdbms. I don't think all the projects should use an RDBMS or even the same RDBMS. It's just that if you do, it's "nice" to give the deployer choice.
20:28:55 <fungi> i guess i'm just wondering if there's an option for saying "we test these services against mysql, and if you want to try with something else it may work but we won't guarantee (or force) projects to accept fixes to make that possible for you" and leave it at that
20:28:57 <mriedem> i'm totally fine with the carrot approach
20:29:07 <sdague> dhellmann: maybe, cdent how do you feel on that?
20:29:37 <mordred> cdent: I totally understand and can respect that point of view, and agree with it to a certain scale. but past a certain scale I believe an abstraction layer is actually a detriment not a benefit
20:29:46 <mriedem> fungi: i'm also good with that - we have a pg dsvm/tempest job in the integrated-gate experimental queue so it's not like we can't run stuff through it
20:29:46 <dhellmann> fungi : if we're going to be that loose, we should ask projects that reject dbs other than mysql to clearly state that. Otherwise, we need to tighten it up and tell project teams that they do need to accept patches to maintain non-mysql support.
20:29:53 <dhellmann> modulo review, quality, etc.
20:29:57 <dhellmann> they can't reject the patch out of hand
20:30:26 <mordred> so it depends on how well we want to support the "massive scale" part of our mission, imo. that said, I can totally live with the mriedem / sdague description above
20:30:37 <cdent> sdague: mostly? I agree that it is okay to say "we test most robustly using X" but I have some issues with "you only get desirable feature if you use X" (thinking in this case of the reliance on triggers in keystone (something I don't actually have enough info to comment fully on))
20:30:40 <cfriesen_> fungi: I'm a little apprehensive about saying that projects can reject patches just because they're there to make postgres work
20:30:53 <fungi> i'm on the fence about whether it's productive to tell projects what kinds of patches they should or can't accept, outside of those which are clearly beyond their scope, legally risky, et cetera
20:31:07 <mordred> I think we need to be super clear in docs about what does and doesn't work out of the box, and also to try to find the places where db impl is leaking through the API and define that behavior better
20:31:08 <dhellmann> cdent : graceful degradation until someone provides the patches to make it do otherwise?
20:31:39 <fungi> cfriesen_: projects already have the leeway to reject all sorts of other patches without us telling them they can
20:31:58 <cdent> dhellmann: At this stage that seems like we could hope for
20:32:08 <sdague> projects prioritize patches on a ton of different grounds, I honestly think that trying to put rules around "you have to accept alternative dbs" seems weird. We did some many slightly nutty things for db2 that was all a waste of people's time
20:32:08 <smcginnis> fungi: But rejection based on an overall policy is a little different.
20:32:11 <dhellmann> fungi : the tc is the last stop for resolving these sorts of conflicts. sometimes we do need to make those sorts of statements to avoid conflicts elsewhere.
20:32:18 <dirk> fungi: isn't the question rather whether openstack infra would provide hosting of a postgresql gate for a particular project? it is not worthwhile to tell a project to accept cross-db support patches if we"re not going to provide testing capability for them
20:32:24 <mriedem> sdague: slightly nutty?
20:32:37 <sdague> mriedem: all those null key migrations
20:32:37 <mriedem> we put a unique constraint on a unique column...
20:32:42 <mordred> dirk: I do not believe infra would do anything to prevent pg support in the gate
20:32:58 <mordred> pg is an open source database. job content is job content.
20:33:01 <mriedem> dirk: we already have that
20:33:07 <fungi> dirk: anyone can apt-get install postgresql in a job. there's nothing for "infra" to support in that regard and i'm happy if people want to test it (official openstack projects or otherwise)
20:33:11 <mriedem> dirk: it's in the experimental queue for all integrated-gate jobs
20:33:12 <mordred> fungi: ++
20:33:16 <sdague> dirk: right, any open source stuff has been welcome in the gate in various efforts
20:33:19 <mriedem> er projects that use the integrated-gate jobs
20:34:00 <dirk> thanks, so the summary is "we welcome projects to test against postgresql but don't require it going forward"
20:34:16 <smcginnis> I'd like to see if we can go back to the first thing and see if there is agreement that at a minimum for now, we at least document the state of non-mysql support.
20:34:20 <dirk> well, it could be one of the summarys. sorry
20:34:37 <mriedem> smcginnis: i think we're all agreeing on docs
20:34:52 <dhellmann> smcginnis : yes, I think we all agreed on that.
20:34:54 <dtroyer> smcginnis, mriedem: ++
20:34:59 <sdague> so... agreed thus far is 1 & 3 in the action list
20:35:03 <sdague> ?
20:35:08 <smcginnis> Then the question comes to which of the porposals are we most OK with?
20:35:14 <smcginnis> For docs.
20:35:26 <fungi> dirk: i think that's where my personal preference lies, but willing to compromise if the rest of the community has conflicting needs in that regard
20:35:42 <mriedem> smcginnis: i think both say basically the same thing
20:35:44 <mriedem> put warnings in the docs
20:35:59 * EmilienM is very sorry and has to drop off for family reasons (22.35pm here)
20:36:06 <smcginnis> EmilienM: thanks!
20:36:07 <fungi> g'night EmilienM
20:36:34 <smcginnis> cdent: Did you have concerns about the first of the two docs patches?
20:37:18 <smcginnis> Or did we now lose quorum?
20:37:20 <cdent> smcginnis: ?
20:37:28 <dims> still here..
20:37:45 <mriedem> i had a clarification question on docs in cdent's patch
20:37:52 <rocky_g> dhellmann, made it eight, so down one leaves 7
20:37:54 <mriedem> but i think both say the same thing
20:37:57 <smcginnis> cdent: There are the two proposed docs patches. There was a reason for creating the second one out of a valid concern, correct?
20:38:10 <smcginnis> rocky_g: thanks!
20:38:14 <cfriesen_> the most recent version of sdague's is quite a bit different from the original verison, I think
20:38:25 <cdent> smcginnis: you're talking about the two different proposals from me and sean or something else?
20:38:42 <sdague> cfriesen_: yeh, I was really trying to capture what I thought was concensus out of the session in Boston
20:38:43 <smcginnis> cdent: Yes, sorry, your vs sdague's/
20:39:26 <smcginnis> If we all agree we need it documented, and the first patch (sdague's) is now updated to be more acceptable, can we abandon the second one and at least get that out of the way.
20:39:30 <dims> apart from verbosity are the two conflicted in any major way? (latest revs)
20:39:42 <dims> smcginnis : i'd support that
20:39:45 <cdent> Yeah, amongst my concerns about sdague's was that it is easy to read as "we really just want to support mysql and that's what we should do" so wrote the second one leaving out all the stuff about mysql (except for that one section) so that it is more about postgresql
20:40:35 <dims> cdent : does it still read that way? (latest rev)
20:40:42 <smcginnis> cdent: Are you now OK with the original patch?
20:40:46 <cdent> I dont' feel strongly enough about it to vote against that proposal but _did_ feel strongly enough to present a different version
20:41:17 <smcginnis> I just see this overall "should we support multiple DBs" taking longer than this meeting, so my hope is we can at least walk away from this with the current state documented and agreed on.
20:41:32 <smcginnis> cdent: OK, sorry to put you on the spot.
20:41:32 <mriedem> maybe propose clarifying wording and -1 sdague's change, and continue to -1 until it's worded how you'd want, but drop the 2nd change so we can focus on one change
20:41:48 <mriedem> or don't, whatever :)
20:41:48 <sdague> I will state that there are definitely folks that don't like the tone which does state mysql* is more supported
20:41:51 <cdent> version seven is still, to me, "let's use mysql" in disguise
20:42:19 <sdague> right, and I think that's where we're eventually going to hit a wall, because there is that split
20:42:31 <dirk> sdague: thats where mordred "s comment comes in : OpenStack is more focused around mysql (rather than saying "support")
20:42:38 <dirk> sdague: and I think that solves the conflict
20:42:56 <dims> cdent : i prefer to lean that way to show that we will pull trigger some time down the road
20:43:02 <sdague> dirk: ok, so maybe a next step would be mordred to redraft that ?
20:43:04 <dirk> "support" is to be avoided unless you want to end up in endless debates, basically
20:43:15 <sdague> dirk: ok, I tried to define support in the last version
20:43:21 <cdent> dims pull which trigger?
20:43:23 <mriedem> dims: what trigger?
20:43:30 <dirk> sdague: I think the current comments on your review just need to be incorporated and then it's good (for me at least)
20:43:31 <cfriesen_> dims: but what if people step up to support postgres?  (which was one of the things mentioned)
20:43:32 <mriedem> the one that kills pg in openstack?
20:43:36 <dims> drop pgsql in 2-3 years
20:43:42 <mriedem> dims: we're not even talking about that
20:43:44 <dirk> sdague: both mordred  and me made concrete wording improvements
20:43:46 <cdent> yeah, exactly, that's why I don't want that version :)
20:43:47 <dims> cfriesen_ : right then we reconsider
20:43:52 <dirk> sdague: in a review comment.
20:43:56 <sdague> I'll also admit, I've done so many iterations and shifts here I'm getting pretty blind on making changes that make sense
20:44:02 <mordred> sdague: I can respin if you like
20:44:05 <dims> lol sdague
20:44:13 <dims> i know it's tough
20:44:14 <sdague> dirk: ok, maybe would you like to intergrate those changes?
20:44:20 <mordred> or dirk can - either way
20:44:31 <sdague> that might make sure we get a balance you are comfortable with
20:45:00 <sdague> and have drafting by someone that's not seen as tainted with a particular POV that I know mordred and I are perceived as
20:45:04 <dims> so we settle down on the sdague governance patch and interate there
20:45:13 <edleafe> Decalring what the current state is, and how we got there, is the part everyone seems to agree on. Seems the differences are on where we move from here
20:45:21 <smcginnis> dims: +1
20:45:22 <mordred> dirk: you ok with taking the next iteration?
20:45:27 <edleafe> Keep going in that direction, or change course
20:45:37 <dhellmann> are we going to keep all 3 steps? or drop it down to just the first one?
20:45:42 <dims> dirk : thanks in advance :)
20:45:44 <dirk> mordred: I can give it a try
20:45:52 <mordred> dirk: awesome!
20:45:53 <smcginnis> #action dirk to update sdague's first documentation patch
20:45:58 <cdent> I think having dirk take a pass is a good idea
20:46:05 <dims> s/documentation/governance :)
20:46:15 <dirk> #undo
20:46:20 <smcginnis> #undo
20:46:21 <openstack> Removing item from minutes: #action dirk to update sdague's first documentation patch
20:46:26 <smcginnis> #action dirk to update sdague's first governance patch
20:46:32 <dirk> thanks :)
20:46:58 <dhellmann> thanks, dirk
20:47:01 <smcginnis> cdent: But you would like to hold on to your alternative?
20:47:01 <dims> k. me switching to partially here mode then
20:47:09 <sdague> thanks dirk
20:47:21 * smcginnis wonders if we technically have quorum then.
20:47:26 <cdent> And I'll say now that I'll comment on dirk's version with my particular perspective (too much mysql!) if it is necessary.
20:47:36 <sdague> cdent: sounds reasonable
20:47:40 <dhellmann> cdent : ++
20:47:43 <dims> thanks cdent
20:47:55 <cdent> I think that seems like the best way to iterate at this point
20:47:56 <smcginnis> cdent: +1
20:48:17 <cdent> smcginnis: since we're not voting we don't really need quorum: we just chattin'
20:48:27 <smcginnis> Oh, true. :)
20:48:32 <sdague> so, the only real remaining sticking bits were whether point #2 / #3 need to be changed around
20:48:36 <smcginnis> Watercooler talk, eh
20:48:43 <sdague> they were captured because of the boston session
20:48:47 <sdague> as things we wanted
20:48:54 <sdague> for different reasons
20:49:03 <dhellmann> I think we're all happy with point 3?
20:49:11 <fungi> i think we may be down to 7 present (me, cdent, dims, dhellmann, mordred, sdague, smcginnis)
20:49:29 <dtroyer> o/
20:49:30 <smcginnis> Only half of a dims though. :)
20:49:32 <cdent> 3 is: work with foundation to get better data of current state of affairs?
20:49:34 <sdague> dhellmann: I have not heard objections to 3
20:49:45 <dhellmann> folks, I don't think we need quorum because we're making an action plan not a final decision
20:49:46 <smcginnis> sdague: +1
20:49:47 <fungi> oh, right, dtroyer's here so long as dims is at least partly here still
20:49:54 <sdague> cdent: yeh, so for instance purp and I had a bunch of conversations out of band on this review
20:50:01 <sdague> and his objections included
20:50:03 * smcginnis notes there will be no voting
20:50:16 <sdague> - we have no idea what switching cost would even be (agree)
20:50:26 <sdague> - the openstack survey is not scientific (also agree)
20:50:27 <smcginnis> Agreed
20:50:44 <dhellmann> those are fair points
20:50:54 <dhellmann> I still think it's OK to point out that the survey could be improved.
20:50:58 <sdague> and the SAP folks in the room did actually say they didn't realize that the survey was used to make decisions
20:51:03 <sdague> otherwise they might have filled it out
20:51:11 <mriedem> ha
20:51:15 <mriedem> btw,
20:51:19 <dhellmann> how many years have we been doing that?
20:51:21 <mriedem> everyone is running cells v1 according to the survey
20:51:24 <mriedem> surprise!
20:51:31 <sdague> mriedem: yeh :)
20:51:58 <smcginnis> dhellmann: For some reason I thought I saw this was our 7th user survey.
20:52:04 <smcginnis> But I could be completely making that up.
20:52:12 <sdague> it is also the reason that the last draft talks about lines of evidence which all seem to align with the 10 to 1 (or more) ratio
20:52:47 <sdague> but, there are a ton of users that aren't making a decision, they are just canonical, red hat, suse, windriver, huawei customers
20:52:58 <sdague> that are just getting their defaults, and probably never showed up
20:53:02 <sdague> in our survey
20:53:05 <cfriesen_> as someone who works at a company that produces an opinionated openstack install, our customers may not actually *know* the answers to the survey...should we be feeding them the answers and asking them to fill it out?
20:53:16 <smcginnis> I guess I'll stir the pot again - regardless of the data, is there a desire to have DB abstraction/agnosticism in the community?
20:53:32 <sdague> cfriesen_: that's kind of the ask in #3, start the conversation about that collection
20:53:33 <dhellmann> cfriesen_ : the idea is to have distributors provide some info about their defaults and their customer base size
20:53:53 <fungi> cfriesen_: some of the takeaway for the survey team was that distros be able to sort of "proxy" answers or something along those lines
20:53:53 <mriedem> smcginnis: i have 0 desire to talk about that again right now
20:53:54 <mriedem> in this meeting
20:54:01 <sdague> mriedem: right
20:54:22 <sdague> my biggest concerns is not to surprise any new users by them thinking they are more supported than they are
20:54:26 <cdent> that's a shame as that seems to be the key issue. the reason we needed a meeting
20:54:37 <cfriesen_> smcginnis: I think there is a desire by some people, and not by others. :)
20:54:37 <smcginnis> Well, the previous comments about it were all interlaced with wether the data supported it or not.
20:54:52 <smcginnis> So I was hhoping we could clearly state one way or the other whether we even cared.
20:54:57 <sdague> and to not prevent advanced things like zero downtime services unless they build it with an abstraciton
20:54:59 <smcginnis> Because if not, the rest is moot.
20:55:04 <sdague> smcginnis: it's not though
20:55:10 <sdague> it's grey space
20:55:25 <sdague> we're definitely going to keep supporting mysql*
20:55:32 <sdague> and do advanced things there
20:55:35 <fungi> i can say that i don't personally care whether openstack is db-agnostic, but i assume the question is more whether we think the openstack community as a whole cares
20:55:38 <mriedem> in general abstraction is good, in practice there are exceptions
20:55:47 <sdague> and the rest... show up and fill out the feature set if you care
20:55:52 <dhellmann> let's not get into that cycle again
20:55:56 <cfriesen_> does the abstraction really prevent mysql from making progress if we don't require feature-parity from different DBs?
20:56:02 <dhellmann> item 3 seems to have support?
20:56:03 <cdent> "and do advanced things there"
20:56:12 <cdent> dhellmann: yes
20:56:13 <sdague> dhellmann: I think so
20:56:15 <mriedem> dhellmann: +1 to #3 from me about better data
20:56:23 <dhellmann> ok, so should we drop item 2 from the next draft?
20:56:27 <dhellmann> and consider that separately?
20:56:30 <cdent> I think so
20:56:35 <dhellmann> as part of any future action?
20:56:42 <sdague> could we just soften it?
20:56:45 <mordred> cfriesen_: I think that's key - and I think we can certainly structure things such that we _can_ make progress
20:56:52 <dhellmann> maybe? how would you soften it, sdague?
20:56:52 <sdague> it was a specific ask "how hard would this be?"
20:57:01 <sdague> lots of people were asking that in the room, including you dhellmann
20:57:02 * cdent I'm a grape in the path of the steamroller of progress: I _don't_ think we should do "advanced things" withing the persitence layer
20:57:08 <cdent> within*
20:57:17 <dhellmann> yeah, I'm not saying we don't do the work, I'm just saying we don't put it into the resolution
20:57:41 <fungi> cfriesen_: are other dbs without implemented feature parity in the software and without substantial testing and subject matter experts upstream actually something we should be recommending as a solution? that's the important question i think
20:57:42 <sdague> dhellmann: ok, so where are we keeping track of the fact that we are doing that work, and we want to report on it?
20:57:44 <dhellmann> us including item 2 or not isn't going to change suse's next steps, right?
20:57:53 <mriedem> if advanced things means scaling to a million nodes, then i'm cool with advanced things
20:58:06 <smcginnis> 2 minute warning
20:58:26 <sdague> dhellmann: us asking for that may change how they surface it
20:58:41 <dhellmann> sdague : if we have the votes to pass something that includes it, I'm fine with it. I thought we needed to rework things to make it approvable.
20:58:45 <cfriesen_> fungi: I see it as the difference between "we're dropping postgres" and "we're not implementing new hotness for postgres, you can do it if you want it"
20:58:49 <mordred> cdent: I think we must, or else we don't serve our users well
20:58:50 <dhellmann> I don't have a problem with keeping it in
20:59:06 <cfriesen_> fungi: the difference is mainly for people already using postgres with lots of sunk costs
20:59:07 <mordred> cdent: but it's highly possible we mean different things by "advanced things"
20:59:07 <fungi> cfriesen_: well, my take is that we can't drop something we never had
20:59:16 <cdent> mordred: potentially
20:59:23 <cfriesen_> fungi: practically speaking it works quite well currently
20:59:30 <dims> smcginnis : thanks for running the show today
20:59:37 <smcginnis> dims: No problem
20:59:41 <dhellmann> yeah, thanks smcginnis, this wasn't an easy one
20:59:52 <smcginnis> Pretty much at time. Thanks everyone.
20:59:55 <sdague> thanks
20:59:58 <mordred> cdent: because I CERTAINYL do not think we should do 'advanced' things in the persistence layer like triggers or stored procedures
21:00:01 <sdague> and thanks dirk for stepping up
21:00:06 <smcginnis> I'm sure there will be more of these to come.
21:00:09 <mordred> dirk: ++
21:00:14 <smcginnis> #endmeeting