20:01:39 <ttx> #startmeeting tc
20:01:40 <openstack> Meeting started Tue Nov 29 20:01:39 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:43 <openstack> The meeting name has been set to 'tc'
20:01:44 <ttx> Hi everyone!
20:01:46 <stevemar__> present!
20:01:53 <ttx> Thanks to dhellmann for chairing last week
20:01:58 <ttx> Our agenda for today:
20:02:01 <dhellmann> my pleasure
20:02:01 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:03 <mordred> o/
20:02:05 <flaper87> o/
20:02:11 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:17 <stevemar__> mtreinish and i were sippin' lattees in montreal last week
20:02:22 <ttx> #topic Add project Octavia to OpenStack big-tent (final discussion)
20:02:35 <ttx> #link https://review.openstack.org/313056
20:03:12 <EmilienM> ship it :)
20:03:21 <ttx> This was discussed last week, I couldn't spot any strong objection in the logs
20:03:24 <ttx> Feels like it's mostly reflecting a change that has already happened
20:03:36 <stevemar__> EmilienM: ++
20:03:37 <ttx> My only concern is with the timing: you mention the transition is to be completed in Ocata.
20:03:40 <ttx> dougwig: ocata-2 is Dec 15, ocata-3 is Jan 27 -- how early do you think you can complete that ?
20:04:00 <dhellmann> yes, that was my only concern, too
20:04:19 <dhellmann> if the transition doesn't happen quickly enough, what portion of octavia is part of "newton" or not?
20:04:20 * mtreinish is still surprised by how short the cycle is :)
20:04:22 <ttx> dhellmann: I guess given the cycle is short it can be done for ocata-3 ?
20:04:57 * dhellmann checks the release model for octavia
20:05:04 <flaper87> mtreinish: no kidding
20:05:05 <dougwig> we're going to try, but the staffing changes hit us as well. worst case, it finishes in P, and the end user API via neutron is not affected. we currently expect it to be done.
20:05:14 <amrith> ./
20:05:30 <johnsom> We are actively working on the neutron-lbaas/octavia merge, but I think that is a bit independent of the governance change as we are actively managing compatibility via neutron.
20:05:35 <dhellmann> ttx: it's cycle with intermediary, so as long as they have a final release I guess I'm OK with including it in newton
20:05:36 <ttx> dougwig: in that case you would just publish neutron-lbaas ?
20:05:41 <johnthetubaguy> I thought octavia already released things last cycle, so worst case it is similar this cycle?
20:05:48 <johnthetubaguy> johnsom: +1
20:05:50 <dougwig> ttx: aye.
20:06:01 <ttx> makes sense to me, thx for the precision
20:06:03 <dhellmann> ok, that sounds fine
20:06:06 <ttx> OK, no more objections from me, anyone else ?
20:06:19 <dougwig> i expect both neutron-lbaas and octavia to be required as packages in O, since the former will have the api proxy for backwards compat.
20:06:20 <dims> no objections
20:06:28 * flaper87 steals ttx's magic wand and approves Octavia
20:06:43 <johnsom> dougwig +1
20:06:58 <ttx> should we get formal approval from armax ?
20:07:01 <dhellmann> I just realized I said newton when I meant ocata
20:07:17 <flaper87> ttx: he was active in the review already
20:07:42 <ttx> sure, but not formal +1
20:08:03 <dhellmann> it seems reasonable to wait for a +1 from armax, but then to let ttx approve as soon as that happens
20:08:14 <dhellmann> without having to go through another meeting review
20:08:16 <flaper87> works for me
20:08:17 <dougwig> if you need that, ok. but we have had many conversations with armax, so i'm not worried.
20:08:33 <dhellmann> yeah, this is mostly to ensure the record is clear for posterity
20:08:40 <fungi> yeah, he chimed in on last week's tc discussion as well
20:08:45 <ttx> #agreed since neutron-lbaas is thorically in neutron currently, waiting for a formal +1 from armax, but ttx is clear to approve as soon as that happens
20:08:49 <johnsom> Yeah, armax is very supportive of this, but I am fine waiting for the rubber stamp.
20:09:30 <fungi> i can't find thorically in my dictionary
20:09:34 <ttx> he might chime in during the meeting
20:09:46 <ttx> fungi: it involves a hammer
20:09:54 <dhellmann> fungi : isn't the thoric the middle section of an insect?
20:09:56 * fungi is duly schooled
20:10:07 <dims> lol
20:10:10 <ttx> Alright, let's move on
20:10:22 <ttx> dougwig, johnsom: consider it almost-done :)
20:10:30 <johnsom> Grin, thanks!
20:10:39 <mordred> dhellmann: s/ic/ax/
20:10:48 <dhellmann> mordred : my joke was not as funny as ttx's
20:10:56 <ttx> #topic Reference doc for new language additions
20:11:01 <ttx> #link https://review.openstack.org/398875
20:11:09 <ttx> flaper87: want to introduce the topic ?
20:11:14 <flaper87> sure
20:11:27 * dims has to drop off :(
20:11:40 <ttx> dims: bye!
20:11:50 <stevemar__> ttx: great blog a few days ago btw (myth #1 touched on the topic)
20:12:01 <flaper87> So, I started this by doing a brain dump on my blog and then cleaned the brain dump a bit and wrote it down in the form of a reference document. This is very much a draft that I'd lie us to go over and clean up a bit
20:12:27 <flaper87> So, the current proposal is a 2-phase process
20:12:34 <ttx> stevemar__: thx!
20:12:50 <flaper87> the first phase is to discuss the needs of a new language and why the currently supported languages are not good enough
20:13:03 <flaper87> the second phase involves addressing the set of requirements listed in the proposal
20:13:33 <flaper87> I intentionally kept the bar high in the proposal because I want us to think about things that new languages should/shouldn't support before OpenStack adopts them
20:13:43 <flaper87> we can remove and/or add new requirements to the proposal
20:13:54 <flaper87> there have been some comments on it already from various folks
20:14:18 <dhellmann> I like the 2 phase structure
20:14:27 <ttx> mordred: you still have a blogpost queued to recount the javascript experience
20:14:33 <flaper87> I think one of the main objections is that it's too much work in advance
20:14:48 <ttx> dhellmann: yes, I like the idea of making people part of the solution, rather than proactively block progress
20:15:09 <flaper87> Now, I also want to mention something that has come up a couple of times
20:15:25 <ttx> flaper87: we could relax the oslo part -- I don't think a team that is not using some oslo lib would have to front the cost for a lib (or go equivalent) they would not use
20:16:04 <flaper87> There's a feeling that this proposal is not allowing for people to experiment and that it adds new requirements without having added the language yet. In my opinion, we've experimented with the process already and we did that with python
20:16:16 <flaper87> sure, different times and a single language but we learnt from that process
20:16:16 <johnthetubaguy> yeah, I am mostly +1 all the requirements except the oslo libs (we need a way to create such things though)
20:16:34 <ttx> flaper87: in the past we allowed experiments in feature branches and/or unofficial repos
20:16:37 <edleafe> ttx: but if they did implement a common thing that oslo implements, they should make it a lib/whatever to help future work in that language
20:16:46 <ttx> edleafe: right
20:16:50 <flaper87> ttx: johnthetubaguy ++ I don't have a good formula to figure out what libs (if any) should be required
20:16:55 <johnthetubaguy> so, I think if we talk more about the why in the process, many peoples fears will go away
20:17:01 <dhellmann> I don't think we need to say that all of the oslo libs need to be reproduced, but I do think we need to say that something like config should be done in a way consistent to openstack, not necessarily consistent to the language ecosystem
20:17:16 <edleafe> flaper87: logging comes to mind as a start...
20:17:20 <dtroyer> dhellmann: ++
20:17:25 <stevemar__> dhellmann: i like that
20:17:25 <johnthetubaguy> flaper87: there is a good point there, its hard to prove you can have a shared lib, if we don't try it... but hey.
20:17:27 <edleafe> dhellmann: yes
20:17:31 <ttx> dhellmann: yes arguably log/config could be upfront. messaging, maybe first-user
20:17:40 <ttx> same for oslo.db
20:17:45 <morgan> dhellmann: as long as the understanding is that if the openstack-consistent way can be done without an additonal lib, it should be fine.
20:17:45 <dhellmann> ttx: right
20:17:47 <flaper87> edleafe: right, so far I think I have logging and config but that's probably subjective
20:17:50 <dtroyer> also, the same sort of thinking that got us to olso in the first place should be expected, for things that didn't need an oslo lib in Python but might in naother language
20:18:05 <dhellmann> morgan : I'm not sure what that means?
20:18:08 <morgan> dhellmann: some languages don't need the extra mechanisms oslo.config provides to provide an equivalent.
20:18:15 <dhellmann> dtroyer : ++
20:18:19 <edleafe> flaper87: true, but requiring that o.vo be implemented is crazy talk
20:18:29 <morgan> richer base (stdlib) style support
20:18:31 <flaper87> dtroyer: right, that's my thought as well
20:18:33 <flaper87> edleafe: oh sure
20:18:34 <morgan> thats all.
20:18:37 <stevemar__> edleafe: yep
20:18:38 <ttx> and frankly, we had a lot of people complaining that "the TC doesn't want go", and telling those that they can be part of the solution in implementing goslo.config... could turn the table around
20:19:04 <dhellmann> morgan : I would be surprised to find another language with an implementation of the things that oslo.config does in a way that is compatible with oslo.config for doc generation, etc. There are a lot of ways to read INI files, but that's only one feature of that library.
20:19:19 <EmilienM> dhellmann: +1 with config. It's a good start helpful for our operators
20:19:30 <flaper87> TBH, if it can be proved that stdlib of language X does the same thing without having to add 10 modules to each project, I guess it's fine
20:19:43 <flaper87> dhellmann: ++
20:19:48 <morgan> flaper87: exactly
20:19:55 <morgan> that is all i was pointing out
20:20:03 <edleafe> flaper87: good point
20:20:07 <morgan> don't force a lib if it is demonstrobly proven to already exist
20:20:11 <flaper87> the point is, it needs to be proven.
20:20:11 <dhellmann> I'm not even certain we need to require something like oslo.messaging -- that's a layer I think we might say works differently in different languages
20:20:17 <morgan> flaper87: ++
20:20:23 <ttx> dhellmann: right
20:20:39 <morgan> oslo.config might have been a bad choice...
20:20:51 <morgan> oslo.messaging might have been a better example (as highlighted by dhellmann )
20:20:58 <fungi> it seems much more like an attempt to avoid a return to the old nova code copies, openstack/common, oslo-incubator...
20:21:07 <mordred> ttx: yes - the javascript blogpost is coming up
20:21:08 <edleafe> dhellmann: in that case, they should demonstrate the reason why messaging isn't applicable
20:21:21 <johnthetubaguy> right, the bit about being able to create shared libs, as needed, seems way more important
20:21:30 <ttx> fungi: yes, I'm actually more interested in having the mechanism to share, rather than exact bits of code
20:21:44 <ttx> what johnthetubaguy said
20:21:44 <flaper87> johnthetubaguy: indeed and I think that's in the current draft already
20:21:50 <dhellmann> fungi : also to avoid having diverging implementations where different pieces of openstack have different deployment needs based on their language
20:21:53 <dhellmann> edleafe : we can argue about the bad patterns in oslo.messaging another time :-)
20:21:54 <johnthetubaguy> flaper87: +1 I love that bit
20:21:56 <fungi> we continue to experience it in our python-based projects, so i don't know that we can completely get in front of it with any other language either
20:21:59 <ttx> And I'll only approve it if it's named goslo
20:22:02 <edleafe> dhellmann: :)
20:22:20 <stevemar__> ttx: not lillehammer?
20:22:25 <edleafe> ttx: I read that as 'go slo(w)'
20:22:36 <mordred> stevemar__: gillehammer
20:22:59 * ttx looks up norwegian cities starting with g
20:23:17 <flaper87> so, would people be ok with having a clause on the oslo topic saying that if there are compatible implementations for oslo.config and oslo.log then those don't need to be implemented?
20:23:28 <flaper87> of course, that needs to be proven and tested, I guess
20:23:33 <fungi> flaper87: yes. take pbr as a (relatively early) example... we have plenty of libraries that share solutions for common problems in python
20:23:41 <ttx> flaper87: ok, so it looks like you're on a good path here, but as always people will nitpick more when we get to  more details
20:23:48 <fungi> the common problems in go may not be the same set of problems
20:23:51 <dhellmann> flaper87 : the part I would want for oslo.log is the config layer that gets the underlying logging machinery to produce output like other openstack services
20:23:53 <mordred> "how does dependency management and stable branch maint work" and "how do dependencies get mirrored/pre-cached for the gate" are the ones that are going to be harder, to be quite honest
20:24:04 <johnthetubaguy> flaper87: do you think adding more about why in the process would help worry about the concerns about the innovation side of things?
20:24:11 <flaper87> dhellmann: I can use that as an example for oslo.log in the ref doc
20:24:12 <ttx> flaper87: did you have further questions that you need answers on before you can produce another draft ?
20:24:16 <mordred> writing code is a thing there are tons of people who love to do - so saying "we need some libraries written in $language" is unlikely to get much pushback
20:24:18 <dtroyer> flaper87: that's why I suggested taking a different perspective and trying to ensure that the externals remain consistent, and getting there informed by what we learned with oslo
20:24:24 <flaper87> johnthetubaguy: yeah, I'm planning to do that too :D
20:24:55 <flaper87> ttx: nope, tbh, I'd like to hear from other folks (especially folks that were involved in the previous golang discussions notmyname *hint*)
20:24:59 <mordred> espeically since the libraries in question have well defined semantics
20:25:05 <flaper87> other than that, I'm good for now and I've amends to work on
20:25:11 <flaper87> dtroyer: ++
20:25:12 <johnthetubaguy> flaper87: cool its that, so you have a prototype, you can save man years using this new language, help me understand the cost of not using python, well here you go, etc
20:25:33 <ttx> flaper87: if you want specific feedback you might want to reach out more directly
20:25:45 <mtreinish> johnthetubaguy: was that a go pun? :)
20:25:56 <mordred> wow
20:25:58 <flaper87> ttx: yup, added some of these folks to the review, I'll go in crazy ping mode next
20:25:59 <johnthetubaguy> heh, it wasn't meant to be
20:26:17 <ttx> Gjøvik
20:26:24 <stevemar__> lol
20:26:26 <mordred> yes. that
20:26:33 <ttx> because unicode ftw
20:26:33 <mordred> please god call it that
20:26:48 * flaper87 is done, fwiw
20:26:54 <ttx> flaper87: thx!
20:26:59 <ttx> moving on to next topic then
20:27:05 <stevemar__> thx for leading this flaper87
20:27:21 <flaper87> my pleasure
20:27:27 <ttx> #topic Add project Zun to OpenStack big-tent (initial discussion)
20:27:31 <ttx> #link https://review.openstack.org/402227
20:27:33 <hongbin> o/ for zun-related question
20:27:37 <ttx> hongbin: o/
20:27:42 <ttx> I'l do a quick intro
20:27:50 <ttx> As you may know, Magnum used to have COE-provisioning features and container-lifecycle features
20:27:59 <ttx> Since those are actually targeting two different use cases, a number of us advocated for separating the two sets
20:28:09 <ttx> Magnum retained the COE-provisioning abilities, and Zun was formed to host the container-lifecycle abilities
20:28:20 <ttx> So this is more of a project split than a new project, in my view
20:28:29 <mordred> yah
20:28:32 <ttx> That said I'm happy that hongbin took the time to completely set up the project and team separately before applying
20:28:49 <mordred> ++
20:28:54 <ttx> if anything that makes it even easier to make a call here
20:28:59 <flaper87> ++
20:29:13 <dhellmann> ++
20:29:29 <ttx> I'll go on record saying I'm still unconvinced this approach has potential, but I'll fight to give them the chance to prove me wrong
20:29:43 <dhellmann> same
20:29:44 <ttx> Comments, objections ?
20:29:48 <johnthetubaguy> same actually
20:29:54 <mtreinish> so I did have a question in the review about how they seem to have a nova driver in tree
20:29:55 <dhellmann> mtreinish , dims : there was a question about a "nova" tree in the zun repo
20:30:14 <mtreinish> I'm curious if that's just a temp thing or a long term direction
20:30:26 <hongbin> mtreinish: we have a driver that copied nova-docker code as a starting point
20:30:39 <mtreinish> because I don't think we want to encourage projects to use unstable unsupported interfaces from other projects
20:30:41 <fungi> dims seems to have addressed it half an hour ago
20:30:41 <dhellmann> yeah, I think from a packaging perspective we'd want that part of the tree renamed to avoid colliding with the regular nova tree
20:30:44 <armax> ttx: done
20:30:51 <hongbin> mtreinish: the rational is to avoid duplicate what nova was doing
20:30:52 <ttx> armax: great thanks!
20:31:02 <johnthetubaguy> mtreinish: +1, although I wouldn't block on that I guess
20:31:22 <dhellmann> no, it's not a blocker, just pointing out some potential issues with packaging and deployment
20:31:25 <ttx> (dougwig: octavia approved!)
20:32:05 <mtreinish> dhellmann: well it's a bit more than than that to me. It's more that it feels like we're sanctioning doing something the wrong way
20:32:14 <mtreinish> whether that's actually the case or not
20:32:14 <hongbin> ok, i will discuss the packaging and deployment issue with the team
20:32:22 <hongbin> thanks for the feedback
20:32:23 <mtreinish> but I agree it's not really a blocker
20:32:51 <dougwig> ttx: ty!
20:33:01 <johnthetubaguy> hongbin: nova doesn't really support out of tree drivers, because that interface isn't stable, its worth knowing
20:33:15 <hongbin> johnthetubaguy: ack
20:33:25 <ttx> that makes zun a bit brittle, basically
20:33:46 <johnthetubaguy> I am curious why the COE is not created by magnum, but thats a separate conversation I guess
20:34:14 <mtreinish> ttx: that's why I brought it up. Because if that's the long term direction to do that it raises some flags
20:34:53 <fungi> yeah, the docker driver's checkered past should serve as a signpost
20:34:56 <ttx> mtreinish: good catch
20:35:03 <ttx> Shall we wait until next week to finally approve as usual, or should we fast-track it since it's more of a project split ? (and it has already the required approvals)
20:35:21 <ttx> I'm fine letting it bake for the week to give others a chance to comment
20:36:07 <ttx> but also fine approving it now since there is nothing that forces us to do it in two meetings
20:36:15 <fungi> i'm fine with immediate approval on this one
20:36:32 <dhellmann> I agree, we can go ahead
20:36:45 <fungi> looks like we already have rc x10 on this
20:37:13 <ttx> alright then, let's win some precious minutes and not force hongbin to get up next week at very early hours
20:37:37 <ttx> approved
20:37:43 <ttx> hongbin: welcome back!
20:37:48 <hongbin> thanks all for reviewing the application
20:37:57 <hongbin> ttx: thx!
20:38:15 <ttx> let's move on to next topic...
20:38:20 <ttx> #topic Visions for the TC and OpenStack
20:38:36 <ttx> johnthetubaguy started two documents to work on visions for the TC and OpenStack:
20:38:40 <ttx> Add a draft TC vision structure: https://review.openstack.org/401225
20:38:46 <ttx> Add a draft OpenStack technical vision: https://review.openstack.org/401226
20:38:59 <ttx> I commented that those are not visions (yet) -- and I'm not convinced Gerrit changes are the best way to get to something we can all review
20:39:17 <ttx> I would rather collaborate on an etherpad for fast iterations / brainstorming, but I'm fine leaving the choices of weapons to whoever is pushing it :)
20:39:46 <johnthetubaguy> yeah, so I wanted to get something down for us to discuss
20:39:56 <johnthetubaguy> I guess the first thing, is the TC vision
20:39:56 <ttx> Also I would rather not do both in parallel :)
20:40:11 <ttx> there is only so many cans of worms you can hold open at the same time
20:40:25 <johnthetubaguy> yeah +1 that
20:40:27 <mordred> bah. we can hold SO MANY CANS of worms
20:40:28 <dhellmann> it's useful to have both to make the scope of each clear, but I agree that it'll be easier to work on them one at a time
20:40:42 <johnthetubaguy> these patches are really just me thinking out loud
20:40:54 <johnthetubaguy> yeah, I think the TC vision could include, we should create an OpenStack vision
20:41:09 <johnthetubaguy> but yeah, the scope is a bit clearer in my head now
20:41:25 <johnthetubaguy> so the TC vision, do people think we should start with that one?
20:41:35 <johnthetubaguy> and do people agree that would be useful?
20:41:42 <ttx> johnthetubaguy: "we created a vision for openstack", you mean :)
20:41:57 <johnthetubaguy> ttx: true, true
20:42:10 <dhellmann> johnthetubaguy : yes, I think it makes sense to start small and focus on a tc vision
20:42:12 <johnthetubaguy> ttx: I added a new patch on the TC one to have more vision-ey bits in it
20:42:50 <johnthetubaguy> so the personal struggle I have is wanting to point the general direction we are going
20:42:55 <ttx> johnthetubaguy: you weren't at the Ann Arbor training iirc ?
20:43:12 <johnthetubaguy> but I get a vision, with concrete what success lucks like is going to be more useful
20:43:15 <johnthetubaguy> ttx: I wasn't
20:43:49 <ttx> One trick is that some of us (who attended this training) now have a coherent vision (ha!) of what a vision looks like, would be great if gothicmindfood could give you an overview
20:43:49 <johnthetubaguy> I have been pointed at the Ziggman stuff on visions thats public
20:43:55 <ttx> would save you time
20:44:08 <edleafe> johnthetubaguy: haven't had a chance to read them yet, but what is the intended audience for these visions?
20:44:09 <dhellmann> some of the rest of what's here could go into the charter (the relationships stuff, for example) -- now that I say it here, I think maybe someone already said that on a review
20:44:20 <ttx> johnthetubaguy: it's not as if we practiced that skill that much, so you're not really late to the party :)
20:44:36 <johnthetubaguy> dhellmann: yeah, I think some of this probably migrates into an expanded charter
20:45:17 <johnthetubaguy> so I would love to see us get a TC vision agreed by the end of the PTG
20:45:37 <johnthetubaguy> my focus is really, how do we set oursevles up for success
20:46:05 <dhellmann> what changes do people want to see in the TC or how it operates between now and then?
20:46:16 <ttx> johnthetubaguy: I think we could reuse the stewardship WG to make regular progress on this
20:46:25 <dhellmann> where "then" is the end of the time frame laid out here, the end of Queens
20:46:32 <johnthetubaguy> ttx: yes, that makes sense to me
20:46:36 <johnthetubaguy> dhellmann: yeah
20:46:51 <johnthetubaguy> I picked the end of queens, because its in the future, but not too far away
20:47:06 <dhellmann> I think that's a good target
20:47:06 <ttx> I'm skeptical we can slowly turn the review into the final document though, so I would abandon them and invite interested people to join the SWG meetings / channel
20:47:20 <johnthetubaguy> ttx: yep, thats fine
20:47:36 <johnthetubaguy> I could get this into a etherpad, and pass it along to the next SWG
20:47:42 <ttx> that would be great
20:47:56 <fungi> i agree that should be far faster for initial draft collaboration
20:48:10 <fungi> final polish in code review should still be fine
20:48:18 <johnthetubaguy> yeah, after having drafted this, its totally an etherpad thing
20:48:24 <ttx> right, I'm pretty sure we'll still nitpick it to death in the end...
20:48:40 <johnthetubaguy> I was shooting for merging bits, and evolving it in tree, but its totally not that kind of thing
20:49:20 <dhellmann> yeah, and since we'll have multiples of these it might end up landing as a resolution instead of a top-level document
20:49:25 <ttx> #info We'll work on the vision for the TC first
20:49:35 <johnthetubaguy> dhellmann: yeah, not a bad idea
20:49:36 <ttx> #info The vision for the TC may include completing a vision for openstack
20:49:55 <johnthetubaguy> there are probably bits that turn into expanding bits of the charter I guess
20:50:08 <ttx> #info We'll grow a base proposal using the Stewardship WG as a vessel
20:50:11 <dhellmann> yeah, maybe those can come out into their own patches
20:50:50 <ttx> #action johnthetubaguy to turn the governance reviews into etherpad(s) to discuss in the WG, and encourage people interested to join to attend SWG WG meetings
20:51:15 <ttx> johnthetubaguy: did I capture the next steps well ?
20:51:15 <johnthetubaguy> anyways, wanted to try get *something* moving, so success
20:51:23 <dhellmann> johnthetubaguy : ++
20:51:38 <johnthetubaguy> ttx: yeah, I think thats good
20:51:41 <johnthetubaguy> thank you
20:51:42 <ttx> johnthetubaguy: cool
20:51:57 <ttx> Let's open it up for...
20:52:00 <ttx> #topic Open discussion
20:52:09 <ttx> stevemar: I saw you added the "formal-vote" topic to https://review.openstack.org/401990 ... did you want to discuss it in meeting ?
20:52:18 <ttx> Or you think we should generally discuss repository removals ?
20:52:21 <mtreinish> so I had one quick question, when is a good time to start discussing pike goals?
20:52:28 <dhellmann> I started a mailing list discussion about driver-specific teams. I would appreciate everyone participating in that discussion
20:52:30 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074
20:52:30 <mtreinish> I want to revive the tempest plugin goal at some point
20:52:31 <ttx> mtreinish: I'd say now
20:52:37 <EmilienM> mtreinish: I was about to run it :)
20:52:54 <EmilienM> mtreinish: it's on my list to send it tonight or tomorrow morning
20:52:58 <ttx> mtreinish: in a future "normal" cycle that would be around summit (middle of the cycle) time
20:53:21 <ttx> but there is no summit in the middle of Ocata so now is as good a time as any imho
20:53:52 <mtreinish> ttx: ok cool, I'll work on respinning that patch soon then
20:54:02 <ttx> #info EmilienM volunteers to drive Pike goals identification
20:54:10 <dhellmann> thanks, EmilienM!
20:54:35 <stevemar__> ttx: sorry, i thought i was being helpful and thought all repo removals needed their topic to be formal vote
20:54:36 <ttx> Note that we'll have rooms at the pTG available if people want to get together and make quick progress on whatever goal we end up defining
20:54:37 <EmilienM> #info EmilienM volunteers to also drive OpenStack goals feedback
20:55:23 <ttx> stevemar__: if someone objects to a removal during the "lazy consensus week" then i'll raise it for the meeting
20:55:29 <ttx> otherwise we'll just merge it
20:55:40 <stevemar__> ttx: rgr that, i'll change the topic then
20:55:44 <ttx> ok, I'll clean up the topic then
20:55:48 <ttx> stevemar__: done
20:55:52 <stevemar__> ++
20:56:04 <ttx> dhellmann: did you want to point people to the driver-team patches ?
20:56:14 <ttx> and/or the thread discussion ?
20:56:22 <ttx> It's on the agenda for next week meeting
20:56:23 <dhellmann> ttx: they're all linked from the ml thread that I just posted
20:56:26 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#108074
20:56:30 <dhellmann> there it is again
20:56:32 <ttx> oh, missed that, great
20:57:31 <ttx> ok, anything else ?
20:57:51 <dhellmann> this is one of those topics where the outcome can have unintended consequences, so please read carefully
20:58:27 <ttx> FWIW I'm making progress on making a neutral governance website that holds TC, UC , election docs
20:58:42 <ttx> maybe board one day, one never knows
20:58:43 <fungi> yeah, i'm just now looking for the change you linked for me earlier in the infra channel
20:58:52 <mtreinish> dhellmann: fwiw, I wonder why a vendor would really want tc oversight. Also how is that something we could actually exert any influence over?
20:59:07 <mtreinish> but I'll take that to the ml (or wait for next weeks meeting)
20:59:11 <ttx> fungi: cool, because we now publish to the new directory so the changes do not appear until you flip it
20:59:15 <dhellmann> mtreinish : the cisco team has already asked for it
20:59:19 <fungi> ttx: the files are getting published to the new /srv/static/tc tree so should be safe to update the vhost now
20:59:37 <dhellmann> mtreinish : https://review.openstack.org/363709
20:59:40 <ttx> fungi: ++
20:59:41 <mtreinish> dhellmann: right, but do they actual have a reason? or is it just they think that's a requirement for marketting or something?
20:59:48 <dhellmann> mtreinish : does it matter?
21:00:05 <ttx> mtreinish: discoverability is one, having their contributions count as "openstack" is another
21:00:10 <cdent> dhellmann: shouldn't it?
21:00:16 <dhellmann> mtreinish, cdent : I respond to that point in the thread, so I won't repeat myself here.
21:00:18 <ttx> and... we are off time
21:00:21 <fungi> ttx: seems to be https://review.openstack.org/395660 so i'll get it going here in a sec
21:00:30 <ttx> let's continue that discussion on the ML, the reviews and at the meeting next week
21:00:37 <ttx> #endmeeting