20:01:24 <ttx> #startmeeting tc
20:01:25 <openstack> Meeting started Tue Mar 14 20:01:24 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:29 <openstack> The meeting name has been set to 'tc'
20:01:31 <dims> o/
20:01:35 <ttx> Hi everyone!
20:01:37 * lbragstad finds the next most comfy chair next to edleafe
20:01:40 <ttx> Our agenda for today is at:
20:01:42 * mugsie lurks
20:01:44 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:49 <ttx> We have three big sections
20:01:55 <ttx> #topic New working groups
20:02:06 <ttx> I'm a bit torn on those, as I really don't want to make it look like you need to apply to the TC in order to set up a working group
20:02:10 <ttx> I mean, anyone should be able to form a group on anything
20:02:20 <ttx> I get that a formal resolution gives the group some weight though, which is why the Stewardship WG was created from a TC resolution
20:02:20 <fungi> (and in fact they do, often)
20:02:28 <ttx> Opinions on that, before we dive in the specific requests ?
20:02:33 <sdague> yeh, my feeling is people should just start gathering and doing useful things
20:02:39 <EmilienM> +1
20:02:40 <dtroyer> I generally agree
20:02:46 <johnthetubaguy> I don't want to make a resolution required
20:02:55 <EmilienM> ttx: I can abandon mine if it makes no sense and just keep Wiki updated
20:03:04 <johnthetubaguy> but then I do like the TC saying something is important, and needs addressing
20:03:05 <sdague> it feels like TC appoval ends up making these look like permanent institutions, vs. people coming together to solve things
20:03:10 <fungi> any time we create a new list of things in governance, people will want to try to add to it
20:03:15 <sdague> fungi: ++
20:03:16 <johnthetubaguy> sdague: thats a good point
20:03:16 <dtroyer> I guess the question to the authors is "what might make these worth the exception"?
20:03:17 <ttx> EmilienM: we could maintain a registry of the workgroups but it feels overkill too
20:03:25 <EmilienM> yeah
20:03:36 <dhellmann> I do think there will be cases where we want to "charter" working groups, but both of these cases feel like we could skip that step
20:03:37 <johnthetubaguy> ttx: although the UC was talking about the issues they had without a registry
20:03:53 <ttx> johnthetubaguy: ah ?
20:04:00 <dhellmann> a registry makes a lot of sense to improve discoverability
20:04:06 <dtroyer> a directory?
20:04:12 <dhellmann> and that doesn't need to be in the governance repo
20:04:12 <dtroyer> less official sounding
20:04:14 <sdague> so, I think the real issues are, if people are coming together to solve a thing: a) how does anyone discover they exist? b) how would one get involved if they wanted to c) what do those folks see as their scope
20:04:16 <johnthetubaguy> them mentioned at the board meeting, they found it hard having no ... directory I guess
20:04:17 <ttx> We could list them on the governance website
20:04:25 <fungi> a registry for the uc is somewhat necessary, as it factors into their electorate
20:04:29 <johnthetubaguy> I mean a wiki page would totally work
20:04:30 <ttx> but that means extar review
20:04:32 <sdague> a wiki page solves it all except discovery
20:04:38 <dtroyer> ++
20:04:41 <johnthetubaguy> fungi: true
20:04:46 <ttx> We can point to the wiki page from the governance website
20:04:54 <dhellmann> we could link to the wiki from the governance site, or we could share a registry with the uc
20:04:56 <ttx> avoids crazy reviewing
20:05:00 <fungi> would we want to extend separate election privileges to "active" members of these working groups who are not already active technical contributors through other means?
20:05:01 <johnthetubaguy> ttx: yeah was about to type the same
20:05:03 <persia> If the need for a directory is partially driven by UC electorate concerns, might it make sense for the UC to perform the reviews to extend the directory?
20:05:19 <dhellmann> persia : the uc has its own working groups
20:05:30 <dtroyer> I like the combination of linking to the wiki from governance, it seems to strike the right official vs "just do it balance"
20:05:33 <ttx> ok, let's dive into each specifically
20:05:39 <ttx> #topic Propose VM and Bare-metal Platform Working Group
20:05:44 <ttx> #link https://review.openstack.org/442387
20:05:47 <ttx> johnthetubaguy: want to introduce this ?
20:06:01 <johnthetubaguy> so this really is an thing that keep coming up over beer
20:06:19 <johnthetubaguy> get a group to worry about the VM + baremetal platform
20:06:23 <ttx> workgroups: no resolution needed, but beer welcome
20:06:30 <johnthetubaguy> :)
20:06:55 <johnthetubaguy> there are a few problems that keep coming
20:06:56 <johnthetubaguy> up
20:07:05 <johnthetubaguy> mostly user experience related
20:07:11 <johnthetubaguy> both in the human and machine case
20:07:21 <johnthetubaguy> humans using REST APIs, horizon, etc
20:07:21 <ttx> sure, feels like a good vehicle to solve inter-project pains within that platform
20:07:26 <fungi> it sounds like there are already people who worry about this, so the point is to just provide some rallying point for them?
20:07:44 <johnthetubaguy> yeah, its more about looking at the whole problem, and priorities between the efforts
20:07:57 <ttx> fungi: also creates some inter-PTL agreement on priorities
20:08:03 <johnthetubaguy> one example, I think we should work together to work out what needs to happen at the forum for that set of use cases
20:08:04 <dhellmann> how is this group different from the architecture working group?
20:08:05 * jroll sneaks in the back, late
20:08:18 <cdent> on the topic of having groups be something that involves tc application: a win from that is that it is easier to get support from an employer to spend time on it when it is officially sanctioned
20:08:20 <johnthetubaguy> dhellmann: the main thing here, is the reduced scope
20:08:22 <mugsie> or API-WG ?
20:08:23 <ttx> dhellmann: arguably a VM+Baremetal platform focused Arch WG
20:08:40 <dhellmann> cdent : good point
20:08:41 <mugsie> (for the eaxmple of humans using a rest API)
20:08:44 <dhellmann> johnthetubaguy : how are conflicting decisions between the two groups resolved?
20:08:57 <dims> johnthetubaguy : how does the TC stamp help? (curious)
20:09:00 <johnthetubaguy> discussions between the groups
20:09:05 <ttx> cdent: could make it worth the pain of maintaining the list as a governance doc, good point
20:09:16 <lbragstad> would everything the done by the PWG fall under the umbrella of the API or Arch WG?
20:09:16 <johnthetubaguy> so the TC stamp here, was more to identify a set of problems that need attention
20:09:17 <dhellmann> dims : we've had plenty of companies only give permission for folks to work on "official" projects
20:09:18 <sdague> johnthetubaguy: ok, so the API-WG started with a rough plan and 3 people
20:09:24 <fungi> cdent: if it gets employer support to work more upstream, i'm happy to rubber stamp numerous taskforce resolutions ;)
20:09:25 <ttx> dhellmann: I suspect conflicting decisions don't get solved
20:09:28 <dims> dhellmann : ack
20:09:37 <johnthetubaguy> sdague: yep, I think thats what this needs too
20:09:40 <sdague> I guess my practical question is who are the key players here besides yourself?
20:09:42 <dhellmann> ttx: or they come up to the tc?
20:09:47 <ttx> dhellmann: yes
20:09:51 <cdent> (sorry for making that statement after we had moved on a bit, but I had been pulled away momentarily)
20:10:13 <sdague> because, I think we still have the johnthetubaguy's not allowed to sign up for more things by himself rule enforced on alternate tuesdays
20:10:14 <johnthetubaguy> sdague: not got commitment from folks yet
20:10:29 <johnthetubaguy> sdague: heh, that should be a thing
20:10:39 <dhellmann> in the past, we've also said we wanted new groups to show that they're actually doing work before approving them. does that apply to working groups, too?
20:10:57 <johnthetubaguy> dhellmann: that makes sense
20:11:02 <sdague> dhellmann: yes please
20:11:07 <dims> ++ dhellmann
20:11:14 <johnthetubaguy> so there is one piece that I wanted to check we are in agreement
20:11:17 <dhellmann> and for the record, I think it's fine to have a group doing this, I just want to work out whatever approval process details we need worked out
20:11:19 <sdague> the last thing I want to see is a ton of shadow governance locks on problems
20:11:30 <dhellmann> right
20:11:46 <ttx> at the same time I don't want to spend time vetting working groups
20:12:03 <dhellmann> that doesn't seem like a good use of our time, no
20:12:05 <ttx> they just should not exist if they are not doing things
20:12:31 <fungi> to sdague's point, it would be unfortunate to approve a working group who ends up having no time to commit to the issue at hand, but ends up preventing others who are available from making progress on the same problem space themselves
20:12:32 <sdague> right, which is why I kind of think staying out of blessing is best. It was a long time before the api-wg became "official"
20:12:35 <johnthetubaguy> so my idea was more to identify these problems need fixing
20:12:49 <johnthetubaguy> a resolution is probably a poor way of doing it
20:13:00 <cdent> johnthetubaguy: that list of issues is a good one
20:13:13 <johnthetubaguy> it feels good if we as the TC can flag those things up
20:13:15 <dhellmann> it may work better to start a ML thread and ask people who are interested in solving those issues to self-organize
20:13:25 <mugsie> dhellmann: ++
20:13:29 <sdague> johnthetubaguy: honestly, I'd be totally happy if we took that list of issues, made an attempt at 1-N prioritization
20:13:44 <sdague> and if a collection of people show up to help there, ++
20:13:46 <ttx> johnthetubaguy: it feels like you should define your set of issues, start working... and if you need the TC to point to you and say: "that's a good thing" there are a variety of ways to do it
20:13:49 <johnthetubaguy> sdague: who is we in this context
20:13:58 <johnthetubaguy> sdague: yeah, in the working group, if it becomes a thing
20:14:07 <dhellmann> right, if we need resolutions to codify specific decisions or something, we could do that
20:14:09 <sdague> johnthetubaguy: well, you, and perhaps the TC stamping the issue list
20:14:27 <johnthetubaguy> ttx: yes, I was just wondering if we as a TC should do something to high light the issues, frankly this discussion is probably enough
20:14:44 <fungi> perhaps simply making the "membership" or working groups fluid is sufficient to allow others to pick up the work without having to get some institutionalized group to relinquish it first?
20:14:46 <johnthetubaguy> sdague: OK, I see what you mean, propose the list, and maybe stamp it, that makes sense
20:14:47 <dims> i like the idea of TC saying this stuff needs attention
20:14:55 <ttx> johnthetubaguy: you could request some time to present the WG issues to the TC and have some pile of +1s
20:14:57 <sdague> because I think that's a very good starting point of key issues with the openstack platform
20:14:58 <cdent> dims++
20:15:00 <johnthetubaguy> dims: thats the bit I am wondering about how we would do that
20:15:02 <dhellmann> iirc, last week the idea of some sort of priority list that wasn't tied to the goals process did come up
20:15:25 <sdague> that aren't horizontal, or vertical, but much more usage based
20:15:26 <ttx> johnthetubaguy: just ask for some time at a TC meeting and present*
20:15:40 <ttx> then I'm happy to pile it +1s
20:15:40 <sdague> and solving any single one of those would make openstack as whole better
20:15:47 <dims> ++ sdague
20:15:48 <ttx> pile up*
20:16:14 <johnthetubaguy> so maybe the key bit I am getting here, is "this is not crazy"
20:16:20 <ttx> we could also have that list of issues and "delegate" it to wgs
20:16:37 <fungi> not crazy, but maybe we lack the framework to slot this and similar priorities into?
20:16:38 <johnthetubaguy> I will try run with this to the ML, and see if there is a motley crew keen to work on this
20:16:54 <dhellmann> oh, yeah, the issue list idea came up with finding ways for new contributors to engage constructively, instead of through typo patches
20:17:05 <ttx> I basically prefer that we support the WGs rather than bless them
20:17:13 <mugsie> ls
20:17:15 <dhellmann> right
20:17:24 <johnthetubaguy> I quite like the flagging issues that need solving bit
20:17:27 * fungi certainly doesn't want to have to get ordained
20:17:55 <ttx> johnthetubaguy: ok so next step is to raise a ML thread. We can discuss visibility of a WG registry separately
20:18:04 <johnthetubaguy> yeah, we should move on
20:18:17 <dhellmann> and then someone needs to start a storyboard list of those issues :-)
20:18:25 <ttx> #info Workgroup should get set up on the ML. TC is happy to supprot and encourage the work of the workgroup
20:18:46 <jroll> I like this
20:18:48 <dims> johnthetubaguy : throw in a etherpad
20:18:51 <EmilienM> ttx: +1
20:19:17 <ttx> #info potential future work: how to maintain list of WGs and ensure discoverability, and a blessed list of high-value targets
20:19:36 <ttx> #topic Propose Deployment Working Group (DWG)
20:19:40 <ttx> #link https://review.openstack.org/442761
20:19:44 <ttx> EmilienM: want to introduce this one ?
20:19:47 <EmilienM> #action EmilienM to transform https://review.openstack.org/#/c/442761 into a ML thread to communicate about this new WG and what we plan to do
20:19:53 <ttx> although I suspect it will meet the same fate
20:20:03 <EmilienM> ttx: no need to spend time on it IMHO
20:20:04 <fungi> it's like we just had most of this discussion already! ;)
20:20:20 <ttx> EmilienM: for the record, I like that workgroup too.
20:20:33 <sdague> ttx: ++, great start there EmilienM
20:20:39 <EmilienM> I like the fact you like :)
20:20:44 <fungi> it seems to already have more or less formed, based on discussions of related topics i've seen on the ml over the past couple weeks
20:20:47 <ttx> we need more of those interproject groups
20:20:53 <EmilienM> fungi: ++ indeed
20:20:55 <johnthetubaguy> yeah, seems like a good thing to do there too
20:21:13 <ttx> ok, moving on
20:21:19 <ttx> #topic Describe what upstream support means
20:21:21 <ttx> #link https://review.openstack.org/440601
20:21:25 <ttx> johnthetubaguy: you again
20:21:27 <dhellmann> ttx: another justification for some sort of registry may be to know which groups to ask about PTG and Forum space
20:21:41 <ttx> dhellmann: ack
20:21:42 <dhellmann> it could still be a wiki page
20:21:43 <fungi> dhellmann: i completely concur there
20:21:46 <johnthetubaguy> so this came up in the postgresSQL discussion
20:22:09 <johnthetubaguy> "supported upstream" is a strange phrase right now
20:22:16 <johnthetubaguy> so I attempted to write down some ideas
20:22:40 <ttx> I like it -- still a bit of polishing work needed
20:22:45 <johnthetubaguy> seeing some good comments from ttx and dtroyer on there
20:22:59 <johnthetubaguy> I like the idea of defining the conditions for claiming support
20:23:11 <ttx> avoids the weird "volunteer" mention
20:23:23 <ttx> (although I see what you mean by that)
20:23:37 <johnthetubaguy> I totally stole the phrase from fungi as I couldn't come up with a better one
20:23:39 * dims has not reviewed that yet
20:23:47 <fungi> i still like the word
20:23:52 <johnthetubaguy> should we just say "upstream support" then?
20:24:25 <johnthetubaguy> I also don't really want to get bogged down into listing all the requirements for support
20:24:30 <fungi> volunteers may refer to the individuals, or to the employers who volunteer their employees' time to participate, after all
20:24:35 <johnthetubaguy> I was more wanting to baseline on definitions really
20:24:41 <ttx> johnthetubaguy: yes, I like we keep it inspirational
20:24:44 <johnthetubaguy> fungi: totally
20:24:51 <dhellmann> this feels a bit like "open source 101"
20:25:07 <ttx> fungi: yes -- just know that some people will read it wrong
20:25:15 <fungi> we have a disproportionately high number of users (and even contributors) who could use a regular support of "open source 101"
20:25:25 <dtroyer> unfortunately ++
20:25:27 <dhellmann> agreed
20:25:28 <fungi> er, regular dose
20:25:39 <johnthetubaguy> dhellmann: maybe, but its good to write down our shared assumptions
20:25:51 <ttx> johnthetubaguy: maybe make it clear that this is nothing new, more of a reminder
20:25:59 <dhellmann> johnthetubaguy : oh, I'm not objecting, just making the comment
20:26:02 <johnthetubaguy> ttx: yeah
20:26:13 <fungi> all those people who think openstack is "like free vmware" are wondering where their support contract is
20:26:14 <johnthetubaguy> dhellmann: very fair comment too
20:26:14 <dtroyer> more in the spirit of writing down our principles?
20:26:21 <johnthetubaguy> dtroyer: yep
20:26:41 <johnthetubaguy> on that note, is it really a "definition" rather than a resolution?
20:26:55 <ttx> johnthetubaguy: hmm... wondering if it could fit in the project team guide... although I guess it's more directed to specific tactical groups
20:26:57 <johnthetubaguy> so lives near the principles not the resolutions?
20:27:18 <johnthetubaguy> anyways, answers on a postcard, I mean gerrit review comment
20:27:21 <ttx> johnthetubaguy: I think it's a statement, not a living document
20:27:30 <ttx> so I'd rather file it under resolutions/
20:27:31 <dhellmann> it seems reasonable to have a resolution saying "we're going to delete things when people stop contributing to them"
20:28:00 <sdague> dhellmann: yeh
20:28:07 <fungi> i think it's a statement at a point in time (resolution) which could be used to inform future updates to a living document such as principles et cetera
20:28:07 <johnthetubaguy> ttx: OK, I just never like trying to get things correct first time
20:28:14 <ttx> ok, let's iterate on the review
20:28:19 <johnthetubaguy> cool
20:28:20 <ttx> and move on
20:28:25 <sdague> or even that we delete things that are considered debt if it helps us move the whole platform forward
20:28:34 <ttx> johnthetubaguy: thanks for pushing those
20:28:50 <johnthetubaguy> sdague: didn't want to repeat the standard deprecation tag, but lets see what we come up with
20:28:53 <sdague> because, I kind of think that's really what's behind the next one...
20:28:55 <fungi> when you prune a shrub, you may lose a few live branches in the process ;)
20:29:11 <johnthetubaguy> sdague: yeah, thats totally why I raised this one
20:29:15 <dims> ooh, i got to write that down fungi :)
20:29:23 <ttx> which brings us to....
20:29:27 <ttx> #topic Deprecate postgresql in OpenStack
20:29:30 <ttx> #link https://review.openstack.org/427880
20:29:39 <ttx> So this one is a bit stuck, although the previous resolution will help with it
20:29:45 <ttx> I think there are multiple ways to slice this one
20:29:55 <ttx> 0/ Make a statement that we'll deprecate it unless there is more consistent upstream work to support it
20:30:02 <ttx> 1/ Pass a resolution now saying it's generally deprecated due to lack of upstream support
20:30:11 <ttx> 2/ Contract the "database" base service to the MySQL family (now or after the deprecation period)
20:30:20 <ttx> (That last one would signal we can start breaking non-MySQL deployments)
20:30:29 <ttx> Before we do (2) I'd like to give people a last chance to step up and save it. Maybe that's my soft side speaking though...
20:30:40 <dhellmann> have we had any input at all from Huawei or SuSE?
20:30:46 <johnthetubaguy> you know how I said we should find a way to flag problems, how about we just say "the status quo of supporting many databases isn't working"?
20:30:48 <ttx> Also before we do (2) I'd prefer non-MySQL numbers to drop below 5% (currently at ~10%)
20:30:50 <dhellmann> I mean in the sense of their interest in supporting PG?
20:30:56 <dtroyer> it feels like we've done that already, but not this formally?
20:31:02 <dtroyer> ttx: ^^^
20:31:07 <smcginnis> Might be better to start with 1, with the statement that 2 will follow.
20:31:12 <fungi> under 2/, are we feeling obligated to provide conversion/migration tools or instructions for people switching at upgrade time?
20:31:21 <ttx> we haven't done anything formal. I guess the question is should we do (0) or jump directly to (1)
20:31:41 <dhellmann> fungi : maybe
20:31:41 <ttx> this proposal is basically (1)
20:31:45 <dtroyer> I would pref to go straight to 1 to help signal "we mean it this time"
20:31:49 <johnthetubaguy> I don't see deprecation as a one way process, so I am fine with (1)
20:31:50 <gordc> dhellmann: can we define what 'more consistent upstream work to support it' means?
20:31:50 <dims> ttx : i vote for (1)
20:32:03 <dhellmann> gordc : excellent question.
20:32:29 <ttx> it feels like more than one person asked "what consistent upstream work means", so (0) seems warranted
20:32:41 <johnthetubaguy> part of me things part of fixing this problem is digging deep to understand what the real issue is, and enumerate the possible solutions
20:33:05 <ttx> although I wasn't involved in previous iterations of the discussion so I may ignore how many times (0) was already done
20:33:12 <dhellmann> I also want us to answer clearly yes/no whether we *want* that contribution, or if we're more interested in dropping support than having help with maintenance.
20:33:24 <fungi> i do feel like we're still operating a little on the misconception that it was already broken when we stopped testing it. i stand by the reasons for ceasing testing, but there were no outward complaints of breakage until the issue ceilo hit recently
20:33:28 <sdague> dhellmann: right, I think we don't want that contribution
20:33:34 <johnthetubaguy> dhellmann: I don't think we can, till someone has all the options laid out
20:33:46 <cdent> fungi++
20:34:02 <dhellmann> sdague : how do we determine consensus on that?
20:34:34 <johnthetubaguy> I think we need to do (1) before we make that decision
20:34:41 <dhellmann> johnthetubaguy : aren't the options (1) someone says they will work on gate failures and we support pg or (2) we do not want anyone working on gate failures, pg is going away?
20:35:09 <johnthetubaguy> dhellmann: its more about how you avoid the gate failures in the first place, not working on that seems bad at this point
20:35:11 <ttx> that's two different ways of writing (1), for sure
20:35:13 <dhellmann> johnthetubaguy, ttx : option 1 presumes we would want support if someone showed up. We should not ask for help if we're going to turn people away.
20:35:15 <sdague> my slightly snark answer to gordc's question is:
20:35:34 <gordc> dhellmann: +
20:35:42 <sdague> when pg folks implement consistent unicode name support for both mysql and pg across the starter kit
20:35:46 <dhellmann> the real option 1 seems to be that we do not want to support it because we want to use $features of mysql
20:36:04 <sdague> because the issue is that the community has to pay a pg tax on every feature, even if a small one
20:36:19 <dims> we have to signal that we are "contracting" the options
20:36:22 <johnthetubaguy> its more about stopping trying to think about all these different database on every patch, somehow
20:36:33 <gordc> sdague: cool, i dont know what that issue is personally. but good to have some qualifer
20:36:34 <sdague> and saying that pg folks only need to be engaged when it's entirely their platform at issue, instead of helping on general things to pay back that tax
20:36:38 <johnthetubaguy> dims: +1 thats why I want (1) to start the deeper discussions
20:36:46 <dhellmann> sure, but then let's be honest. it's not about lack of support from anyone in our community, right? it's about a fundamental underlying difference in the database engines.
20:36:48 <ttx> dims: I don't think we should contract until the alternate option is below 5% though
20:37:03 <ttx> I mean... open question
20:37:16 <sdague> dhellmann: right, it's based on the fact the dev community and operator community largely has the skills knowledge on one backend
20:37:21 <ttx> what's the adoption bar under which it's fine to contract ?
20:37:33 <ttx> 20% ? 10% ? 5% ?
20:37:42 <gordc> dhellmann: tbh, i don't think we can accept/support pgsql if there is no gate on it since it's going to be impossible to measure if it's maintained or not.
20:37:44 <sdague> and "make it work for this other one too" is a real cost, even just at coming up with base plans
20:37:48 <ttx> PG is currently ~9% of deploys
20:37:48 <dhellmann> sdague : are the unicode issues addressable via sqlalchemy, for example?
20:37:53 <sdague> dhellmann: no
20:38:06 <fungi> there was a distinct impression in the joint board/tc/uc meeting last week where the ecosystem perceives openstack as complex, and overall we need to shed some weight (in terms of providing deployers/users too much flexibility) to simplify it
20:38:13 <sdague> fungi: ++
20:38:23 <dtroyer> fungi: ++
20:38:27 <dims> yep fungi
20:38:30 <johnthetubaguy> fungi ++
20:38:40 <dhellmann> sure, I don't have a problem with that, I just want us to be honest about the reason we're doing it.
20:38:45 <fungi> easy ways include removing backend options where the ecosystem has already mostly chosen a winner
20:38:56 <johnthetubaguy> so the request for help is helping people move between databases?
20:38:59 <ttx> yes, we shouldn't say it's for lack of upstream commitment then
20:39:06 <fungi> and thos in particular seemed like a fairly clear-cut example of that scenario
20:39:11 <fungi> s/thos/this/
20:39:14 <ttx> which makes johnthetubaguy's resolution a bit redundant
20:39:29 <dhellmann> johnthetubaguy : would we accept features in service projects to ease that migration? like some sort of db-neutral dump and import tool?
20:39:31 <johnthetubaguy> well, irrelevant I guess
20:39:34 <dims> we can cite both reasons ttx
20:39:41 <sdague> right, and hopefully prevent more people from being on the "wrong" side of a "don't worry wesley, likely to kill you in the morning"
20:39:46 <johnthetubaguy> dhellmann: thats the kind of thing I was thinking
20:40:02 <ttx> dims: I would argue it should just be submitted as a base-services.rst patch then
20:40:03 * dhellmann has a use case for that tool independent of a db transition
20:40:24 <johnthetubaguy> dhellmann: maybe os-ops scripts that use some alembic magic, but something
20:40:25 <dims> ttx : agree
20:40:35 <ttx> dims: no need for a resolution citing lack of commitment if we'd do it anyway in the name of contracting options
20:40:40 <sdague> because I suspect that suse and huawei ended up over on that side of the line based on us not being properly expressive that there was a preference here upstream
20:40:41 <dhellmann> johnthetubaguy : I want it to be schema-neutral for my use case, too
20:41:10 <dhellmann> sdague : exactly. let's not make it worse by suggesting there is any amount of upstream commitment that could reverse this course.
20:41:15 <gordc> sdague: not really from huawei pov.
20:41:18 <johnthetubaguy> did we get explicit about rabbitmq already?
20:41:32 <ttx> johnthetubaguy: nope
20:41:52 <dims> johnthetubaguy : we can line both up :)
20:41:55 <sdague> johnthetubaguy: the non rabbit solutions hard failed enough that a resolution was never really needed practically
20:42:09 <johnthetubaguy> sdague: true, but its good to let folks know that
20:42:10 <dhellmann> there are people actively working on zeromq, and maybe other drivers
20:42:33 <johnthetubaguy> dhellmann: maybe its time to tell them to stop that (unless it fixes rabbitmq ha)
20:42:40 <dhellmann> so we need to engage those teams when we start talking about deprecations there
20:42:42 <dims> dhellmann : mirantis has stopped work on zeromq
20:42:54 <ttx> dhellmann: it fixes a specific distributed cloud case
20:42:57 <dhellmann> dims : ok, I thought it was someone else
20:43:11 <ttx> different discussion though
20:43:16 <dhellmann> ttx: right, my point is someone still thinks there's active work to be done there
20:43:34 <johnthetubaguy> feels like they should both get the same treatment
20:43:50 <dtroyer> I think that is a reasonable starting point
20:43:56 <johnthetubaguy> "hey we tried to abstract this stuff, we failed, sorry"
20:44:06 <dhellmann> we'll want to consider the rpc and notification cases separately, I think, but yeah
20:44:21 <EmilienM> we're also investing in amqp driver (without rabbitmq) in tripleo
20:44:23 <ttx> OK, so two different facets to polish: be clear why we are doing it to not open false hopes, and also be clear of when we'd be fine with breaking setups (after deprecation period I guess)
20:44:25 <johnthetubaguy> dhellmann: thats true, I was thinking RPC
20:44:26 <EmilienM> which would solve the rabbitmq ha
20:44:30 <sdague> johnthetubaguy: or more importantly, the abstraction isn't going to make anyone really happy
20:44:59 <johnthetubaguy> sdague: true, thats realisation here really
20:45:00 <dhellmann> ttx: and suggest that folks start thinking about transition plans, and encourage project teams to allow feature additions to support that transition.
20:45:07 <ttx> johnthetubaguy: I prefer to see it as the natural end of an expand/contracting of options, once the market /operators picked a winner
20:45:17 <ttx> not a failure in abstracting
20:45:54 <ttx> anyway, I think we know what to work on to improve the proposal(s), let's move on to next topic
20:46:09 <johnthetubaguy> ttx: maybe... a bit of both for sure
20:46:12 <dhellmann> johnthetubaguy : that last thing I said may be something to add to your resolution (that we'd want projects to build transition tools)
20:46:23 <ttx> #info two different facets to polish: be clear why we are doing it to not open false hopes, and also be clear of when we'd be fine with breaking setups (after deprecation period I guess)
20:46:30 <johnthetubaguy> dhellmann: I think thats covered in the deprecation tag already, but I will check
20:46:40 <dhellmann> johnthetubaguy : ok
20:47:07 <ttx> #info if we'd do it to contract options, maybe the resolution on upstream support is unnecessary
20:47:13 <ttx> #topic Status update on other proposals
20:47:19 <ttx> Let's go quick on those
20:47:26 <ttx> * Golang CTI (https://review.openstack.org/410355) and Dims's Small steps for Go (https://etherpad.openstack.org/p/go-and-containers)
20:47:27 <ttx> dtroyer, dims: quick update ?
20:47:50 <dtroyer> I rev'ed the CTI doc Friday, think I got the comments, and see one last tab fail on my part
20:48:10 <dims> we have a git repo for golang-commons for oslo style ini and logs. trying to rustle up some contributors
20:48:13 <dtroyer> golang-client is current on the proposal (as far as it goes) for a real-world example
20:48:33 <ttx> ok so still WIP
20:48:51 <notmyname> I have a quick question on this topic
20:48:52 <ttx> dtroyer: let me know when ready for formal vote
20:48:57 <ttx> notmyname: sure
20:49:32 <dtroyer> ttx: there are a few details to be added, but the only thing really missing from the CTI is a translation story
20:49:41 <notmyname> does the TC want to see the dims/dtroyer work happen before anythign else? how does it fit with the things in the flavio resolution? what order does the tc want to see things happen in?
20:49:51 <dims> dtroyer : k8s folks are struggling there too
20:50:13 <dhellmann> dtroyer : translation may not be a high priority unless the i18n team is planning to change their scope to include non-ui tools
20:50:16 <clarkb> dtroyer: dims no gettext support in Go?
20:50:34 <dims> clarkb : tools around it
20:50:37 <ttx> notmyname: I think flaper87's framework calls for approval of the technical case before we work on how that would work
20:50:38 <fungi> also we should be pretty up-front with reasons golang-client is not a replacement of gophercloud. we already have enough reputation problems outside our community when it comes to reinventing other people's wheels
20:50:41 <dtroyer> clarkb: honestly I haven't spent more than an hour on it so far, so IDK
20:50:57 <dims> fungi : right
20:51:03 <ttx> notmyname: here they started working on part 2 assuming you would file something
20:51:07 <ttx> I think
20:51:13 <ttx> dims: ?
20:51:31 <dtroyer> I added a short history of that to dims' etherpad, and am using it here because it existed and I already had core on it and could iterate quickly wihtout impacting anyone else
20:51:47 <notmyname> we've held off once the new ML thread and proposals started
20:51:55 <dhellmann> #link https://governance.openstack.org/tc/reference/new-language-requirements.html
20:52:04 <ttx> (I feel like we went over the technical use case for Swift already, but we could use some formal stamp)
20:52:14 <dims> notmyname : i'd like swift team to help with the golang-commons if possible
20:52:33 <johnthetubaguy> ttx: +1 I was going to check the same thing
20:52:55 <dhellmann> fungi : +1
20:52:55 <cdent> it was unclear to me if the "why not gophercloud?" question was answered?
20:52:56 <notmyname> dims: from what I've seen, the new golang commons thing looks like a client tool? which was never under the no not python rule
20:53:02 <notmyname> which was somewhat confusing
20:53:03 <mugsie> cdent: me too
20:53:21 <notmyname> figuring out the ci and stuff like that is good, but the specifics seemed tangental
20:53:35 <ttx> notmyname: so we still need some "use case analysis" around swift to be approved. I don't think you need a lot more than what you already presented, but we need it to go through the new proces (and be approved rather than rejected)
20:53:56 <ttx> I suspect dims will help you do that
20:54:12 <notmyname> ttx: yeah, and we're planning on that. but my question is if the tc wants to see that before or after the current dims/dtroyer work
20:54:13 <ttx> (assumed that was in progress)
20:54:21 <ttx> I would say before
20:54:22 <dims> notmyname : it's not a client tool, it's code that can help with standardzing some of the operator visible things like logs and ini files
20:54:34 <ttx> based on "step 1" in that document coming before "step 2"
20:55:01 <ttx> need to switch to open discussion, as I had a couple topics to cover there
20:55:13 <dtroyer> ccdent, mugsie: let's talk in -dev after this if I can answer more
20:55:21 <notmyname> ttx: ack
20:55:27 <ttx> we can continue in #openstack-dev the discussion between dims and notmyname
20:55:31 <ttx> #topic Open discussion
20:55:36 <ttx> I have two topics to cover
20:55:39 <ttx> #info Encouraging Forum brainstorming
20:55:48 <ttx> Looks like we have a lot of "we could discuss this with operators at the Forum" moments, but not so many translate into ideas on the etherpads
20:55:51 <ttx> #link https://wiki.openstack.org/wiki/Forum/Boston2017
20:56:01 <ttx> Last week we discussed using the Forum to fill the missing link between user stories and implementation ideas and complete the feedback loop
20:56:06 <ttx> (in particular build up-to-date gap analysis by involving developers in the discussion)
20:56:16 <ttx> It feels like email reminders are not really cutting it, so I'd like to encourage you to get personal
20:56:24 <ttx> try to encourage people to think about and post discussion topics ideas
20:56:36 <ttx> Plan was to start filing formal topic ideas next week, so that the committee would be able to select a schedule for first half of April
20:56:43 <ttx> The deadline was pushed back one week
20:56:57 <ttx> (initial deadline was ~today)
20:57:03 <ttx> But maybe the whole timing is too short, I don't know
20:57:37 <johnthetubaguy> it feels quite soon after the PTG, but having the topics soon helps with requesting budget to attend
20:57:49 <dhellmann> the mysql/pg and messaging deprecations should go on that list
20:57:51 <ttx> yeah, wondering if the whole timing is not just too short
20:58:04 <ttx> goal was to publish schedule a month early
20:58:07 <ttx> (before the event)
20:58:42 <johnthetubaguy> ttx: I totally missed we had a deadline, I probably did know, but I think my head is assuming we sort that all much nearer the time
20:58:43 <dhellmann> I don't see a list from the Arch WG, is there one somewhere?
20:58:45 <ttx> on one hand we want time to figure out which topics are interesting, on the other we need the schedule published so people realize what will be discussed
20:59:03 <johnthetubaguy> ttx: I don't have all the specs approved for this cycle yet, so I am not totally thinking about next cycle
20:59:05 <ttx> dhellmann: I posted mines on the TC catchall
20:59:21 <ttx> My other topic was around Vision exercise feedback
20:59:37 <ttx> we can cover that one next week
20:59:53 <johnthetubaguy> I have a photo with 6 bullet points on it, that looks good
21:00:12 <ttx> ok, we are out of time.
21:00:20 <ttx> Thanks everyone!
21:00:34 <cdent> if folks get a chance look at https://github.com/Jermolene/TiddlyWiki5/pull/2371
21:00:36 <ttx> let's overflow to #openstack-dev
21:00:41 <cdent> whoops not that!
21:00:43 <jroll> thanks ttx
21:00:45 <ttx> #endmeeting