20:00:49 <ttx> #startmeeting tc
20:00:50 <openstack> Meeting started Tue Jan 17 20:00:49 2017 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:51 * smcginnis is hanging out with jroll in the corner
20:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:54 <openstack> The meeting name has been set to 'tc'
20:00:57 <jroll> :P
20:00:57 * AJaeger joins jroll and smcginnis
20:01:09 <dims> o/
20:01:16 <ttx> Hi everyone!
20:01:22 <ttx> Our agenda for today is at:
20:01:25 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:33 <EmilienM> o/
20:01:35 <ttx> I added a few items for the open discussion at the end, so let's keep some time to cover them
20:01:37 <mordred> o/
20:01:40 <flaper87> o/
20:01:42 <sdague> o/
20:01:43 <stevemar> o/
20:01:43 <ttx> A few easy ones first
20:01:45 <ttx> #topic Refresh I18n ATC list
20:01:49 <ttx> #link https://review.openstack.org/417569
20:01:53 <ttx> Nice refresh, no-brainer for me
20:01:55 <flaper87> ship it
20:02:00 <EmilienM> ++
20:02:08 <ttx> shipping in 10 seconds
20:02:11 <thingee> lgtm
20:02:22 <stevemar> do it up
20:02:25 <ttx> shipped
20:02:31 <ttx> #topic Amend new-language reference document
20:02:33 <ttx> #link https://review.openstack.org/418487
20:02:37 <ttx> Also a pretty simple change
20:02:48 <EmilienM> same!
20:02:54 <flaper87> DITTO
20:02:55 <thingee> ship ship
20:02:55 <ttx> shipping in 10 seconds unless someone screams really hard
20:02:58 <flaper87> ops
20:03:03 <stevemar> do it!
20:03:03 <thingee> SHIP
20:03:07 * flaper87 removes caps lock from his keyboard
20:03:08 <ttx> shipped
20:03:14 <ttx> OK, let's pick some Pike goals now
20:03:17 <ttx> #topic Pike goal: support python 3.5
20:03:22 <ttx> #link https://review.openstack.org/349069
20:03:26 <ttx> EmilienM: feels like this one has broad support ?
20:03:38 <flaper87> ship... it
20:03:40 <EmilienM> ditto again? python 3.5 didn't have any pushback
20:03:44 * flaper87 likes this meeting already
20:03:46 <EmilienM> ttx: yes ship it
20:03:48 <ttx> any reason to hold on this one ?
20:03:48 <jroll> \o/
20:03:50 <stevemar> do it up
20:04:00 <stevemar> so many projects are nearly there
20:04:01 <thingee> it has been sitting around for feedback and has good support
20:04:23 <ttx> alright, let's do this. Shipping in 10sec
20:04:35 <fungi> if there are any missing bits of ci standing in the way of projects implementing/testing py3k support, give us a heads up
20:04:41 <fungi> we currently consider that already done
20:04:48 <ttx> shipped
20:04:50 <dims> fungi : yep. will do
20:04:52 <fungi> (we being infra)
20:04:54 <ttx> #topic Pike goal: split out tempest plugins
20:04:55 <sigmavirus> fungi: y'all have been fantastic
20:04:57 <sigmavirus> dims too ;)
20:04:59 <ttx> #link https://review.openstack.org/369749
20:05:09 <ttx> EmilienM: this one sounds slightly more controversial ?
20:05:10 <EmilienM> it seems like this one is still under review
20:05:12 <EmilienM> yes
20:05:26 <thingee> and without mtreinish I'm not sure how far we're going to get
20:05:26 <ttx> We are running out of time though... should we have a plan B in case this one doesn't make it ?
20:05:39 <EmilienM> I have a plan B
20:05:44 <EmilienM> https://review.openstack.org/#/c/419706/
20:06:00 <fungi> i've abstained so far given the number of ptl -1s on 369749
20:06:02 <jroll> until today the -1s were for "please add a guide", but now I see a couple people disagreeing with the premise
20:06:21 <thingee> fungi +1
20:06:26 <ttx> yes, it's a bit less obviously beneficial than other things
20:06:29 <EmilienM> fungi: same here
20:06:46 <flaper87> yeah, it looks like this one needs some extra talking
20:06:50 <sdague> fungi: honestly, I think that there is confusion about the architecture there
20:07:09 <ttx> OK, shall we table it until someone (mtreinish?) addresses the concerns ?
20:07:13 <fungi> sdague: probably so, and i guess the goal can attempt to address that confusion
20:07:14 <sdague> tempest plugins were never designed to be in branches
20:07:16 <flaper87> TBH, If we manage to do the python3.5 goal for pike, I'll consider it a success already
20:07:19 <flaper87> :D
20:07:23 <flaper87> but let's not let that stop us
20:08:00 <ttx> EmilienM: shall we table it until someone (mtreinish?) addresses the concerns ?
20:08:03 <dims> flaper87 : nova/py35/tempest shows "Pass 1295 Failure 42 Skip 85" :)
20:08:09 <EmilienM> ttx: yes, most probably
20:08:10 <stevemar> ttx: yeah, wait til mtreinish is around i suppose
20:08:11 <dhellmann> ttx: it seems like we should wait on this one
20:08:13 <sdague> yeh dims has been making good progress
20:08:23 <ttx> ok, let's see the backup plan then
20:08:28 <ttx> #topic deploy-api-in-wsgi
20:08:32 <ttx> #link https://review.openstack.org/419706
20:08:36 <jroll> sdague: fwiw in-repo tempest plugins work fine with a small hack in project-config, this is just about ops/users AIUI
20:08:36 <EmilienM> ok let me introduce quickly
20:08:39 <ttx> That one was "moved" to Queens
20:08:50 <EmilienM> I was looking for a goal that might have a direct impact on operators
20:08:54 <flaper87> dims: w00h000
20:08:55 <EmilienM> and this one is quite interesting
20:09:15 <EmilienM> I moved it to Queens because I thought we already had 2 goals and stevemar made me realize 3 goals might be too much
20:09:20 * jroll loves this goal
20:09:30 <EmilienM> I don't think the amount of work is huge for this one
20:09:43 <EmilienM> but I'm probably missing something, specially for some projects (maybe neutron)
20:09:44 <ttx> EmilienM: do you think it could be a Pike goal if the tempest plugin stuff is deferred / abandoned ?
20:09:46 <flaper87> EmilienM: fwiw, I like this goal and I'd go as far as saying that it'd be great to do it in Pike and hold tempest for Queens
20:09:56 <EmilienM> ttx: yes, it would be doable I think
20:09:56 <stevemar> as many of you know keystone was one of the first to move to mod_wsgi + apache and ditch eventlet, its one of the best things we've done as far as operators are concerned
20:09:58 <thingee> we could leave this one pending if the back up plan for tempest related goal doesn't pass.
20:10:04 <dtroyer> flaper87: ++
20:10:13 <EmilienM> stevemar: yes exactly that
20:10:14 <ttx> We need more feedback on it though
20:10:15 <dims> stevemar : ++
20:10:19 <thingee> ttx +1
20:10:34 <sdague> so, I actually think because of some of the apache port binding weirdness, we actually need to get off appache for this to really work
20:10:43 <sdague> and explore other wsgi runtimes
20:10:49 <EmilienM> so, for next week folks can give feedback on wsgi goal, so we have a backup ready in case the other one doesn't make it
20:11:02 <sigmavirus> EmilienM: I'm surprised that Glance can't be deployed like you want but at the same time, I am not an expert ;)
20:11:02 <ttx> EmilienM: could you try to gather more PTl feedback on it, just in case we end up needing it ? Ideally we would choose the goals before end of month
20:11:05 <jroll> sdague: what weirdness, specifically?
20:11:12 <fungi> making it webserver agnostic seems generally fine to me
20:11:19 <EmilienM> sigmavirus: I'll need to investigate more
20:11:20 <dtroyer> does this goal need to be specifically about apache?  or just "some" wsgi server?
20:11:24 <EmilienM> ttx: yes, it's on my list.
20:11:27 <sdague> jroll: in order to separate out service logs you need a stanza where you can do it
20:11:31 <ttx> OK good
20:11:36 <EmilienM> fungi: yes that's the Goal
20:11:40 <sdague> which turns out to be a vhost
20:11:45 <stevemar> i think the wording said any possible web server
20:11:55 <EmilienM> fungi: only thing is devstack use apache, so for testing, we'll keep using apache
20:11:55 <stevemar> well sorry, that may be too broad :)
20:11:55 <sdague> which means we still have to bind all the weird ports
20:12:08 <clarkb> sdague: you can still have the python do the logging aiui (rather than rely on apache)
20:12:13 <ttx> EmilienM: in all cases it doesn't hurt to have a backlog -- it gives a chance to teams that are a lot behind to get an early start
20:12:15 <EmilienM> I think it's clear in the goal that you can use any webserver
20:12:26 <EmilienM> ttx: indeed
20:12:28 <jroll> dtroyer: it's already about just exposing a wsgi app that any wsgi-supporting thing can use
20:12:28 <jroll> sdague: ah right
20:12:28 * jroll plugs nginx/uwsgi
20:12:30 <sdague> clarkb: possibly
20:12:31 <dhellmann> dtroyer : the original idea was to do whatever devstack is doing, but once you have a WSGI app it should work with any server
20:12:35 <ttx> I feel like Python 3.5 is easier to pass now because we mentioned it last cycle
20:12:47 <sdague> anyway, the point is that the apache model turns out to be kind of clumsy
20:13:03 <EmilienM> we also need to consider this goal might affect small projects with lower bandwidth
20:13:06 <sdague> and would rather not have everyone put in the effort on the odd work arounds there throughout the community
20:13:17 <ttx> #info trying to address concerns in split-tempest-plugins, and gathering feedback on deploy-api-in-wsgi in case we need it as a backup plan
20:13:18 <clarkb> also for completeness you can also switch vhosts on name rather than poirt
20:13:23 <dhellmann> in order for this to be a well-defined goal, we need to pick *one* target, even if we do end up supporting others
20:13:25 <jroll> sdague: ++
20:13:29 <dhellmann> otherwise we'll have a lot of reinvention
20:13:32 <clarkb> nova.openstack.test:443 vs neutron.openstack.test:443
20:13:42 <flaper87> dhellmann: ++
20:13:49 <sdague> clarkb: you can, but then you have to distribute dns in your dev env
20:13:59 <clarkb> sdague: which we already do
20:14:03 <clarkb> to make multinode testing work
20:14:04 <dhellmann> so if there's an issue with apache, let's use another service, but let's definitely specify one
20:14:09 <sdague> clarkb: not for users
20:14:13 <sdague> clarkb: this is more than CI
20:14:20 <sdague> this has to work for developers as well
20:14:28 <dhellmann> yeah, I don't do dns
20:14:41 <clarkb> ok, just want to point out options here for completeness
20:14:48 * fungi notes we have an entire openstack service devoted to dns ;)
20:14:49 <clarkb> apache doesn't actually prevent you from doing this they way you want
20:14:51 <sdague> I am all in favor of us getting here, I just wanted to raise specific concerns
20:15:03 <jroll> I think it's solvable but doesn't want to dig into details here
20:15:05 <sdague> clarkb: it sort of does given the constraints of working deve environments
20:15:07 <jroll> s/doesn't/don't
20:15:08 <flaper87> let's elaborate more on this things on the review
20:15:11 <sdague> sure
20:15:15 <dhellmann> we could also decide that it's useful to have those logs combined *shrug*
20:15:27 <jroll> pls no
20:15:30 <EmilienM> sdague: please add it into the review
20:15:36 <stevemar> since this goal is more "operator focused" can we add some to the review? like mfisch?
20:15:40 <jroll> log overload already, with them separate
20:15:52 <fungi> it seems like a viable second pike goal, assuming enough projects are already close to doing it
20:15:56 <EmilienM> stevemar: I sent an email to openstack-dev and openstack-operators already
20:15:59 <ttx> yes, please all feed back to the review so that we have all the cards on the table for next week
20:16:39 <ttx> Anything more on that topic ? Any other goal that could serve as a Pike contender ?
20:16:50 <dhellmann> EmilienM : you may want to highlight the fact that we're now considering this for pike, not queens
20:16:55 <ttx> dhellmann: +1
20:17:03 <EmilienM> dhellmann: yes, I'll update it
20:17:30 <EmilienM> ttx: i'm done with this topic.
20:17:50 <ttx> OK, good!
20:17:54 <ttx> #topic Introduce assert:supports-api-compatibility
20:17:58 <ttx> #link https://review.openstack.org/418010
20:17:59 <dhellmann> while we're on goals, there has been a lot of interest in the quota goals, so it would be good for someone to line up to manage that for queens or r*
20:18:11 <ttx> mtreinish is at LCA so isn't around to present this
20:18:18 <ttx> I see it as a continuation of mordred's rant a few cycles ago
20:18:26 <ttx> that we could just say that we won't ever break an API
20:18:52 <ttx> making it an assert tag is a good way to achieve it
20:19:15 <jroll> timing makes this feel like it's an answer to the glance/community images debate, heh
20:19:32 <ttx> The review is pretty dry for the moment, what are your thoughts on that ?
20:19:48 <ttx> (only a few TC members commented so far)
20:19:56 <bswartz> how would the TC police that tag?
20:19:58 <dims> does the "API change guidelines" change?
20:20:07 <dhellmann> there was some pushback to the idea of having microversions as a goal because some folks think it's not a great approach. do we want to encode that answer in this tag?
20:20:15 <ttx> bswartz: we don't need to. projects decide whether they want the follow the rule or not
20:20:19 <dhellmann> bswartz : there's a requirement for a test job
20:20:23 <fungi> bswartz: same as for most of our tags, expect the community to self-regulate and propose addition/removal of it with justification
20:20:28 <thingee> bswartz from the requirements it was my understand that there be a test job
20:20:37 <ttx> ah, misunderstood the question
20:20:49 <jroll> how I read bswartz question: how does the tc validate that the api tests cover enough to be meaningful
20:20:49 <cdent> Is it useful to know that that the api-wg does not like the api change guidelines?
20:21:00 <bswartz> so if a project says they're following the tag, but then they don't, there's a way to catch the mistake before something bad happens
20:21:01 <dhellmann> cdent : yes
20:21:21 <sdague> cdent: it would be more useful if the api-wg changed the guideline then
20:21:22 <cdent> They are too easy to use as a false metric where following the letter of the law becomes more important than the spirit of helping users have a good (long term) experience
20:21:27 <thingee> sdague ++
20:21:37 <cdent> sdague: the api-wg has only just recently realized how little they liked the guidelines
20:21:45 <cdent> also, usual excuses about timelines etc
20:22:14 <cdent> and also it is rather clear, based on the experience of the past couple of weeks, that the members of the api-wg are not necessarily representative of the some of the common feelings on this topic
20:22:15 <thingee> we have an api change guideline to go off of. anyone is welcome to improve it.
20:22:17 <cdent> so it is a bit challenging
20:22:23 <dhellmann> we probably want to wait until that's worked out to approve this tag definition, then, because otherwise the requirements for the tag will change out from under teams
20:22:38 <thingee> dhellmann seems reasonable
20:22:47 * edleafe missed his calendar alarm and shuffles to the back of the room
20:22:52 <jroll> dhellmann: +1
20:22:54 <dhellmann> maybe someone can start a ML thread about it?
20:22:54 * mordred hands edleafe a pie
20:22:59 <dims> ++ dhellmann
20:23:00 <lbragstad> dhellmann ++
20:23:11 <edleafe> mordred: mmmmmm... pie!
20:23:13 <thingee> pie ++
20:23:21 <ttx> anyone wanting to sub for mtreinish and start a thread ?
20:23:46 <ttx> ideally someone who wants that tag to exist :)
20:23:48 <dhellmann> cdent : please do leave a comment on the review, if you haven't already
20:23:48 <cdent> are we talking about a thread about the tag or a thread about the need to change the guidelines
20:23:57 <cdent> dhellmann: yeah will do
20:23:57 <dhellmann> cdent : a bit of both
20:24:09 <cdent> if the latter, I can certainly do the latter
20:24:10 <sdague> ttx: so I think the ML thread really is about the api-wg not liking the guideline
20:24:15 <dhellmann> cdent : that's a good start, thanks
20:24:22 <ttx> sdague: Ah, misunderstood, ok
20:24:29 <cdent> k, I'll do that tomorrow
20:24:37 <sdague> because, I also do wonder about the api-wg opinion being representative of the projects, and a ML thread would help there
20:24:55 <ttx> sdague: ok so a more fundamental "is it a good idea at all"
20:25:41 <dims> thanks cdent
20:25:47 <sdague> well, honestly, https://review.openstack.org/#/c/418010/2/reference/tags/assert_supports-api-compatibility.rst seems like exactly what many of our users have been asking for
20:26:06 <sdague> and I agree that it lines up really strongly with mordred's rants on this subject
20:26:24 <cdent> I think compatibility is a good idea, I have no problem with that. The issue is with some of the metrics in the guideline
20:26:29 * thingee agrees strongly that mordred rants
20:26:39 <ttx> yes, can't wait for mordred to reapply that rant to the thread
20:26:39 * mordred rants
20:26:50 * ttx has been missing mordred's rants lately
20:27:08 <ttx> OK, anything more on that topic ?
20:27:12 <sdague> cdent: so is it more accurate that the overall guideline spirit is fine, but there are details the api-wg would like to refine?
20:27:15 * mordred has to withold rants occasionally so that people enjoy their return
20:27:36 <sdague> I'm trying to figure out if we're going from round earth to flat earth, or round earth to elipsoid earth
20:27:58 <cdent> sdague: I need to review them in detail, but I like they were being applied in the absolute rather than in sprit and that (sorry to be so squishy) felt unfortunate
20:28:19 * fungi observes that the earth is not a perfect ellipsoid, but in fact slightly eggish
20:28:19 <cdent> s/I like/I feel like/
20:28:51 <mordred> fungi: eggs are tasty
20:29:02 <cdent> It's akin to the way if you don't match metrics as a hospital in the NHS, they take away your funding.
20:29:05 <cdent> Backwards
20:29:23 <sdague> cdent: which is more about interpretation than content
20:29:28 * cdent will to make this morass much more clear in the email tomorrow
20:29:35 <sdague> ok, anyway, ML list might clarify
20:29:42 <mordred> cdent: https://en.wikipedia.org/wiki/Goodhart%27s_law
20:29:50 <cdent> sure, the content needs to be better about setting an interpretational context
20:30:03 <cdent> mordred: yes, that, thanks
20:30:26 <ttx> ok, let's move on, funny topics in open discussion
20:30:31 <sdague> mordred: sure, but the corolary is that there have been constant calls that things weren't clear enough so they should be written down
20:30:42 <sdague> and if now writing them down is wrong... *shrug*
20:30:57 <ttx> sdague: yes, that's slightly disappointing
20:31:23 <mordred> sdague: oh - no, I totally think we should write them down
20:31:44 <sdague> at the end of the day... "be a reasonable human being" still has to be assumed here. Nothing, written or unwritten, works if that's not there.
20:31:47 <dhellmann> aren't we just talking about being clear when we do write them down?
20:31:49 <mordred> sdague: just agreeing that we need to make sure to contextualize such that it's clear that there is a spirit that can be more important than the letter
20:31:56 <dhellmann> and writing down what we agree on, not just what the author agrees on?
20:32:02 <mordred> dhellmann: yah
20:32:27 * cdent has not intended to set off such a stir
20:32:29 <mordred> if we currently have places where people are chasing the wrong thing, we just need to adjust to make it clear what they should be chasing
20:32:37 <sdague> mordred: sure
20:32:39 <cdent> It was just this: the guidelines need review and revalidation before we depend on them.
20:32:54 <dims> cdent : totally
20:32:55 <ttx> cdent: said this way, kinda makes sense
20:32:58 <sdague> cdent: ok. I think it's always fair to revisit things
20:33:00 <dhellmann> right, let's just get everything lined up before we start sending folks off in the wrong direction
20:33:11 <cdent> (I've said as much in my comment on the tag review and will say as much in the email)
20:33:13 <sdague> but I think it's also important to realize people are already depending on them
20:33:17 <sdague> they've been around a while
20:33:30 <ttx> ok, so let's do that in the thread, and investigate how we'll actually test/verify that
20:33:50 <ttx> that tag isn't exactly time-sensitive so we can take the time to do it right
20:34:00 <ttx> #topic Open discussion
20:34:07 <ttx> * Date/location for Board+TC workshop on OpenStack Futures
20:34:13 <ttx> As you know we decided not to overload the PTG with a Board+TC meeting
20:34:21 <ttx> which I think was a sane decision given how busy that week is gearing up to be
20:34:31 <ttx> To make progress on that strategy topic, the Board is now proposing a separate 1- or 2-day workshop, sometimes in March
20:34:38 <ttx> One date/location they are floating is Boston the week of March 6th
20:34:47 <ttx> An alternate date/location would be to place it the day before the Ops Meetup in Milan (Italy), week of March 13
20:34:58 <ttx> I tend to prefer the latter because I can combine events to justify the trip, and it's further away from the Atlanta travel
20:35:03 <ttx> also we can visit flaper87
20:35:06 <dims> Boston location works for me!
20:35:18 <flaper87> As crazy as it sounds, I won't be around on the OPs mid-cycle
20:35:20 <flaper87> :(
20:35:30 <ttx> flaper87: dude!
20:35:33 <EmilienM> flaper87: what?
20:35:34 <flaper87> so, I prefer the 6th
20:35:40 <sdague> boston would be better for me
20:35:44 <ttx> ok, let me doodle it to check
20:35:45 <flaper87> yeah, another trip got in the middle
20:35:46 <EmilienM> same ^
20:35:47 <flaper87> :(
20:35:52 <EmilienM> ttx: can we vote maybeN
20:35:54 <ttx> just a sec
20:35:57 <EmilienM> sounds like we have time
20:36:08 <ttx> yes, setting up a doodle for a slightly more complex answer scheme
20:36:11 <flaper87> Actually, I'm out from the 8th
20:36:27 <stevemar> wouldn't the 7th make sense for boston too?
20:36:44 <fungi> i should be able to manage a couple days in boston. not as convenient as some places i can get direct flights, but it's still reasonably nearby that i can't complain
20:36:59 <AlanClark> just to interject - the 6th was a target to shoot at
20:36:59 <ttx> wow that thing sucks
20:37:07 <ttx> Let me try a startvote instead
20:37:11 <dhellmann> what's happening in boston that makes that a good location/date?
20:37:34 <stevemar> oh wait, march, not may...
20:37:52 <AlanClark> Boston was simply East Coast - figured it easy for TC members to get to ; my understand is most TC is on East Coast
20:37:59 <stevemar> dhellmann: yeah, same question
20:38:10 <dhellmann> AlanClark : ok, I was just curious
20:38:26 <dhellmann> esp. given the attachment to the ops meetup for the other date
20:38:41 <flaper87> what about late March ? After the 18th ? or early april ?
20:38:43 <ttx> One thing to consider though is that a lot is happening in the US this year, especially with two PTGs there
20:38:48 <EmilienM> ttx: did you send a doodle already on ML?  I probably missed it
20:39:00 <flaper87> EmilienM: think he's creating it
20:39:06 <ttx> no the doodle is not playing location/date game well
20:39:36 <EmilienM> maybe we can first pick a place and then a date or vice-versa?
20:40:45 <ttx> Oh, there is alaso Berlon the week of March 27, colocate with CloudNative Con
20:40:49 <ttx> Berlin*
20:41:07 <flaper87> yeah, that'd be perfect for me since I'll be there :P
20:41:24 <persia> Will observers be permitted?
20:41:26 <dhellmann> either location is fine with me, but the later into march we go the more likely it will overlap with my as-yet-not-locked-down holiday plans.
20:41:40 <ttx> https://framadate.org/bK8ziU1mhzjThdih
20:41:44 <mordred> yah - so far I'm fine with any of these dates
20:41:50 <dhellmann> not that it should be planned around me, of course
20:42:17 <mordred> and happy to do boston, berlin, or whatev
20:42:22 <ttx> One issue for me is that I'm /also/ scheduled for another round of training in Ann Arbor
20:42:42 <flaper87> ttx: will it be a 1 day thing?
20:43:20 <ttx> I would make it a 2-day thing to justify travel
20:43:33 <AlanClark> I would like to do 2 if possible
20:43:52 <flaper87> mmh, ok. 2 might not work for me if we do it on March 6th so I'll put maybe
20:44:42 <flaper87> done
20:45:03 <ttx> OK, people can continue to vote and I'll collect the results and post on the ML, circle back to Alan
20:45:19 <ttx> next topic was:
20:45:21 <ttx> * Base services
20:45:30 <ttx> The ML discussion on depending on Barbican has some interesting insights
20:45:31 <cdent> yes pleaes
20:45:38 <ttx> I think we (arch-WG and TC) need to move on with defining "base services" and start thinking adding more
20:45:48 <ttx> I'll push a thread on this this week
20:46:08 <ttx> because frankly, reinventing the wheel locally a dozen times to not have a dependency sounds a bit silly
20:46:30 <dtroyer> especially with something as easy to get wrong as crypto
20:46:50 <EmilienM> most of TC is US/Canada based, it would be odd to go in Europe. Maybe Board is mostly Europe based?
20:47:20 <dhellmann> EmilienM : I think the idea is that they may be going to that ops meetup as well
20:47:31 <thingee> dhellmann ++
20:47:31 <sdague> sure, though I think Duncan's point is pretty valid too, getting crypto wrong is not just about the crypto code itself, but how it's used. And there are some big usage questions right now.
20:47:41 <jbryce> EmilienM: board is pretty split between asia, europa and usa now
20:47:56 <EmilienM> jbryce, dhellmann: fair enough
20:47:57 <ttx> sdague: if Barbican is not the right solution, then we need to express that
20:48:07 <ttx> and why
20:48:11 <AlanClark> ttx could you add Berlin to the poll.  Board: 5 Asia, 4 EU, rest North Amer
20:48:20 <thingee> base service: http://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/base-services.rst
20:49:00 <mordred> ttx: the why part I think is important
20:49:09 <mordred> ttx: especially if it's actionable
20:49:38 <ttx> AlanClark: Added
20:49:48 <ttx> AlanClark: you could reuse it for the Board too :)
20:50:15 <AlanClark> ttx: great idea
20:50:59 <jbryce> it also sounded like expressing that (and why) may not fix barbican without finding more contributors
20:51:07 <sdague> thingee: so... to be clear, oslo.db doesn't mean you support other dbs, db migrations definitely can (and do) have dbisms in them.
20:51:14 <sdague> jbryce: yeh, that's how I read the thread
20:51:31 <mordred> jbryce: agree
20:51:33 <sdague> there are gaps, they are known, now by more people
20:51:47 <sdague> but closing them isn't really on anyone's radar
20:52:11 <fungi> on the other hand, projects reimplementing crypto primitives and tooling multiple times when those same people could contribute that same work to barbican could also be hypocritical
20:52:35 <dhellmann> ttx: milan is on that poll twice now?
20:52:47 <mordred> I think either barbican is good and everyone should use it for that purpose, or it isn't suitable for $reasons and we shoudl all know the reasons so we can have a discussion about what projects needing that functionality should do
20:52:49 <jbryce> i like the idea of thinking out what other services would be really useful to have as “base services” and thinking about it even broader than just services that there are openstack options for. as someone in the thread pointed out, starting with some basic assumptions early on (rdbms, mq) did help…those were not things that were all built in openstackland
20:53:05 <mordred> each project implemeting crypto individually and not coordinated is certainly the worst outcome
20:53:13 <thingee> sdague ok SpamapS ^
20:53:15 <mordred> jbryce: ++
20:53:53 <fungi> dhellmann: i only see one milan, but the field orders got moved around
20:53:55 <edleafe> mordred: +1 on multiple crypto == bad
20:54:10 <mordred> jbryce: in ad-hoc discussions I've had people ask me about things like statsd/graphite/elk and similar things, for which we do not have a coordinated answer
20:54:13 <dhellmann> fungi : and now reloading does show that
20:54:26 <sdague> fungi: maybe, except the primary concern is actually the barbican interface relying on a keystone token
20:54:29 <mordred> (and for the record, I've heard both "why don't you have an opinion" AND "please stay out of having an opinion"
20:54:39 <ttx> fungi: I had to add a column to modify the "Milan" choice to include ops meetup colocation
20:54:43 <ttx> fungi: should be all set now
20:54:54 <sdague> because the keystone token actually isn't secure enough for the kinds of operations you want to do with the secrets
20:55:02 <fungi> sdague: sure, maybe the solution is for the people who have a different need to collaborate on something not-barbican which has the alternate design they need
20:55:03 <edleafe> mordred: that means "why don't you have MY opinion" :)
20:55:14 <mordred> edleafe: yup
20:55:25 <ttx> Last thing I wanted to cover in open discussion was...
20:55:31 <ttx> * Next steps for Golang
20:55:33 <lbragstad> most use cases I've heard from barbican devs is that they want to be able to get a token for a specific secret (instead of all of them within a project)
20:55:35 <ttx> From flaper87's document it feels like someone needs to formally push step 1
20:55:43 <ttx> "Use case analysis"
20:55:47 <ttx> flaper87: Or should we consider that done ?
20:56:13 <dtroyer> I think one specific use case is done, not sure if that covers the general case though
20:56:33 <fungi> do we need more than one use case to get the ball rolling on the rest of the process?
20:56:45 <flaper87> yes, we need that first phase to be officialized for golang
20:56:53 <thingee> https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis
20:56:56 <ttx> flaper87: are you working on it ?
20:57:09 <ttx> or waiting for someone else to pick it up ?
20:57:20 <flaper87> I'm not because I think other folks have a better understanding of the use case for golang than myself
20:57:32 <flaper87> so, hoping someone from the swift team can help with this
20:57:35 <fungi> (my question about needing more than one use case was in response to dtroyer)
20:57:39 <flaper87> or anyone interested, really
20:57:47 <EmilienM> flaper87: it sounds fair.
20:58:04 <ttx> should we... trigger that in other folks ?
20:58:07 <dtroyer> fungi: sure.  I don't think we need more to start, or I should say I didn't wait for that to start…
20:58:24 <flaper87> ttx: I tried but I'll be more agressive this time
20:58:31 <ttx> or maybe dims can take it
20:58:31 <dtroyer> but I also have a want for it in a place that doesn't fall under this specific guideline (a non-service project)
20:58:39 * flaper87 will write to the mailing list to announce this has merged and to request for volunteers
20:58:50 <ttx> flaper87: +1
20:58:50 <flaper87> has been merged*
20:59:03 * thingee whispers to ttx that he has an item that wasn't posted
20:59:05 <dims> ack i can help with that
20:59:32 <ttx> dims, sdague added one option to the poll (Berlin) in case you want to file how much you love/hate it
20:59:34 <flaper87> dims: i'll send the email anyway, feel free to "o/" there too :)
20:59:48 <ttx> OK, last minute... Anything else, anyone ?
20:59:52 <thingee> o/
20:59:54 <dims> flaper87 : will do
21:00:01 <ttx> thingee: go for it
21:00:30 <EmilienM> #openstack-dev otherwise? (out of time now)
21:00:37 <thingee> we all agreed in previous discussions that improving vendor discoverability can be done regardless of things like official vendor project teams. I have communicated out my first intentions in improving things in the market place http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
21:00:47 <dims> ttx marked ifneed be for berlin
21:00:50 <thingee> feedback would be much appreciated since I haven't received much yet
21:01:11 <thingee> otherwise I'd like to give nova and cinder a first pass in demonstrating something that works with multiple projects with different matrices
21:01:11 <ttx> ack, please feed back to thingee's thread
21:01:18 <ttx> and we are out of time
21:01:21 <ttx> Thanks everyone!
21:01:26 <ttx> #endmeeting