20:01:43 #startmeeting tc 20:01:44 Meeting started Tue Nov 22 20:01:43 2016 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:49 The meeting name has been set to 'tc' 20:01:54 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:01:54 #info ttx is on the road this week and asked dhellmann to act as chair for today 20:01:54 #link our agenda https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:05 #topic Rearrange presentation of Principles 20:02:11 #link https://review.openstack.org/394786 20:02:22 This one is a pretty straightforward change of the order of the principles list. 20:02:24 There were some wording changes in an earlier draft, but those were moved to a follow-up (which we will discuss next). 20:02:39 Does anyone have any comments to raise? 20:02:52 I think everyone present has voted +1 already 20:03:06 no concerns here 20:03:18 dhellmann : +1 20:03:18 i hadn't, but have now. was waiting to see some other comments addressed last week 20:03:26 lgtm 20:03:31 I don't have approval rights, so we'll just cast votes today and let ttx approve when he's back online 20:03:47 ah, sorry, fungi & dims, I missed that you hadn't voted 20:03:58 let's move on then if there's no discussion 20:04:04 #topic Prefer voluntary participation 20:04:11 #link https://review.openstack.org/398540 20:04:18 This patch updates the “Participation is Voluntary” principle to try to improve on how it states the original spirit. 20:04:58 there's some additional discussion of even more alternate wording suggestion 20:05:34 johnthetubaguy : were you suggesting that the other change you link (which we'll discuss next) should be taken instead of or in addition to this one? 20:05:53 I was unclear, sorry 20:06:08 I may also just be undercaffeinated 20:06:09 I meant the next change fixes ending on a positive note 20:06:25 but I also like improving the current wording 20:06:33 ok 20:06:42 endign the document… in my comment I was referring to ending the paragraph (in re Eoghan's suggested alternative) 20:07:09 dtroyer : yes, that makes sense. 20:07:38 it seems like we think this is an improvement, even though it could be improved further 20:07:39 oops, yeah the document 20:07:53 everything could always be improved further 20:08:00 * mordred is perfect the way he is 20:08:03 incremental improvement is fine 20:08:11 * fungi incrementally improves mordred 20:08:18 ooh. tingly! 20:08:38 yes, I agree with incremental changes, though I'd like to not have an update to this paragraph every week :-) 20:08:40 right, then, moving on to the next one 20:08:41 #topic We value clear, friendly and open communication 20:08:46 #link https://review.openstack.org/365590 20:08:56 this is flaper87's but since he's not here, I'll try to introduce it 20:09:10 This change is an updated version of the proposal adding “assume good faith” and focuses more on the reason and on the goal of clear communication than on trying to tell people what assumptions to make. 20:09:31 I think that makes it more of a principle and less of a CoC-esque instruction 20:10:00 comments? 20:10:31 I am good with it as-is 20:10:41 yeah, this version is great 20:10:43 same 20:10:50 I like what we are trying to say here, and this feels like a good way to say it 20:10:55 i.e. +1 20:11:12 I was going to say we might want to move it up earlier in the list, but johnthetubaguy's point about this ending on a positive note is good, too 20:11:25 Yeah, this is better written than the last iteration 20:11:32 yeah, i hadn't thought about that, but is a great point 20:11:34 It also more clearly communicates what I understood Flavio's point to be 20:11:42 I like that we say we value people who are not native english speakers 20:11:50 mordred : ++ 20:11:57 i like that we say we value people, period ;) 20:11:59 mordred: even frenchies? 20:12:00 fungi : ++ 20:12:07 EmilienM : especially! 20:12:08 mordred ++ 20:12:10 EmilienM: I didn't say _all_ non-native english speakers :) 20:12:12 lol 20:12:23 we should move on before EmilienM throws a baguette at mordred 20:12:25 next tc meeting is in french 20:12:26 * mordred eyes EmilienM and ttx with skeptical eyes 20:12:35 we were doing so well with the agreement... 20:12:39 heh 20:12:40 EmilienM: only if you can tolerate my terrible Google Translations ;) 20:12:46 heh 20:12:51 sigmavirus: welcome to my life 20:12:55 alright, le moving on 20:12:58 #topic Update Python CTI for 3.5 20:13:04 #link https://review.openstack.org/397501 20:13:09 fungi, do you want to introduce this one? 20:13:15 sure 20:13:41 in short, with the move to ubuntu xenial for stable/newton and later, we no longer have python 3.4 available on our worker images 20:13:46 3.5 is what comes standard 20:14:02 so this is just a simple patch to update the ctg to that effect 20:14:30 that all seems very straightforward, and it's a good idea for our policies to reflect our reality 20:14:36 we could, alternatively, not specify a specific py3k version, to avoid future churn 20:14:54 but this was the more trivial option 20:14:55 I get the question quite a lot, so I like writing it down, but it doesn't have to be here 20:14:58 every 2 years isn't too much load 20:15:11 fungi: can we just specify "latest version" or something more generic? 20:15:20 i'm open to that as well 20:15:29 EmilienM : 3.6 is due out soon (it's in beta now), but it won't be in distros for a bit 20:15:38 so I think being specific removes confusion 20:15:43 though that mighth confuse people into thinking they should be going out of their way to test 3.6 on ubuntu lts that lacks it, yeah 20:15:56 yeah, until it lands in ubuntu/redhat it might takes a while. So hardcoding it makes sense 20:16:05 ++ 20:16:06 as he requires manual verification to see if it's in distro 20:16:14 s/he/it/ 20:16:28 true 20:16:37 we're going to get to python 3.7 before 2.7 is fully dead aren't we? 20:16:46 that seems likely 20:16:52 * mordred hangs his head 20:17:05 anyway, the patch seems to have support, so i'm cool moving on unless there are any questions 20:17:05 * dhellmann makes a note to update the python 3 goal for pike 20:17:12 I agree 20:17:14 #topic Acknowledge nominal prerequisites for tests 20:17:14 #link https://review.openstack.org/397502 20:17:15 fungi, this one is yours, too 20:17:40 this one's a little less straightforward 20:17:57 it came up when i was helping work through some swift testing needs 20:18:13 apparently their extended attribute support depends on using xfs 20:18:30 and to avoid lots of mocking out the fs, they want to have an xfs partition available when running unit tests 20:18:56 that seems reasonable -- I'd expect them to need it for functional tests anyway 20:19:05 in reflection, we already make similar concessions for projects needing, e.g., particular databases preconfigured 20:19:17 to run unit testing 20:19:45 seems fair to be pragmatic about that kind of thing 20:20:01 yes, I don't see any real issue with this 20:20:04 so in an effort to stem future questions about non-straightforward unit test prerequisites, i thought it would be a good idea to acknowledge them in the ctg and advise that they be clearly documented 20:20:07 being flexible is good 20:20:46 I like the clearly documented part, seems a good prompt to do the right thing 20:20:49 the documentation requirement is a good idea 20:21:02 we (infra0 have some ideas as to how to make these similar for teams to document and integrate with our test infrastructure in a more consistent manner in the future, but i'll let the people working on that plan introduce it on the ml once they're ready 20:21:24 er, s/similar/easier./ 20:21:50 I think I saw a post from ajaeger about a setup script that some jobs would look for 20:21:52 it'l be compatible with this phrasing in the ctg at a minimum, anyway 20:22:09 good call 20:22:11 yeah, that's what i was referring to, so i guess he's sent that in the past few minutes 20:22:39 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107784.html 20:22:46 any questions about this, or shall we move on? 20:22:56 we've done similar things to simplify system package setup for tests in a way that's consistent between developer experience and ci system, so that's the goal 20:23:07 ++ 20:23:13 and yeah, nothing else from me on this 20:23:40 the next topic may involve a bit more discussion, so let's move on and we can come back if there are questions 20:23:46 #topic Review of Ocata goal acknowledgements 20:23:46 (a bit of an info dump coming) 20:23:52 Part of the goal process is for us to look through the acknowledgement responses. 20:23:52 The deadline set was the first milestone, which was last week. 20:24:00 Responses that have been reviewed and approved are on the goal document: 20:24:00 #link http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html 20:24:08 There are still some waiting to merge under the house rules: 20:24:09 #link https://review.openstack.org/#/q/project:openstack/governance+topic:+goal-remove-incubated-oslo-code+is:open 20:24:11 #link note from Andreas - http://markmail.org/message/akl7bkq2xuyr33dw 20:24:15 And we have some projects that have not yet acknowledged the goal 20:24:27 #info 17 of 57 teams have not yet acknowledged the community goal 20:24:27 #info those teams are Community App Catalog, I18n, OpenStack Charms, OpenStack UX, OpenStackSalt, 20:24:27 #info Packaging-deb, Packaging-rpm, Quality Assurance, RefStack, Stable Branch Maintenance, 20:24:27 #info dragonflow, fuel, karbor, kuryr, magnum, tacker, watcher 20:24:39 The overall response rate is a little disappointing, but some of the projects on this list aren’t surprising since several are much less active this cycle than in the past. 20:24:48 #info 17 projects had work to do to complete the goal 20:24:48 #info 1 team with work to do (as listed in the goal) has not yet responded: karbor (formerly smaug) 20:24:59 That response rate is better, but I’d like to get to 100%. 20:24:59 I have contacted the PTLs of all teams who did not respond to prompt them to do so. 20:25:05 Does anyone have any comments on the process or our status so far? 20:25:37 dhellmann : how many teams had not responded? 20:25:47 dhellmann: so - some of tehose projects are ones that removing oslo incubator code doesn't make sense for 20:25:54 17 did not respond, but only 1 of those had work to do 20:25:58 yah 20:26:10 mordred : yes, that's true. However, the process is that all teams acknowledge all goals. 20:26:14 totally 20:26:18 because this is about communication 20:26:22 right 20:26:23 wanted to personally thank dhellmann for proposing the patches to fix this in storyboard and python-storyboardclient (infra's only matches). 3 of 4 changes for that have merged now, the last one just needs some reviewing 20:27:06 fungi : I'm glad to help. I know the storyboard team is stretched thin with other work, and that provided a good example patch for some other projects. 20:27:52 dhellmann: i'll try mentioning above to karbor/dragonflow/kuryr. hopefully they look at internal mail more frequently. 20:27:57 I should thank those of you who have helped review the acknowledgements, too. Esp. stevemar 20:28:25 gordc : thanks, that would help. Yesterday I emailed all of the PTLs for the projects that haven't responded. 20:28:27 one case for the current process where all teams need to ack a goal is that it's always _possible_ something got overlooked in assessing whether they are or aren't impacted 20:28:48 so it gives them the ability to confirm/deny 20:28:48 fungi : exactly. I don't want the TC to make assumptions about impact on teams one way or another. 20:29:34 the next step in the process is for teams to do the work to meet the goal. Quite a few are done already, or have patches in progress. 20:29:37 i can even see it not being within the tc's direct purview to put together lists of who's impacted (though perhaps it falls under expectations for whoever proposes the goal) 20:30:16 yeah, when the goals were originally proposed one piece of feedback was that we should try to provide *some* insight into expected impact 20:30:34 for this goal I included a list of the official repos that had incubated code remaining 20:31:04 for python 3, haypo has done a lot of good analysis so the document summarizes that and refers to the wiki page for more detail 20:31:54 if there are no other comments or questions, I think we can call the review done 20:32:21 I am happy its causing the right discussions to happen 20:32:21 I would appreciate some help tracking down the PTLs for teams who haven't responded, yet, so if you have some time to assist please let me know 20:32:32 johnthetubaguy : ++ 20:32:37 dhellmann: I can take magnum as a start 20:32:43 johnthetubaguy : thanks 20:33:07 dhellmann: I just posted https://review.openstack.org/400954 for the UX team 20:33:11 dtroyer : thanks 20:33:16 i'll get up with Community App Catalog 20:33:39 fungi : thanks 20:34:23 dhellmann: i'll take some time too 20:34:47 EmilienM : great, thanks, just pick from the list and let me know 20:34:52 dhellmann: get in touch with PTLs who haven't responded yet 20:35:41 some of the teams look fairly inactive, so we may want to review those project teams in a more general way 20:35:46 but that can wait 20:35:51 * johnthetubaguy nods 20:36:02 alright, let's talk about Octavia then 20:36:03 #topic Add project Octavia to OpenStack big-tent (initial discussion) 20:36:38 #link https://review.openstack.org/313056 20:36:39 last week we approved the change to move several neutron projects to the legacy list 20:36:40 #link https://review.openstack.org/#/c/392010 20:36:41 this new patch moves some of the lbaas repositories to a new team, which is already maintaining the Octavia project 20:36:42 following our usual practice, we’ll spend more than one meeting discussing adding a new team referring to the list of requirements 20:36:43 #link http://governance.openstack.org/reference/new-projects-requirements.html 20:36:45 dougwig, are you here today? 20:37:05 * dhellmann should have pinged him before the meeting 20:37:08 I am here 20:37:24 ah, johnsom, great 20:37:25 On pto, but my phone just buzzed. :) 20:37:50 dougwig : I think we have it covered, go back to PTO :-) 20:37:57 johnsom: maybe you can start the discussion by introducing the scope of Octavia, how it relates to Neutron, and giving a little of the background behind this change? 20:38:02 Sweet 20:38:43 Sure, currently Octavia is an open source reference driver for neutron-lbaas. 20:39:21 It was build with the expectation that we could dis-entangle the neutron-lbaas code from neutron proper and accomplish our goals via the API. 20:39:37 that's a separate API from neutron's? 20:39:39 We started discussions about this at the Paris summit. 20:40:02 Core teams between neutron-lbaas and Octavia are the same, and do not overlap neutron except myself and armax. 20:40:37 Today Octavia has it's own API process, but it is consumed by neutron-lbaas. We are currently working to move the API component of neutron-lbaas out of neutron and implementing it in the Octavia API process. 20:40:47 the specs linked from this patch have some implementation details 20:40:49 #link https://review.openstack.org/#/c/310805/3/specs/newton/kill-neutron-lbaas.rst 20:40:55 #link https://review.openstack.org/#/c/310667/3/specs/version1/n-lbaas-api-parity.rst 20:41:02 Octavia is a separate API server, and closely mimics neutron lbaas v2. Part of this split is making them exact, and including a proxy in neutronnso users are not affected. 20:41:13 This "lbaas-merge" work started in newton 20:41:24 johnsom: how backward compatibility will be ensured between neutron & octavia if you move it out? 20:41:53 dougwig : how long do you anticipate maintaining that proxy? a standard deprecation period, or longer? 20:42:04 API tests still run against neutron server, will also run against Octavia and the future proxy. 20:42:16 EmilienM via the proxy that will remain in neutron for some time. Our plan is to allow a simple endpoint change and the API will be the same. 20:42:27 to me, it seems Octavia have basically been operating as a separate (but co-operating) team for a bit now, it seems right to update the projects file to reflect that 20:42:31 johnsom: excellent from operator point of view, ++ 20:42:34 My intention was to maintain it longer than 2 cycles if it's not a maintenance burden. 20:42:39 johnthetubaguy : that's the impression I'm getting, too 20:42:42 * fungi notes dougwig is setting a bad example for how to do pto 20:42:55 I've always been bad at pto 20:43:12 johnthetubaguy: correct. 20:43:50 johnthetubaguy: +1 20:44:05 as a release manager, I’m a little concerned about the timing, since we’re past the first milestone for this cycle. Though Octavia uses the cycle-with-intermediary model so it isn’t technically “late” for any releases. 20:44:59 I also don't think that's a reason to hold up progress 20:46:15 reviewing the list of criteria for new projects, I'm not spotting any obvious issues with how Octavia is developed or being integrated 20:46:31 does anyone have any concerns to raise this week, assuming we'll have another discussion about this application next week? 20:46:55 johnsom : does Octavia need to remove any incubated oslo code? 20:47:08 No, we have completed that 20:47:11 ok, good 20:47:33 I guess that is technically already reported in the neutron report? 20:47:35 We didn't push a patch because currently we fall under neutron. 20:47:47 What is Octavia's py3 status? 20:47:50 ah, right 20:47:53 dtroyer : good question 20:48:08 dtroyer we support 3.4 and 3.5 with gates 20:48:16 good answer :-) 20:48:28 thanks 20:48:39 We try to "do the right thing"... grin 20:48:58 johnsom dougwig : any trademark concerns? (would octavia have to be renamed?) 20:49:14 s/would/that would/ 20:49:18 No, Stephen trademarked Octavia for openstack 20:49:29 cool thanks dougwig 20:49:31 There is a trademark already and I was told it was already transferred to the foundation 20:49:36 i see you have two repos under neutron's octavia deliverable right now, but would be splitting them into separate deliverables under the new team. any concerns there? 20:50:17 is that the dashboard split out bit? 20:50:24 johnsom: I remember octavia had a specific parameter for oslo_messaging/topic (not part of oslo_messaging iiuc). Is it still the case? 20:50:38 Currently there are three repositories: neutron-lbaas, octavia, and neutron-lbaas-dashboard. 20:50:46 yeah, it looks like one repo per deliverable now. From the release team's perspective I think that's fine. If we run into issues with our release tooling, we can work through it. 20:50:49 the tags seem to have conveyed consistently in the split of openstack/octavia and openstack/neutron-lbaas-dashboard into separate deliverables, yeah 20:51:00 johnsom: random question, because I tested octavia, with the puppet-octavia module we wrote a few months ago :) 20:52:01 EmilienM Yes, there is a messaging topic used inside Octavia via oslo messaging. 20:52:21 It is used between our API process and the controller-worker process 20:52:31 oh, though i notice the openstack/neutron-lbaas-dashboard repo belongs to a octavia-dashboard deliverable now. is there an expectation that the repo will get renamed to that in the future? 20:53:17 seeing all these questions...they don't feel like show stoppers :) so johnsom and dougwig have my support for doing this 20:53:19 Yes, I think to limit future confusion we will want to rename away from "neutron" 20:53:22 fungi : good question. I think we can change the deliverable name in the repo without renaming the repo, right? 20:53:29 dims: +1 20:53:35 that would give us time to schedule a repo rename when it's convenient 20:53:41 Rename would be cleaner, but we are open. 20:53:42 dims : +1 20:53:58 dougwig : oh, a rename is fine, it's just a matter of not holding up releases or other work until that's done 20:54:04 dims: same thing. +1 to have it in the big tent 20:54:18 Not urgent for pacts, I'd think 20:54:36 yeah, the deliverable name is arbitrary, i was mostly just curious if there was a repo rename in the future 20:54:37 Ocata. Autocorrect. 20:54:50 fungi: likely yes. 20:54:52 * dhellmann was wondering 20:55:17 alright, as I said, I expect ttx to put this on the agenda again for next week for final discussion and voting 20:55:20 * mordred thinks pacts is now the secret codename for ocata 20:55:41 so far I'm not seeing any real issues, but we're not running with the full tc for this meeting so keep an eye on review comments 20:55:49 and we have a few minutes left for 20:55:50 #topic Open discussion 20:56:29 I'd like to say thanks to the octavia team for sticking with it through _several_ organizational approach shifts 20:56:44 that's some good patience 20:56:51 agreed 20:56:56 * johnthetubaguy nods 20:57:02 We'll be rewriting in go soon. 20:57:08 thank god 20:57:09 * dougwig hides 20:57:12 dougwig: heh 20:57:16 * fungi wondered when that was coming ;) 20:57:20 I was worried it was going to be too easy for you 20:57:36 * johnsom notes that dougwig does not speak for the whole Octavia team. 20:57:39 dougwig : comments like that are why we have 2 discussions for most of these applications ;-) 20:57:42 heh 20:57:56 lol 20:57:59 johnsom: oh, traitor ! 20:58:37 Jk, of course. 20:58:41 with that I think we're finished for today 20:58:45 thank you, everyone! 20:58:58 nice work dhellmann ! 20:59:00 thanks 20:59:06 dhellmann: thx for chairing today, next time in french like we said 20:59:13 EmilienM : ++ 20:59:18 thanks dhellmann! 20:59:24 Merci 20:59:47 dougwig: enjoy vacations now! 20:59:52 merci buckets 21:00:03 #endmeeting