20:00:59 #startmeeting tc 20:01:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:03 The meeting name has been set to 'tc' 20:01:06 o/ 20:01:08 o/ 20:01:17 o/ 20:01:18 so, DB2... 20:01:25 * edleafe finds a comfy seat 20:01:26 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 o/ 20:01:41 Agenda is here: 20:01:44 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:46 fun stuff 20:01:52 Scroll down to Next Meeting 20:02:06 o/ 20:02:12 #topic Declare the current state of Postgresql in OpenStack 20:02:15 o/ 20:02:49 are we at quorum? 20:03:14 I count 7 20:03:29 * rockyg hands mriedem a lollipop and says "there, there" 20:03:32 Yep, looks like we've reached quorum, right? 20:03:47 dtroyer: mriedem isn't TC, though his opinion is valued 20:03:56 Welll... 20:04:01 :) 20:04:02 I didn't count him 20:04:08 ok, I'm failing at math 20:04:25 o/ 20:04:28 sdague, dtroyer, smcginnis, fungi, cdent, EmilienM 20:04:34 ah, dhellmann == quorum :) 20:04:41 dims 20:04:42 And dims 20:04:45 sdague : am here too, fighting network issues 20:04:45 * dhellmann feels useful 20:04:47 oh, damn 20:04:49 :) 20:04:54 * dhellmann feels less useful now 20:04:59 I should go back to camping 20:05:10 ++ moar camping for everyone 20:05:15 sdague: Good life lesson in general. 20:05:15 ok, shall we begin? 20:05:18 ++ 20:05:26 SO cdent pulled together a nice post with links 20:05:29 #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/117921.html 20:05:48 We've have had a few lengthy discussions on the ML 20:05:57 #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html 20:06:09 sdague: i had already piped up earlier, but yes, here 20:06:16 #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/117148.html 20:06:42 And we have a couple proposals up to how we want to approach this: 20:06:44 #link https://review.openstack.org/#/c/427880/ 20:06:53 #link https://review.openstack.org/#/c/465589/ 20:07:19 I am your impartial moderator today ss, go.... 20:07:27 *so 20:07:57 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 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 dhellmann: I don't think that's a settled question 20:08:21 and hetypes faster than I do :) 20:08:26 right, so I think that's where we need to start 20:08:31 dhellmann: is it? 20:08:55 we talked about that at the summit, 20:08:56 dhellmann: There certainly are some who *want* it supported. So maybe discuss around what that means in this context. 20:08:58 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 a) we don't support is not up to mysql-par; b) we should document that; c) then what? 20:09:20 i think at the summit we could all agree on actually documenting the current state of htings 20:09:21 *things 20:09:26 which is why we have the two proposals to do that 20:09:29 dhellmann: I agree that asking the board for assistance here seems like a weird ask (from cdent's proposal) 20:09:40 so even cdent's draft would have to change to drop that part 20:09:54 and if that's all we're going to do now, someone could just go write the doc patch 20:10:00 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 right 20:10:14 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 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 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 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 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 I'd like to focus on 1 first here, as I think leaving its state ambiguous isn't helpingn anyone. 20:11:00 smcginnis: I agree 20:11:01 sdague: but are we really talking about postgresql specifically or "any sqlalchemy/oslo.db supported sql vs mysql family only" ? 20:11:03 smcginnis : +1 20:11:06 I wrote the alternative as a way of saying "if we want it, here's a way to say that" 20:11:11 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 so in the proposal https://review.openstack.org/#/c/427880/7/resolutions/20170201-postgresql-status.rst there are 3 concrete actions 20:11:23 sdague: isn't postgresql the guinea pig of making sure that the stuff is reasonably portable accross no-matter-what db? 20:11:35 1) document that it is less supported 20:11:47 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 2) see what a transition would look like / cost (as there is a team doing that) 20:12:12 good plan of attack 20:12:13 3) figure out how the board can give us vendor based usage data that's not coming through in the survey 20:12:37 so, I guess I want to figure out if those 3 actions are +1/-1 from folks 20:12:48 then, there is disagreement about preamble 20:13:00 and we can figure out what's the deal breakers there 20:13:01 i'm +1 on those 3 actions fwiw 20:13:06 but just a lowly pawn 20:13:19 and was my takeaway from the summit session 20:13:20 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 mriedem : well, you rep a vendor that uses postgresql, right? 20:13:31 +1 20:13:35 SO can we get a show of hands - who backs 1 above? 20:13:38 dhellmann: i do 20:13:48 o/ 20:13:58 smcginnis : do you want to use #vote to keep track? 20:14:00 #1 seems fine to me 20:14:08 dhellmann: Would that be better? 20:14:11 ++ #1 20:14:13 * dhellmann shrugs 20:14:25 I support option 1 20:14:50 at this point I think we're looking for opposition to any of those three? 20:14:50 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 +1 to #1 (documenting the dhellmann: Was thinking just semi-informal, but maybe that would help make it more official. 20:15:01 sdague : good point 20:15:10 smcginnis : oh, no, I just meant so you didn't have to count :-) 20:15:25 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 sdague: Final proposal as far as pg support, or final proposal as to hwo we are going to document it? 20:15:30 sifting through the usual level of chatter might have been hard, but we seem to be well-behaved today 20:15:40 smcginnis: final version of whatever this is 20:15:45 I half-object to #2 20:15:59 cdent: ok, because? 20:16:09 #2 just seems like collecting data 20:16:12 sdague : i support all 3 points above 20:16:17 and options fungi 20:16:45 cdent: isn't #2 also in yours? 20:16:49 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 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 mriedem: yes, but I don't really want that one 20:17:19 cdent: that seems very odd to me 20:17:29 I would have written a much string alternative if it was just me 20:17:32 fungi : I believe the SUSE folks are planning to migrate regardless of the outcome, and they're doing that research. 20:17:43 cdent: confused - it's your change :) 20:17:43 because I can't imagine actually deciding to deprecate and remove pg without knowing the cost to current users 20:17:47 dhellmann: right, i knew what it was a reference to 20:18:10 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 cdent, ++ 20:18:44 cdent: ok, so because of that it's not possible to understand alternatives? 20:18:51 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 #2 is all fact finding i thought - if it's prohibitively expensive to migrate from pg to mysql 20:19:24 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 sdague: it is fine to investigate the path, but it is wasted effort if we never choose to take it 20:19:32 and I don't think we should take it 20:19:37 cdent: it's not even our effort 20:19:42 the suse team is already doing it 20:19:43 so why waste the effort when there is so much else to do? 20:19:54 the suse team is as much as anyone else 20:19:55 basically it's just whether or not we want to supress the info 20:19:58 what if we phrase that one as "do nothing else until the suse team reports back" 20:20:07 and if they do it, we can still benefit from the info without having legislated it 20:20:17 legislating it indicates encouragement 20:20:26 suse made a business decision to spend $$$/time on that, ignoring that information seems a waste 20:20:26 dhellmann: as i said: I'm okay with that 20:20:33 and/or implies that it will influence the decision when it may not 20:20:37 I don't think we should ignore the information 20:20:58 I simply think that these resolutions shape future direction: they are politics 20:21:02 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 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 and I think our politics should say: we would like to support many databases, but right now it is hard, halp 20:21:26 Why not "accept info from outside sources on costs of transitioning, etc? 20:22:06 rockyg: I'd be fine with that too 20:22:11 cdent: right, and I think that's where we disagree about that being a priority in OpenStack 20:22:16 which was dhellmann's question 20:22:17 sdague: yes 20:22:18 so then re-work #2 and #3 to be about collecting information about transition, usage, cost of support, whatever... 20:22:19 yes 20:22:23 now we're back to where i suggested we start 20:22:25 yes 20:22:26 :) 20:22:28 dhellmann: right 20:22:32 dhellmann: but we aren't going to agree there 20:22:42 and along with transition costs, if anyone wants to provide costs of maintaining the abstraction would be nice. 20:22:43 like, litterally aren't going to get to concensus 20:23:07 rockyg: right, that's what I tried to put into the preamble 20:23:10 we are already maintaining the abstraction, we just don't test enough to be confident 20:23:19 so the one single thing we need to do, and then we could stop, is adjust the docs 20:23:25 we don't _need_ to do more 20:23:29 but we have an opportunity to do so 20:23:30 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 to answer the question about what we want 20:24:43 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 memories of mongodb debates from years past 20:25:19 we have forced projects to have a sqla driver 20:25:25 I think the idea is for us to clearly say whether postgresql counts as "a database" in our base layer 20:25:35 or "a relational database" 20:25:47 base layer? whoa whoa whoa, that sounds too much like core to me... 20:25:49 alert alert 20:25:59 or if we're going to contract that, to just say mysql-like databases 20:26:08 mriedem : you're reading my lines 20:26:13 :) 20:26:14 mriedem: the base services list (database, message queue, et cetera) 20:26:15 mriedem: I think he means "the things we assert all openstack services can depend on being there" 20:26:35 https://governance.openstack.org/tc/reference/base-services.html?highlight=base 20:26:37 #link https://governance.openstack.org/tc/reference/base-services.html?highlight=base 20:26:54 i'm not really serious, sorry about that one 20:26:56 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 dhellmann : don't think we are ready to state that right now 20:27:07 I'd go one further 20:27:27 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 those are trade offs 20:27:55 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 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 there isn't consensus there now, but I thought that was the whole point of this even coming up? 20:28:07 we don't even have consensus on that 20:28:17 mriedem: that's where I'd be fine being 20:28:22 sdague: me too 20:28:30 there is all sorts of crap you can't do with nova api if you're not using libvirt 20:28:34 in which case we need to be ok that not all dbs are equal 20:28:42 that seems ok to me 20:28:42 as steady state 20:28:47 maybe we have more of a consensus than we thought? 20:28:52 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 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 i'm totally fine with the carrot approach 20:29:07 dhellmann: maybe, cdent how do you feel on that? 20:29:37 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 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 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 modulo review, quality, etc. 20:29:57 they can't reject the patch out of hand 20:30:26 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 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 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 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 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 cdent : graceful degradation until someone provides the patches to make it do otherwise? 20:31:39 cfriesen_: projects already have the leeway to reject all sorts of other patches without us telling them they can 20:31:58 dhellmann: At this stage that seems like we could hope for 20:32:08 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 fungi: But rejection based on an overall policy is a little different. 20:32:11 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 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 sdague: slightly nutty? 20:32:37 mriedem: all those null key migrations 20:32:37 we put a unique constraint on a unique column... 20:32:42 dirk: I do not believe infra would do anything to prevent pg support in the gate 20:32:58 pg is an open source database. job content is job content. 20:33:01 dirk: we already have that 20:33:07 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 dirk: it's in the experimental queue for all integrated-gate jobs 20:33:12 fungi: ++ 20:33:16 dirk: right, any open source stuff has been welcome in the gate in various efforts 20:33:19 er projects that use the integrated-gate jobs 20:34:00 thanks, so the summary is "we welcome projects to test against postgresql but don't require it going forward" 20:34:16 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 well, it could be one of the summarys. sorry 20:34:37 smcginnis: i think we're all agreeing on docs 20:34:52 smcginnis : yes, I think we all agreed on that. 20:34:54 smcginnis, mriedem: ++ 20:34:59 so... agreed thus far is 1 & 3 in the action list 20:35:03 ? 20:35:08 Then the question comes to which of the porposals are we most OK with? 20:35:14 For docs. 20:35:26 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 smcginnis: i think both say basically the same thing 20:35:44 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 EmilienM: thanks! 20:36:07 g'night EmilienM 20:36:34 cdent: Did you have concerns about the first of the two docs patches? 20:37:18 Or did we now lose quorum? 20:37:20 smcginnis: ? 20:37:28 still here.. 20:37:45 i had a clarification question on docs in cdent's patch 20:37:52 dhellmann, made it eight, so down one leaves 7 20:37:54 but i think both say the same thing 20:37:57 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 rocky_g: thanks! 20:38:14 the most recent version of sdague's is quite a bit different from the original verison, I think 20:38:25 smcginnis: you're talking about the two different proposals from me and sean or something else? 20:38:42 cfriesen_: yeh, I was really trying to capture what I thought was concensus out of the session in Boston 20:38:43 cdent: Yes, sorry, your vs sdague's/ 20:39:26 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 apart from verbosity are the two conflicted in any major way? (latest revs) 20:39:42 smcginnis : i'd support that 20:39:45 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 cdent : does it still read that way? (latest rev) 20:40:42 cdent: Are you now OK with the original patch? 20:40:46 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 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 cdent: OK, sorry to put you on the spot. 20:41:32 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 or don't, whatever :) 20:41:48 I will state that there are definitely folks that don't like the tone which does state mysql* is more supported 20:41:51 version seven is still, to me, "let's use mysql" in disguise 20:42:19 right, and I think that's where we're eventually going to hit a wall, because there is that split 20:42:31 sdague: thats where mordred "s comment comes in : OpenStack is more focused around mysql (rather than saying "support") 20:42:38 sdague: and I think that solves the conflict 20:42:56 cdent : i prefer to lean that way to show that we will pull trigger some time down the road 20:43:02 dirk: ok, so maybe a next step would be mordred to redraft that ? 20:43:04 "support" is to be avoided unless you want to end up in endless debates, basically 20:43:15 dirk: ok, I tried to define support in the last version 20:43:21 dims pull which trigger? 20:43:23 dims: what trigger? 20:43:30 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 dims: but what if people step up to support postgres? (which was one of the things mentioned) 20:43:32 the one that kills pg in openstack? 20:43:36 drop pgsql in 2-3 years 20:43:42 dims: we're not even talking about that 20:43:44 sdague: both mordred and me made concrete wording improvements 20:43:46 yeah, exactly, that's why I don't want that version :) 20:43:47 cfriesen_ : right then we reconsider 20:43:52 sdague: in a review comment. 20:43:56 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 sdague: I can respin if you like 20:44:05 lol sdague 20:44:13 i know it's tough 20:44:14 dirk: ok, maybe would you like to intergrate those changes? 20:44:20 or dirk can - either way 20:44:31 that might make sure we get a balance you are comfortable with 20:45:00 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 so we settle down on the sdague governance patch and interate there 20:45:13 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 dims: +1 20:45:22 dirk: you ok with taking the next iteration? 20:45:27 Keep going in that direction, or change course 20:45:37 are we going to keep all 3 steps? or drop it down to just the first one? 20:45:42 dirk : thanks in advance :) 20:45:44 mordred: I can give it a try 20:45:52 dirk: awesome! 20:45:53 #action dirk to update sdague's first documentation patch 20:45:58 I think having dirk take a pass is a good idea 20:46:05 s/documentation/governance :) 20:46:15 #undo 20:46:20 #undo 20:46:21 Removing item from minutes: #action dirk to update sdague's first documentation patch 20:46:26 #action dirk to update sdague's first governance patch 20:46:32 thanks :) 20:46:58 thanks, dirk 20:47:01 cdent: But you would like to hold on to your alternative? 20:47:01 k. me switching to partially here mode then 20:47:09 thanks dirk 20:47:21 * smcginnis wonders if we technically have quorum then. 20:47:26 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 cdent: sounds reasonable 20:47:40 cdent : ++ 20:47:43 thanks cdent 20:47:55 I think that seems like the best way to iterate at this point 20:47:56 cdent: +1 20:48:17 smcginnis: since we're not voting we don't really need quorum: we just chattin' 20:48:27 Oh, true. :) 20:48:32 so, the only real remaining sticking bits were whether point #2 / #3 need to be changed around 20:48:36 Watercooler talk, eh 20:48:43 they were captured because of the boston session 20:48:47 as things we wanted 20:48:54 for different reasons 20:49:03 I think we're all happy with point 3? 20:49:11 i think we may be down to 7 present (me, cdent, dims, dhellmann, mordred, sdague, smcginnis) 20:49:29 o/ 20:49:30 Only half of a dims though. :) 20:49:32 3 is: work with foundation to get better data of current state of affairs? 20:49:34 dhellmann: I have not heard objections to 3 20:49:45 folks, I don't think we need quorum because we're making an action plan not a final decision 20:49:46 sdague: +1 20:49:47 oh, right, dtroyer's here so long as dims is at least partly here still 20:49:54 cdent: yeh, so for instance purp and I had a bunch of conversations out of band on this review 20:50:01 and his objections included 20:50:03 * smcginnis notes there will be no voting 20:50:16 - we have no idea what switching cost would even be (agree) 20:50:26 - the openstack survey is not scientific (also agree) 20:50:27 Agreed 20:50:44 those are fair points 20:50:54 I still think it's OK to point out that the survey could be improved. 20:50:58 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 otherwise they might have filled it out 20:51:11 ha 20:51:15 btw, 20:51:19 how many years have we been doing that? 20:51:21 everyone is running cells v1 according to the survey 20:51:24 surprise! 20:51:31 mriedem: yeh :) 20:51:58 dhellmann: For some reason I thought I saw this was our 7th user survey. 20:52:04 But I could be completely making that up. 20:52:12 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 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 that are just getting their defaults, and probably never showed up 20:53:02 in our survey 20:53:05 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 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 cfriesen_: that's kind of the ask in #3, start the conversation about that collection 20:53:33 cfriesen_ : the idea is to have distributors provide some info about their defaults and their customer base size 20:53:53 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 smcginnis: i have 0 desire to talk about that again right now 20:53:54 in this meeting 20:54:01 mriedem: right 20:54:22 my biggest concerns is not to surprise any new users by them thinking they are more supported than they are 20:54:26 that's a shame as that seems to be the key issue. the reason we needed a meeting 20:54:37 smcginnis: I think there is a desire by some people, and not by others. :) 20:54:37 Well, the previous comments about it were all interlaced with wether the data supported it or not. 20:54:52 So I was hhoping we could clearly state one way or the other whether we even cared. 20:54:57 and to not prevent advanced things like zero downtime services unless they build it with an abstraciton 20:54:59 Because if not, the rest is moot. 20:55:04 smcginnis: it's not though 20:55:10 it's grey space 20:55:25 we're definitely going to keep supporting mysql* 20:55:32 and do advanced things there 20:55:35 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 in general abstraction is good, in practice there are exceptions 20:55:47 and the rest... show up and fill out the feature set if you care 20:55:52 let's not get into that cycle again 20:55:56 does the abstraction really prevent mysql from making progress if we don't require feature-parity from different DBs? 20:56:02 item 3 seems to have support? 20:56:03 "and do advanced things there" 20:56:12 dhellmann: yes 20:56:13 dhellmann: I think so 20:56:15 dhellmann: +1 to #3 from me about better data 20:56:23 ok, so should we drop item 2 from the next draft? 20:56:27 and consider that separately? 20:56:30 I think so 20:56:35 as part of any future action? 20:56:42 could we just soften it? 20:56:45