20:01:12 #startmeeting tc 20:01:13 Meeting started Tue Nov 8 20:01:12 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:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:16 The meeting name has been set to 'tc' 20:01:17 * edleafe lurks in the back 20:01:24 * mordred hands edleafe some popcorn 20:01:26 Hi everyone 20:01:27 * Rockyg slinks into back of room 20:01:29 o/ 20:01:33 Our agenda for today 20:01:35 * flaper87 right-clicks on edleafe and selects "Bring to front" option 20:01:37 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:39 Rockyg: you'll have to share edleafe's popcorn 20:01:46 flaper87: nice 20:01:49 Rockyg: help yourself! 20:01:54 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:02:00 #topic Adjust TC and PTL election timeframes 20:02:01 flaper87: heh 20:02:05 * sigmavirus lurks with edleafe 20:02:06 #link https://review.openstack.org/385951 20:02:21 * edleafe thinks we'll need more popcorn 20:02:22 OK so the deadline is up for this one 20:02:29 We got a lot of PTLs to chime in, which is great 20:02:39 Any last minute objection to getting this merged now ? 20:02:48 At this point I'd rather keep the votes and do wording tweaks in a separate change. 20:02:57 ++ 20:02:57 +1 for merge now 20:03:00 ++ 20:03:01 ++ 20:03:01 ttx ++ 20:03:02 mege it! 20:03:07 or merge even 20:03:13 Thanks, edleafe ! 20:03:13 stevemar: either one works really 20:03:16 done 20:03:29 merge now 20:03:37 #topic remove expired entries for extra-atcs 20:04:20 #link https://review.openstack.org/388170 20:04:29 This one seems ripe as well. Objections ? 20:04:35 one concern 20:04:39 though i don't object 20:04:54 this guts the ux team electorate 20:05:01 People can still re-add themselves 20:05:07 yep 20:05:12 which is why i don't object 20:05:40 just want to make sure people are aware that there are effectively no ux team contributors once this merges, until they ask to add some again 20:05:42 I did add the PTLs as reviewers 20:06:03 I suspect removing them will be a strong incentive 20:06:15 to refresh it in time for elections 20:06:32 fungi: or you could take an action to reach out more directly :) 20:06:32 should I try to contact Piet directly? 20:06:35 +1 fungi and ttx on the ux project 20:06:48 yeah, we should reach out 20:06:56 dhellmann: I don't think that should block the patch though 20:07:02 those entries are expired 20:07:04 I'd probably reach out, yeah 20:07:07 ++ ttx 20:07:14 ttx: ack 20:07:16 I mean, let's merge it and reach out anyway 20:07:19 same, they'd need to submit a change to governance to either readd or update expirations either way 20:07:24 so let's approve now + reach out 20:07:29 +1 20:07:54 #info we merge this one now but should reach out to UX directly so that they refresh their list before elections 20:08:04 ok done 20:08:15 i can write something to the -dev ml using their mailing list tag unless someone else was already planning to do so 20:08:26 I'll do it 20:08:30 thanks dhellmann! 20:08:38 #action dhellmann contact the ux team about their electorate 20:08:42 #action dhellmann will reach out to UX for extra-atc refresh 20:08:47 #undo 20:08:48 Removing item from minutes: 20:08:56 #topic Add project Tricircle to OpenStack big-tent 20:09:04 #link https://review.openstack.org/338796 20:09:05 hi 20:09:10 look it's a joehuang 20:09:12 joehuang: hi! 20:09:16 Quick intro... this project team was proposed back in July 20:09:26 Back then it was rejected, in part because making it an official project created confusion as to what the top API for an OpenStack cloud is 20:09:34 in part because the proxying approach sounded a bit brittle 20:09:44 joehuang worked with mordred to limit the scope of the team, which resulted in a split of Tricircle repos 20:09:57 Tricircle is now focused on providing Network automation across region boundaries 20:10:10 The "top cell" proxying stuff has been renamed to trio2o is kept unofficial/separate 20:10:19 which removes most of my "slippery slope" concerns 20:10:25 yup. same here 20:10:28 I think this is a great split 20:10:31 yes, one second, 3 thanks:) 20:10:32 joehuang, mordred: anything to add ? 20:10:46 Thank you for your time to talk with most of TCs (and also Russell and Armando) for a while in Barcelona summit, but missed the chance to talk with some TCs due to session overlapping. 20:11:00 I'd just like to say that I think the goals of the new slimmer tricircle are things that would be quite useful to end users 20:11:02 Thanks to Monty for helping Tricircle move forward, and learned that Tricircle and Shade/Oaktree in OpenStack-Infra can compliment each other for multi-clouds. Thanks to Thirrey for allocating summit venue and session slots. 20:11:16 Thank you for your insistance in API, which makes Tricircle being more focused and better and better. 20:11:24 joehuang: thanks for working with us on getting this to a good place! 20:11:37 joehuang: thanks for your patience ! 20:11:38 thank you all again 20:11:45 Questions, comments ? 20:11:52 Similar requirements could also be found in the ops session in OpenStack Barcelona summit "Control Plane Design (multi-region)" Line 25~26, 47~50: https://etherpad.openstack.org/p/BCN-ops-control-plane-design 20:12:13 they need tricircle networking capability across region 20:13:26 joehuang : any feedback from neutron cores/ptl on this? (just curious) 20:13:42 1 comment: I've seen more tricircle activity on the mailing list than even some official projects (glance, security, etc.) and I think that bodes well 20:13:53 I talked with Armando in Barcelona 20:13:56 so tricircle is limited to only networking functions now? 20:14:04 sigmavirus: ++ 20:14:08 yes, and nice organizational diversity on the project too 20:14:12 sigmavirus ++ 20:14:23 to dhellmann yes 20:14:24 joehuang : cool 20:14:32 dhellmann: it facilitates bridging networking functions across cloud regions 20:14:44 talked to Armando in Barcelona 20:14:53 joehuang : and the implementation is through a neutron plugin, and not a substitute neutron API? 20:14:53 (not finished yet afaict) 20:15:17 to dhellmann, yes plugin, no api substitue 20:15:26 joehuang : great, thanks for confirming that 20:15:26 sounds like most of the concerns have been addressed 20:15:34 will users see the regions similarly to how they appear for Compute operations? ie, user's only see one region setup 20:15:34 indeed 20:15:34 * dims steps out to answer the door 20:15:36 thank you 20:15:45 to dtroyer, yes 20:15:51 I think the scope is *much* improved, totally see the need for the network orchestration, but I would love a +1 from armax on that 20:15:51 see multi-region 20:16:01 joehuang: thanks 20:16:35 joehuang: I'm curious about how your interactions with the neutron team have been going. I know they are decomposing the stadium. Was there any interest in adopting the driver you've written? 20:16:39 armax's +1 wouldn't hurt the proposal, but I'm fine with it as it stands 20:17:02 Armax said he will review it, but I don't know he finished it or not after back from summit 20:17:25 dhellmann: was about to ask that +1 20:17:54 to dhellmann, there are tricircle's database, standalone API service, and XJOB 20:18:24 it's not simply a plugin, including local and central plugin 20:18:25 I'm fine waiting for at least a comment from armax before finally approving 20:18:34 joehuang : ah, I see. 20:19:08 ttx: we'll have to wait till next week anyway, there's no quorum on the patch yet 20:19:14 as long as there is no proxy api for neutron itself, I think it's fine to move ahead. Especially since the neutron team is dissolving the stadium. 20:19:23 dhellmann: ++ 20:19:32 but yeah, wait for quorum, of course :-) 20:19:41 dissolving a stadium seems like it would take much longer than using explosives to implode it ... 20:19:50 unless it's some really strong acid 20:20:04 lol 20:20:33 #info No objections so far, but some TC members would really much like to get armax's opinion on it before final approval 20:20:37 would like to know when Amando can give feedback? He was added to reviewer since july 20:21:08 We'll reach out to him and proceed next week with or without his comment 20:21:13 ++ 20:21:20 I don't want to hold it to some other PTL approval 20:21:26 ok, thank you all 20:21:36 joehuang: thanks for the work and the patience 20:21:39 Also lots of TC members off today, won't hurt to let them ask a few more questions 20:21:45 my pleasure :) 20:21:50 Sorry that may mean crazy hours for you next week as well 20:22:05 slepless night:) 20:22:14 #info Tricircle shall be finally approved (barring any objection) next week meeting 20:22:15 but my pleasure anyway:) 20:22:49 joehuang: thanks for making the personal time sacrifice to be here, it is really helpful 20:22:58 next topic, small reordering upon request 20:22:58 ++ 20:23:03 joehuang : thanks! 20:23:09 thanks bye 20:23:10 #topic Add "Assume Good Faith" to OpenStack principles 20:23:18 #link https://review.openstack.org/365590 20:23:22 We discussed that one last week 20:23:32 in flaper87's absence nobody felt strongly for or against it, lots of +0s 20:23:39 personally I think that for something to make it into our principles list there needs to be enough people caring strongly about it 20:23:48 ++ 20:23:49 otherwise I fear we'll end up with a very long list of "sure, why not" principles 20:23:57 the current version feels more like an admonition than a principle 20:23:58 so we waited until flaper87 was back 20:23:59 I am still struggling with this, it just doesn't feel right to be _here_. 20:24:27 yeah, it's definitely something I like, I'm not sure it fits with the other items we've put in this category so far, though 20:24:35 dtroyer: where would you put it ? 20:24:39 My position is that we don't have a critical mass of people that think it should definitely be a part of our principles 20:24:58 I'm fine with it if there is such a critical mass, but I just don't see it 20:25:03 flaper87 : last week we talked about adding a "communication guidelines" section to the PTG 20:25:19 flaper87: I'm not sure 20:25:25 dhellmann: mmh, I guess that could help 20:25:27 How would adding this change anything? That's what I don't understand 20:25:35 ttx: I can have a pass at it today 20:25:43 armax: that would be awesome thank you 20:26:15 flaper87: I agree with the ideal 20:26:16 If folks feel more comfortable having it in the PTG, then I'll move it there. I'm, of course, ok with it being in the principles reference doc 20:26:19 edleafe: as I understand it, the principles documentation is meant to document what are our principles today 20:26:28 but I can see why peopl may not feel as comfortable with it 20:26:35 edleafe: not so much "what does this fix?" or "what does this do to change things?" 20:26:37 flaper87 : dhellmann : y "communication guidelines" would seem better 20:26:38 sigmavirus: +1 20:26:47 * sigmavirus wasn't around last week but supports this being documented somewhere 20:26:58 sigmavirus ++ 20:27:00 i was in favor of dhellmann's suggestion last week for 'a "how to communicate successfully" section of the project team guide' 20:27:02 yeah, I would be much more comfortable if personal behavior guidelines like this were in the Project Team Guide or the CoC 20:27:07 I don't have particularly strong feelings as to where, although I think it could fit there 20:27:13 sigmavirus: IMO, it's more of a "where do we _want_ to be", not "where are we now" 20:27:34 edleafe : it will become that, but we've said at this point we're still trying to write down where we are 20:27:37 because I don't think we should have 100 principles and I can see us having a 100 personal behavior guidelines :) 20:27:55 +1 20:28:04 ugh, I hope not 100 of those, either 20:28:06 ttx: so it's not just about personal behaviour, in my opinion. Yes communication is the primary place where we should be assuming good faith, but it also applies in patches 20:28:10 Ok, I'll move it... I don't feel strongly about this being a principle 20:28:11 dhellmann: figure of speech 20:28:15 edleafe: I hope the majority of the community already does this… but maybe not given the kinds of comments made during the last election cycle 20:28:19 * flaper87 really thought it was, though. 20:28:21 I think that a lot of the mailing discussions about mass sending of patches are missing this point 20:28:23 ttx: :-) 20:28:24 sigmavirus: code is speech ;) 20:28:43 dtroyer: exactly. It's aspirational, but not where things are today 20:28:45 sigmavirus: or mass bug subscriptions :) 20:28:48 fungi: fair, I think most people distinguish between "code" and "email" where they view email more as communication 20:29:01 stevemar: right, these are things that are annoying, but I suspect the people are doing it in good faith 20:29:08 edleafe: it's also difficult to mandate 20:29:13 i expect as a community we communicate more through code review comments than e-mail 20:29:32 ttx: that too 20:29:33 #agreed this should be put in the Project Team Guide instead 20:29:34 1/b 40 20:29:36 fungi: absolutely. I'm just thinking of events on the mailing where people felt they were being attacked instead of assuming good faith 20:29:36 oops. 20:29:44 fungi : that's certainly my goal 20:29:46 jroll: don't use irssi :P 20:29:48 would people feel comfortable with this being in the principles doc once we start adding "where we want to be" ? 20:29:58 #info no critical mass of members agree this should live as a principle at this stage 20:30:04 sigmavirus: I would never (weechat) :D 20:30:06 flaper87: yes 20:30:11 Or is the concept of assuming good faith that folks are not comfortable with ? 20:30:14 sigmavirus: i agree it's just as possible to crop up in bug triage, code review, irc channels... we have lots of means of communication 20:30:21 I mean, comfortable with having it in the principles file 20:30:27 mmh 20:30:30 flaper87: sounds like a "vision" rather than a "principles list" :) 20:30:32 flaper87: that's a good question 20:30:34 flaper87 : possibly phrased differently 20:30:48 flaper87: I don't think it's possible to tell people how to feel 20:30:59 dhellmann: what would be your suggestion? Asking because the last wording came out of feedback 20:31:00 I don 't think "where we want to be" belongs in the principles doc 20:31:03 flaper87 : maybe something more general about taking open and clear communication seriously 20:31:06 The feedback was to make it more asperational 20:31:28 however, it's possible to explain that certain positions in communication are more effective at getting your point across than others, and at understanding the points made by others 20:31:28 edleafe: that's not how I read flaper87's review in the slightest 20:31:56 edleafe: it's not how ppl should feel but how they should communicate 20:32:45 Ok, I'll abandon this path or reword it entirely to not mention good faith but focus on communication 20:32:48 "assuming good faith" is less about feeling a certain way, and more about making conscious vs unconscious choices when interpreting personal communication, private or public 20:32:52 edleafe: I still think it's valuable that we document expected communication behavior -- just think it's not a "principle", and should live in the Poject Team Guide instead 20:32:54 Well, the principle is we act in good faith. 20:32:57 fungi:++ 20:33:40 Rockyg: right 20:33:50 flaper87 : I have some ideas about the communication angle, if you'd like to work together on that 20:33:58 Positive communication is a great angle, even if you don't assume someone is acting in good faith. Always rise above. 20:34:07 dhellmann: I'd appreciate your help on this, thanks 20:34:27 flaper87 : cool, maybe early next week we can chat 20:34:42 sounds perfect, this week would be impossible for me 20:34:55 ok, let's move on ? 20:35:02 yup, I'm good 20:35:12 #topic Create a project tag for zero-downtime upgrades 20:35:18 #link https://review.openstack.org/372686 20:35:30 This one looks pretty close. 20:35:39 There is a one-word change suggested by Doug that we might want to add before or after we approve it 20:36:30 getting the testing going on that one is going to be hard, but i appreciate the high target/goal that dolphm is setting 20:36:34 unless dolphm is around to fix it, we can approve this and then change the word in a subsequent change ? 20:36:48 sounds fine to me 20:36:49 stevemar: ++ 20:37:05 I like the phrase "continuous tempest" 20:37:11 i am around 20:37:12 stevemar: yes. I like that it's not ready to apply but sets the vision 20:37:25 i'm happy to make the change, but wanted to wait for any additional feedback before doing a minor revision 20:37:44 dolphm: we can either approve it now or you fix it and we reapply our votes 20:38:02 dolphm: it has majority support already 20:38:06 ttx: I'm OK with changing that word later 20:38:22 ttx: just submitted the revision :) 20:38:23 yes, it's not as if people would apply that tag tomorrow 20:38:50 ok, reapply votes 20:38:58 I'm first 20:39:54 stevemar: ? 20:40:49 last call 20:41:17 were we going to also discuss the follow on change? https://review.openstack.org/#/c/389300 20:41:29 ok, approving now 20:41:30 sorry, double booked... 20:42:04 ttx: +1 from me :) 20:42:05 hmm, now I'm confused 20:42:30 stevemar: i proposed a minor revision and cleared your vote 20:42:45 Somehow I missed that there were two of those 20:42:52 dolphm: yes, i see that, re-adding it now (even if it's approved) 20:42:59 zero downtime is less restrictive than zero impact 20:43:00 the subsequent change (zero-impact upgrades) was proposed substantially more recently (in case we want more time to socialize it) 20:43:06 johnthetubaguy: so yes we should 20:43:19 fungi: other way around 20:43:34 fungi: zero-impact is the ultimate goal 20:43:45 the session on these at the summit was good, there is *down* and a bit degraded, and *no* degredation 20:43:48 i think that's what i said? 20:44:08 fungi: oh wow, i misread :) 20:44:11 zero-impact looks ok to me 20:44:15 fungi: you were totally correct 20:44:27 okay, just making sure i was reading the specs the right way 'round ;) 20:44:36 I propose we approve it too unless someone objects 20:44:50 #link https://review.openstack.org/#/c/389300 20:44:57 even if it wasn't formally on the agenda 20:45:40 yeah, I think approve both, I like the completeness that gives us 20:46:02 alright then, last chance to vote on it 20:46:06 it's been up and had the formal-vote tag for a few weeks at this point, so seems like plenty of time 20:46:29 annnd... approved 20:46:41 Thanks dolphm for painting that shiny picture 20:46:47 \o/ 20:46:51 #topic Add "servant leadership" to principles 20:46:51 +1 20:46:56 now we just need some projects to start buying the reprints 20:46:57 #link https://review.openstack.org/390864 20:47:18 checking out the last rev 20:47:31 ohai 20:47:40 jroll: will you kill me if I nitpick two words at this point? 20:47:53 mordred: :) 20:47:54 oh - nevermind - it's consistent with other principles 20:47:57 We are not allowed to pass a principle without nitpicking anyway 20:47:58 mordred: I've had patches in flight for nine months in the past, this is nothing 20:48:18 ttx: You should add "nitpicking" as a principle 20:48:19 I like it 20:48:31 edleafe: maybe an expected behavior 20:48:34 lol 20:48:39 * mordred was going to quibble about the word "should" 20:48:45 edleafe : I think we call that bike shedding, don't we? ;-) 20:48:47 jroll: I have patches still open from 2014 20:48:52 mordred: you want "shalt" ? 20:48:53 it's slightly disjoint with the respective electorates, but i'm okay with the assertion that leaders serve more people than merely those who are able to vote to elect them 20:48:55 well, wouldn't it really be bikeshedding :-) 20:49:00 ttx: I just wanted to remove the word should 20:49:10 mordred: I purge sometimes :) 20:49:28 "OpenStack leaders should hold their positions only in order to serve" to "OpenStack leaders hold their positions in order to serve" 20:49:28 I think we can refine the wording but I think it is a key principle we have 20:49:34 mordred: yeah, an ietf reading of "should" there waters it down, agreed 20:49:41 dang dhellmann totally type faster... 20:49:47 fungi: yah. the ietf infects my brain 20:49:49 i prefer an ietf "must" 20:49:50 mordred: yes, I kind of agree with you here 20:50:03 I think it's great though - maybe that's a follow up patch? 20:50:11 mmm, yeah, that's a good point 20:50:13 mordred : ++ to removing 20:50:26 maybe jroll can ninja it 20:50:34 same with the TC line - the PTL line is good 20:50:40 I could 20:50:47 * dhellmann makes sound effects to go with jroll's ninja-ing 20:50:57 clickety click 20:51:18 ninja'd 20:51:27 ttx: I didn't know you were a foley artist 20:51:34 jroll: stopped the wallclock, ninja time 8.33Sec 20:52:16 ttx: I'm slow today because sitting on the couch 20:52:18 reapply votes ad lib 20:52:37 jroll : "contributors to and users"...sounds slightly off 20:52:52 dims "and users of" 20:52:53 "contributors to and users of" 20:52:54 dims: "contributors to and users of" 20:53:07 contributors to the project and users of the project 20:53:10 I did a double read on that one too 20:53:12 would be the long form 20:53:26 kk 20:53:33 happy to do grammar-y things in a follow-up if this is hard to read :) 20:53:34 I think you want some commas: contributors to, and users of, ... 20:53:45 dims: nitpicking accepted, we can now proceed 20:54:05 the check queue is on fire today 20:54:06 hehe, i already voted 20:54:13 approved 20:54:18 #topic Open discussion 20:54:29 One change I wanted to attract your attention on is the Neutron project cleanup patch 20:54:33 #link https://review.openstack.org/#/c/392010/ 20:54:43 In particular I was wondering if neutron-vpnaas can be un-officialized this fast, since it was assert:follows-standard-deprecation 20:54:55 I wonder if we should not mandate a longer path for that one 20:55:07 quick note, I'll have a patch to clean up a couple ironic governance things sometime this week 20:55:10 (otherwise there is a risk of depreciating the protection supposedly offered by this tag) 20:55:20 I think we should ... HOWEVER ... it apparently has no humans 20:55:28 so we may be finding ourselves in a tricky spot 20:55:32 (ironic clarified what does and doesn't belong, and also has a dead project or two) 20:55:41 yeah... hopefully it doesn't have any user either 20:56:04 if it's going to bypass the deprecation period, we need to make a lot of noise about that so any users do know 20:56:17 mordred: in an ideal world the thread on -ops that the deprecation process would raise would confirm that there is no user 20:56:28 and if there are, could trigger them to actually take it over 20:56:31 similar questions were raised in one of the teams' driver removal discussions 20:56:40 we have a nice long list of patches related to the cycle goal already 20:56:42 #link https://review.openstack.org/#/q/topic:goal-remove-incubated-oslo-code 20:57:31 mordred: though in all fairness they are not removing the feature 20:57:56 so /technically/ nothing is deprecated or removed 20:58:02 just left to bitrot 20:58:03 i guess at some point ttx will just fast-approve the topic:goal-remove-incubated-oslo-code changes that have sufficient roll-call +1 right? 20:58:08 to all new TC members, I offered to post this PSA in the TC meeting today for gothicmindfood who isn't able to attend. Would you please let her know what your schedule looks like to attend the TC training similar to the one which was conducted earlier this year. Thanks! 20:58:08 fungi: yes 20:58:49 anyway, if you carte one way or another, please chime on the patch. We'll likely review that one next week 20:58:53 care* 20:59:01 amrith: I heard her say 'next year' in BCN, do you know if that is still the case? 20:59:08 "2017" 20:59:39 FYI PTG registration should officially open today or tomorrow 20:59:52 depending on how much energy I have left to review forms and web pages 21:00:13 and time is up 21:00:17 dtroyer, I believe that you are correct. let me check if she provided me with some dates. 21:00:18 fungi : yes, the approval rules are at http://governance.openstack.org/reference/house-rules.html#goal-updates-from-ptls 21:00:20 I don't think so though 21:00:25 one second, will catch you 21:00:29 Thanks everyone! 21:00:30 on some other channel if not this one 21:00:30 thanks ttx 21:00:32 #endmeeting