21:00:13 #startmeeting networking 21:00:15 Meeting started Mon Sep 14 21:00:13 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:19 The meeting name has been set to 'networking' 21:00:29 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:00:29 hello 21:00:37 We've got a mostly liberty-rc1 focused agenda for today, so lets get started! 21:00:38 hi 21:00:42 #topic Announcements 21:00:45 yello 21:00:49 hi 21:00:51 Hi 21:00:51 #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Liberty_Release_Notes Liberty Release Notes 21:00:52 o/ 21:00:56 hi 21:01:00 o/ 21:01:00 #info Please continue adding high quality release notes to the release notes page 21:01:04 o/ 21:01:06 o/ 21:01:10 My thanks to those of you who have already plastered stuff on that page! Way to go! 21:01:12 o/ 21:01:17 Hi 21:01:36 #info The Tempest plugin interface is now ready! 21:01:43 mestery: is there a plan to move release notes into openstack-manuals? 21:01:45 #link https://review.openstack.org/#/c/201955/ An example change using this 21:01:46 Hi 21:01:59 #link http://docs.openstack.org/developer/tempest/plugin.html Documentation for Tempest plugin 21:02:06 emagana: I don't think so, those stay on the wiki page per past releases 21:02:22 mestery: should we move them? 21:02:28 hi :) 21:02:31 mestery: correction.. copy them 21:02:50 emagana: Copying them is fine, but I'd wait a bit, we still have more to add 21:02:59 mestery: roger that! 21:03:00 #link https://wiki.openstack.org/wiki/PTL_Elections_September_2015 PTL Elections have begun! 21:03:09 #info I encourage anyone interested in running for Neutron PTL to throw their hat into the ring! 21:03:19 We have a deep bench of leadership 21:03:29 The next PTL is gonna be awesome :) 21:03:39 Any other announcements for the team? 21:03:40 mestery: i was confused about your candidacy email. it made it sound like you weren't going to run 21:03:48 kevinbenton: lol 21:03:49 kevinbenton: lol 21:03:50 kevinbenton lol 21:03:54 haha 21:04:03 * Sukhdev salutes to outgoing PTL for awesome job he has done 21:04:12 Also note: You can nominate someone else, that person has to +1 the nomination 21:04:19 mestery: thanks for everything, mestery! You've left the project in great shape 21:04:21 Sukhdev: thanks :) 21:04:28 yes, you have 21:04:35 russellb: +1 21:04:36 hear hear 21:04:41 russellb: I'm just doing the final walkthrough before turning the keys over :) 21:04:44 kevinbenton: I think there is a bylaw for which if nobody runs the old PTL stays in charge indefinetely until one is found 21:04:46 yes indeed! thanks Kyle, Neutron community is so much better now 21:05:01 salv-orl_: Wait, no one told me that! 21:05:04 salv-orl_: lol :) 21:05:04 moo. 21:05:13 Any other announcements for the team? 21:05:22 in all seriousness, if nobody runs, it falls to the TC to find and designate someone 21:05:30 not that i expect that to happen here ... 21:05:36 i think people are just holding off to build up suspense 21:05:38 :) 21:05:42 looks like mike perez is freeing himself up :) 21:05:59 :) 21:06:02 #link http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst 21:06:09 ;) 21:06:14 russellb: As the outgoing PTL, I'd be happy to provide a list of names to the TC should that happen :) 21:06:17 Thanks carl_baldwin 21:06:24 mestery: carl first? 21:06:38 mestery: the appointee has to agree though :( 21:06:40 Sam-I-Am: Please, nominate carl_baldwin! Anyone can nominate anyone else 21:06:46 russellb: That's no fun :( 21:06:47 Sam-I-Am: ++ 21:06:56 mestery: he's sitting next to me 21:06:59 i'm waiting to get punched 21:07:02 Sam-I-Am: lol 21:07:05 there 21:07:18 Sam-I-Am :-) 21:07:21 Seriously folks, we have many great leaders in our community! I know we'll support whoever becomes the next PTL and Neutron will continue to rock! 21:07:23 OK 21:07:31 Lets move along now :) 21:07:36 #topic Bugs 21:07:39 I know ... BUGS :( 21:07:46 damn bugs :) 21:07:48 First up 21:07:50 #link https://bugs.launchpad.net/neutron/+bug/1484148 21:07:51 Launchpad bug 1484148 in neutron "neutronclient gate broken following VPNaaS infra changes" [Critical,Confirmed] - Assigned to Paul Michali (pcm) 21:07:58 bugs: the life of this community 21:08:00 pc_m: Looks like this one is under control? 21:08:04 armax: lifeblood! 21:08:12 mestery: yes. Just need reviews. 21:08:24 pc_m: I voted positively on your infra review 21:08:29 Looks like you need that one first 21:08:36 Doesn't need to be critical, as there is a workaround (disabled tests) 21:08:48 pc_m: OK, bumping down! :) 21:08:48 mestery: yes. thanks 21:09:05 Next up 21:09:06 #link https://bugs.launchpad.net/neutron/+bug/1477192 21:09:08 Launchpad bug 1477192 in neutron "neutron test_multi_prefix_slaac failing in the gate with ping failures starting around 7/22" [High,Confirmed] - Assigned to Henry Gessau (gessau) 21:09:20 I took an initiall look 21:09:21 HenryG: Thanks for correcting me on there :) 21:09:30 HenryG: I don't know if this one deservers to be high based on your input. Thoughts? 21:09:31 It's not as bad as the query lets on 21:09:34 Right 21:09:37 Maybe it's medium? 21:09:43 probably 21:09:48 Sold! 21:09:58 But there is a problem in there somewhere, that needs looking at 21:09:59 HenryG: Thanks! 21:10:00 Moving on 21:10:13 * mestery nods 21:10:15 #link https://bugs.launchpad.net/neutron/+bug/1439696 21:10:16 Launchpad bug 1439696 in neutron "Referencing a lb-healthmonitor ID for the first time from Heat would fail" [High,Confirmed] - Assigned to Doug Wiegley (dougwig) 21:10:32 dougwig: I'm not sure this deserves to be high, do you agree? 21:10:37 dougwig: It's been sitting here for a while now 21:10:46 Medium 21:10:59 xgerman: Sold! 21:11:06 doug says it doesnt need t be high 21:11:07 dougwig is predisposed at the QA midcycle now, so lets move along 21:11:08 he's standing here 21:11:10 Sam-I-Am: Thanks! 21:11:16 should be joining shortly 21:11:23 Sam-I-Am: Tell him he's up for this one too 21:11:29 #link https://bugs.launchpad.net/neutron/+bug/1163569 21:11:30 Launchpad bug 1163569 in neutron "security groups don't work with vip and ovs plugin" [High,Confirmed] - Assigned to Doug Wiegley (dougwig) 21:11:39 This one has a security note attached which lifeless was curious to have someone from Neutron look at. 21:11:46 Hoping dougwig can verify this yet 21:11:48 that bug is older than i am 21:11:53 lol 21:11:57 sc68cal ? 21:11:57 i don't understand how it's been sitting there that long 21:12:00 kevinbenton: To be fair, you're like 14, right? 21:12:07 hmm? 21:12:14 we havent looked yet. bad devs, no biscuit. 21:12:29 sc68cal SH is our wheelouse 21:12:32 dougwig: Can you eyeball this one closer this week yet when you get a moment? 21:12:33 SG 21:12:46 xgerman: Yes, sc68cal looking would be great too 21:12:48 sc68cal: https://bugs.launchpad.net/neutron/+bug/1163569 21:12:49 Launchpad bug 1163569 in neutron "security groups don't work with vip and ovs plugin" [High,Confirmed] - Assigned to Doug Wiegley (dougwig) 21:12:57 mestery: yes, hopefully i can delegate that eyeball, but yes. 21:13:02 * sc68cal adds to his trello 21:13:18 :) 21:13:20 OK, moving on 21:13:28 #link https://bugs.launchpad.net/neutron/+bug/1491131 21:13:30 Launchpad bug 1491131 in neutron kilo "Ipset race condition" [High,New] 21:13:33 This one was reported by an actual operator! 21:13:44 we have those? 21:13:45 Looks like ZZelle__ assigned it to himself 21:14:11 mestery, yes, that's my tomorrow job 21:14:12 yikes, I forgot to follow up 21:14:23 I see shihanzhang came with a few patches that can be backported to kilo 21:14:23 ajo: :) 21:14:29 ajo: Excellent! 21:14:36 ajo: Can you propose those ones if they aren't already proposed? 21:14:46 I didn't see ocurrences of what the operator saw in logstash 21:14:53 but that doesn't mean it's not in kilo 21:15:08 mestery: I will 21:15:22 ajo: AWesome sir, thanks :) 21:15:35 Does anyone have any bugs for the team to talk about this week? 21:15:42 mestery: well 21:15:54 we should inform the group that DVR job went back to non-voting 21:15:59 * mestery straps in for the armax bug assault 21:16:01 Swami: ^^ 21:16:08 #info the DVR job is non-voting again :( 21:16:13 armax: tl;dr for the team? 21:16:15 there's an email going around 21:16:17 sc68cal: ^ 21:16:33 carl_baldwin, dougwig, sc68cal and ryan would tell you more 21:16:33 yep, sent it about 30 mins ago for people to review 21:16:38 #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074433.html 21:16:41 sc68cal: ^^^ 21:16:41 they were the ones charging the coup 21:16:54 off with its head. 21:17:00 is this all dvr jobs or just dvr-multi? 21:17:03 armax: hi 21:17:28 more seriously, we have some work to do, as a team, to make sure our jobs are stable. and since dvr has merged, it is our responsibility. if we don't want that, it needs to be out. 21:17:29 #info VPN functional tests for Neutron commits is upstreamed as experimental job 21:17:42 dougwig: Spoken like a true PTL! :) 21:17:45 I'm cleaning up the QoS house with this: https://launchpad.net/bugs/1486039, but you will see me pushing for a refactor just in front, to avoid fixing the same thing twice in different qos drivers.. 21:17:46 Launchpad bug 1486039 in neutron "Setting a policy to a network will limit the router/dhcp/net-device ports, that's not expected" [High,In progress] - Assigned to Miguel Angel Ajo (mangelajo) 21:17:59 ajo: Ack 21:18:09 I know is a bit late in the cycle to be doing refactors, but I guess QoS is experimental, and not a bad thing to cleanup asap 21:18:29 ajo: +1000.5 21:18:31 Any other bugs for the team? 21:18:41 armax: You have another few up your sleeve today? 21:18:44 Do we need such feature in Liberty? https://review.openstack.org/#/c/221508 21:18:48 dougwig: yes, that applies to any job, dvr, functional, api, etc 21:18:50 nice to see a lot of linuxbridge stuff has been addressed 21:18:59 mestery: no I am good 21:19:01 i'm currently reworking the install guide to use it 21:19:03 armax: ack 21:19:09 I did my bug scrub during the past few days 21:19:27 ZZelle__: I'm on the fence there, lets iterate on the review for that one 21:19:31 I am content 21:19:33 armax: That's because you're awesome. 21:19:35 ZZelle__, what's the thing, which bridges don't we clean now? 21:19:36 Sam-I-Am: LB with provider networks? 21:19:41 (the install guide i mean) 21:19:58 mestery, ok 21:20:04 russellb: yes, and augmenting that arch to do l3 things 21:20:12 Sam-I-Am: cool 21:20:22 OK, lets slide along into the next section .. 21:20:23 will talk about it more in a bit here 21:20:23 #topic Docs 21:20:29 emagana: hi there! 21:20:31 Sam-I-Am: Also, hi there 21:20:34 mestery: Hi! 21:20:36 yeah... like here :) 21:20:43 Sam-I-Am: You see what I did there? 21:20:56 All the open reviews for IPv6 have been completed. Thanks! 21:20:56 yep 21:21:04 yaaaaaay 21:21:06 ajo, see https://bugs.launchpad.net/neutron/+bug/1328546 21:21:07 Launchpad bug 1328546 in neutron "Race condition when hard rebooting instance" [High,Fix released] - Assigned to Li Ma (nick-ma-z) 21:21:08 whats ipv6? 21:21:25 Working on the sub-chapter for QoS hoping to get a lot of help from ajo 21:21:39 yes emagana , thanks, that will help a lot, 21:21:44 docs are good 21:21:46 awesome! Thanks emagana and ajo! 21:21:53 emagana, just fighting the last life of qos bugs to jump into it, 21:22:05 ajo: I will get more staff between today and tomorrow.. wait for my next patch 21:22:15 emagana+++++++++ 21:22:41 mestery: I will review the release notes and make sure we have some coverage in the networking guide 21:23:03 Sam-I-Am and sc68cal Do you guys want to add something? 21:23:03 emagana: Awesome! In particular, RBAC networks, QoS and pluggable IPAM are probably worthy of documentation notes 21:23:09 emagana: yeah 21:23:11 carl_baldwin kevinbenton ajo: ^^^ 21:23:21 Sam-I-Am: go for it! 21:23:23 +1 :) 21:23:25 i'm working on the installation guide changes to make linuxbridge go in liberty 21:23:29 #link https://review.openstack.org/#/c/221560/ 21:23:39 Sam-I-Am: nice nice nice! 21:23:43 advanced services need docs in the networking guide 21:23:46 here's the plan... 21:23:49 *cough* fwaas ;) 21:24:00 sc68cal: I'm going to add a release note there 21:24:05 e\\\yep 21:24:08 there's only one architecture... two nodes, two network interfaces per node 21:24:09 indicating we're rebooting it and will remove the existing API in Mitaka 21:24:12 That sound right? 21:24:15 xgerman sc68cal : ^^^^ 21:24:19 yes 21:24:20 this way no one has to choose a particular arch based on hardware limitations 21:24:21 cool 21:24:40 we start people out with provider networks, then optionally let them add L3 support 21:24:54 if they have L3 support, they can use both provider and project networks 21:25:28 this also solves the common gripe of 'why cant i launch a vm on the ext/public net' when they used the neutron arch 21:25:42 now it supports both... with less hardware 21:26:14 i've tested the new arch and it works 21:26:14 cool :) 21:26:27 hopefully we can get the patches written and merged in a couple of weeks 21:26:39 Sam-I-Am: i'm not following 21:26:47 kevinbenton: que? 21:26:51 Sam-I-Am: what patches? neutron should have supported this for a long time 21:27:05 kevinbenton: docs patches 21:27:08 upstream install guide 21:27:13 neutron is fine :) 21:27:18 Sam-I-Am: oh, i see 21:27:19 * mestery quotes Sam-I-Am 21:27:24 haha 21:27:28 :) lol 21:27:33 * for various kinds of neutron 21:28:04 we will point users of the install guide to the networking guide for more details 21:28:09 Sam-I-Am: ++ 21:28:10 rather, more production-worthy archs 21:28:15 now that we have it 21:28:49 Sam-I-Am: That's a good goal, thanks for that! 21:28:59 Looks like lots of awesome work going on the docs area. Thanks emagana and Sam-I-Am! 21:29:06 +++ 21:29:08 * russellb is very thankful for folks working on docs :) 21:29:17 russellb: +1000.5 21:29:21 sure thing 21:29:26 getting there... 21:29:29 :) 21:29:35 nothing else from me!! 21:29:36 OK, lets move along to the meat of the meeting. 21:29:45 #topic Liberty-RC1 21:29:51 #link https://launchpad.net/neutron/+milestone/liberty-rc1 21:30:01 Lets see where we're at 21:30:15 BPs: 5 down, 7 to go 21:30:21 #info Blueprints: 5 down, 7 to go 21:30:22 Not bad 21:30:29 First up 21:30:29 #link https://blueprints.launchpad.net/neutron/+spec/lbaas-ref-octavia 21:30:35 xgerman: This is on track yet for this week? 21:30:40 YES 21:30:40 https://review.openstack.org/#/c/223265/1 21:30:41 octavia as ref is done, just needs to be enabled in our devstack plugin. 21:30:44 AWESOME! 21:30:45 one patch missing, some bugs 21:30:46 MOAR LBAAS! 21:30:59 That was easy. Thanks dougwig and xgerman 21:31:00 yep 21:31:01 Next up 21:31:02 #link https://blueprints.launchpad.net/neutron/+spec/wsgi-pecan-switch 21:31:04 all props to the octavia folks. 21:31:06 kevinbenton: MOAR PECAN! 21:31:13 +++++ 21:31:24 patch for bulk up late tonight/early tomorrow 21:31:26 then merge 21:31:30 I think this one can land this week once kevinbenton completes MOAR BULK support 21:31:33 kevinbenton: Thank you! 21:31:45 Next up 21:31:47 #link https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution 21:31:53 mlavalle: This one needs a respin and then maybe it's good? 21:31:59 I know carl_baldwin has been following it very closely 21:32:20 * carl_baldwin needs to check up on it. 21:32:32 carl_baldwin: I think it's a small patch which mlavalle is addressing a few final nits 21:32:33 mestery: ok, will do 21:32:37 mlavalle: Awesome! 21:32:53 Our first possibly contentious BP 21:32:54 #link https://blueprints.launchpad.net/neutron/+spec/add-availability-zone 21:33:08 I had a pass 21:33:09 armax: Can you review again? 21:33:13 russellb armax: I know you two had looked at this one 21:33:14 hichihara: will do 21:33:14 Thanks armax! 21:33:18 armax: Early thoughts? 21:33:18 awesome 21:33:21 What shape is it in? 21:33:32 it needed some work when I looked at it 21:33:35 * russellb thought he might review at night last week, but never had the energy 21:33:39 i was traveling all week 21:33:41 amotoki also looked at it 21:33:43 no worries russellb 21:33:46 armax: Cool! 21:33:50 OK, lets leave it targeted at this point. 21:33:54 i did look today and it seemed like there was more coming? 21:34:01 We've still got another week until potential RCs are cut 21:34:03 we’ll look at it again…but I got nervous when I looked at it 21:34:04 mestery: I've also looked at it too 21:34:09 armax: ++ 21:34:16 Thanks markmcclain, looks like this one has plenty of coverage :) 21:34:20 Awesome! 21:34:22 how bad would it be if it missed? 21:34:22 1I will try to run a pass too 21:34:26 Thanks folks 21:34:28 MOAR AVAILABILTY ZONES! 21:34:33 * mestery notices the hogpile happening 21:34:35 :) 21:34:35 russellb: neutron would be cancelled 21:34:40 kevinbenton: oh ok 21:34:46 Please folks, save some energy for ... 21:34:48 #link https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms 21:34:53 VLAN aware VMs 21:34:59 That's right 21:35:12 mestery: can we revisit #link https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution? 21:35:16 just feels like the point where we look for things to say no to instead of doing anything risky this late 21:35:23 russellb: ++ 21:35:33 mlavalle: We can indeed! What is your case for that one? 21:35:40 mestery: doesn't vlan-aware VMs require a nova change? 21:35:43 russellb: ++ 21:35:45 avail zones is pretty invasive 21:35:56 so i'd be inclined to bump it ... and i apologize for not reviewing faster 21:35:59 kevinbenton: Yes, but even outside that, my gut says no at this point 21:36:03 russellb: ++ 21:36:08 mestery: functionality is veru advanced. Problem is the gate.... we need neutron with designate to be able to approve it 21:36:10 armax: Thoughts on bumping avail zones? 21:36:10 I've never been a great fan of that avail zones work 21:36:15 mlavalle: Yikes 21:36:18 mlavalle: This late in the cycle? 21:36:28 so yes, if my opinion is worth anything that's something I'd bump 21:36:29 it depends how the suggestions have been addressed 21:36:29 the case against avail zones is building ... 21:36:31 mestery: well if it needs nova changes then there is completely no point in merging 21:36:31 mestery: I am working with Kiall, the designate ptl to get that fixed 21:36:45 kevinbenton: Aye aye captain, it's out! 21:36:45 i don't think it needs nova changes 21:36:53 mestery: if work had been done not so invasively merging it now wouldn’t be a problem 21:36:54 but how far along is it? 21:36:58 actually ready? 21:37:02 need to see how the author addressed my comments 21:37:03 russellb: Patches were propsed 3 weeks ago ... 21:37:15 armax: Sounds like you're not in favor either 21:37:16 it doesn't need nova changes if you just create the ports in advance and pass the trunk port to nova (in theory) 21:37:20 but i haven't looked at hte latest code :) 21:37:23 :) 21:37:24 if it's not implemented that way, i'd -1 21:37:26 I haven’t looked the new patchsets 21:37:38 mestery: can I ping you Wednesday or Thursday to see how much progress we get this week? 21:37:38 ++ 21:37:39 but the entire code was proposed 21:37:46 mlavalle: Lets do it! I'll eave it there for now 21:37:48 *leave 21:37:56 mestery: :-) 21:37:56 my 2p is that they way they're built currently, they're not going to be useful for operators. 21:38:04 salv-orl_: vlan trunk ports? 21:38:15 https://review.openstack.org/#/q/topic:bp/vlan-aware-vms,n,z 21:38:17 sorry I was still talking about av zones 21:38:19 they are all set workflow -1 21:38:21 :) 21:38:23 did not noticed you moved one 21:38:26 on 21:38:30 russellb: That seals it then 21:38:34 yeah we're talking about 3 at once i think 21:38:47 #info VLAN aware VMs is out of Liberty 21:39:08 * salv-orl_ a wave rage awaits mestery 21:39:08 to be clear, i'm a fan of that feature though 21:39:18 just seems too late 21:39:29 russellb: yes 21:39:31 russellb: +1 21:39:43 russellb: Well, we have our first pririty for M 21:39:47 OK 21:39:50 priority* 21:39:53 we are always fun of features, it’s the code we’re not so fond of 21:39:53 emagana: that makes sense :) 21:39:59 On to avail zones now ... 21:40:00 That one also out? 21:40:02 armax: :) 21:40:04 Seemed like the team was headed that way 21:40:22 if it was just waiting on getting through the gate or something, that'd be one thing 21:40:27 I think delaying makes sense 21:40:30 as dougwig pointed out, the onus is on the team to bear the cost 21:40:32 Right 21:40:41 Exactly 21:40:43 armax: Words to live by 21:40:50 it's invasive, and it's RC1 time 21:40:53 i'd bump it 21:40:53 yes 21:40:56 I have that tatooed on my right arm 21:41:03 bump looks good for me 21:41:04 the whole phrase 21:41:10 armax: "i'd bump it"? 21:41:12 and again, i think the feature is OK ... but don't see a need to rush it 21:41:21 kevinbenton: yes, that one 21:41:35 It's out 21:41:45 Next up 21:41:46 #link https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp 21:41:50 I added this one back in today 21:41:59 Because it was approved and slipped the cracks 21:42:00 But the lone Neutron patch out for review 21:42:04 indicates it only partially implements 21:42:06 so .... 21:42:29 mestery: there’s no code posted for it 21:42:29 #link https://review.openstack.org/#/c/213586/ 21:42:31 afaik 21:42:35 armax: https://review.openstack.org/#/c/213586/ 21:42:43 oops 21:42:49 armax: And https://review.openstack.org/#/c/220804/ 21:42:50 :) 21:42:56 well…there’s no sane code posted for it 21:43:02 armax: Taht may be tru 21:43:03 partially-implements ? 21:43:03 *true 21:43:05 I know 21:43:09 russellb: My concern as well :( 21:43:09 I think we should talk more with the api-wg first 21:43:12 Thus my question in the review 21:43:16 HenryG: ++ 21:43:21 HenryG: We have salv-orl_ for that 21:43:23 is it missing the changes-since filter? 21:43:25 btw there’s work that kevinbenton is doing to make these sorts of additions easier 21:43:33 WAT 21:43:39 so I think it’s safe to say this should be deferred 21:43:40 that was a key part of that IIRC 21:43:45 kevinbenton: https://review.openstack.org/#/c/222079/ 21:43:47 armax: Awesome sir 21:43:52 * mestery moves it out 21:43:56 kevinbenton: ^ 21:44:02 russellb: indeed 21:44:04 i actually kind of hated these attributes in the nova API 21:44:21 but it was largely due to implementation details 21:44:24 anyway. 21:44:33 doesn't look complete 21:44:34 current impl is concerned to make timestamp work, which is ok 21:44:54 but does not worry about the overall openstack api consumer experience 21:44:56 yeah but their use case specifically was that + ability to do changes_since filtering 21:45:02 Our last one 21:45:05 #link https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework-templates 21:45:11 dougwig xgerman: Status update? 21:45:14 definetely not critcial feature, so I have all the time to bring that up with the rest of the api-wg 21:45:25 code is all submitted 21:45:30 https://www.irccloud.com/pastebin/yjizL2r9/ 21:45:35 salv-orl_: cool, definitely something worth trying to make sure is consistent where possible 21:45:52 AbtractFlavorFrameworkFactory 21:45:58 mestery: I see only one patch on the lp whiteboard and it;'s merged 21:46:19 salv-orl_: For which spec? 21:46:21 ah found th eother patch(es) 21:46:27 salv-orl_: got it 21:46:29 https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework-templates 21:46:29 port timestamp right? 21:46:32 Ah 21:46:33 OK 21:46:48 need to update the whiteboard then 21:46:54 kevinbenton: you go wash that dirty mouth out with soap, young man 21:46:59 #link https://www.irccloud.com/pastebin/yjizL2r9/ 21:47:04 lol 21:47:29 with the timstamp work deferred, i wonder if we should improve on it and just have a change log for resources 21:47:57 updated the whiteboard... 21:47:58 xgerman: other patches are in "work items". Topics do mot match that's why they are not in the wb 21:47:59 kevinbenton: Seems like a nice idea 21:48:16 kevinbenton: changelogs on busy DBs tend to grow huge tables 21:48:43 kevinbenton: if there is a use for it that's ok, otherwise let's not bother with stuff that can grow indefinetely in size. 21:48:44 kevinbenton: do you mean keeping a change log of what changed on every resource? 21:48:54 think about the changelog for the default external network 21:49:24 ajo: right 21:49:59 That was the last one 21:50:00 kevinbenton, I don't mean I'm against it, if there are interesting use cases, let's just consider the risks :) 21:50:00 We're down to 4 left 21:50:07 So I encourage folks to review code for those BPs this week 21:50:09 salv-orl_: well that wouldn't have many changes 21:50:17 anyway: flavor framework. The api change by itself is not disruptive, so it's ok. It might not be the best way of doing it, but since we don't know we shiuld just go ahead and experiment with it rather than bikeshedding 21:50:29 * mestery notes there are 2 items left on the agenda 21:50:35 salv-orl_: +1 21:50:40 kevinbenton: I know you would have said that. You want to carry me in a rabbit hole. I might say then floating IP 21:50:41 salv-orl_ +1 21:50:56 but then you would argue that the change log are in the port associated with it 21:51:04 salv-orl_: right :) 21:51:08 OK 21:51:10 moving along 21:51:13 o/ 21:51:16 :) 21:51:17 And this will be quick 21:51:20 kevinbenton: go for it then. It's awesome. 21:51:20 #topic Mitaka Design Summit 21:51:22 #link https://etherpad.openstack.org/p/neutron-mitaka-designsummit 21:51:25 mestery: we like quick 21:51:30 Please keep proposing fun ideas to discuss in Tokyo there 21:51:47 The next PTL will handle scheduling the sessions (yay!) :) 21:52:01 you’re ptl until the week of the 24th 21:52:05 get to work 21:52:12 armax: That long? 21:52:14 When must we do by? 21:52:16 yes 21:52:17 armax: +++ 21:52:26 leave a lasting legacy 21:52:28 hichihara: I can't speak for the next PTL, but if it was up to me, sooner is beter than later :) 21:52:33 and since you bailed the week of feature freeze 21:52:33 OK 21:52:37 rofl 21:52:41 Does anyone try to add structure or organisation to all those ideas? 21:52:42 that’s the least you could do for the next ptl 21:52:44 armax: Are you saying I owe the next PTL a week of time? 21:52:47 neiljerram_bb: Yes 21:52:49 the PTL does :) 21:52:49 lol 21:52:50 mestery: yes 21:52:59 In general, the PTL and drivers team schedules the summit sessions 21:53:09 And tries hard to make sure we address the less sexy ideas which are important for the community 21:53:19 We'll have a bunch of those as well 21:53:19 Lucky new PTL! 21:53:21 neiljerram_bb: anarchy and chaos are the main drivers for our team. Structure and organization are two unknown values to us ;) 21:53:39 can we have a "neutron users stories / priorities" session again? 21:53:43 where people show up and scream at the room? 21:53:49 russellb: YES! 21:53:52 Also, lightning talks again 21:53:56 screaming++ 21:53:59 Do people like those still? 21:53:59 Seemed like they did 21:54:00 salv - thx, will adjust my paradigms 21:54:01 because i loved that 21:54:10 :) 21:54:12 OK 21:54:14 Lets move along 21:54:16 Keep submitting 21:54:18 We'll keep reviewing 21:54:19 And planning 21:54:21 For screaming 21:54:22 MILLIONS OF DOLLARS! 21:54:29 rofl 21:54:31 kevinbenton: daring 21:54:34 sc68cal: +1operators meet-up and all we heard was crickets! 21:54:35 #topic DefCore Update 21:54:52 hogepodge: you're up! 21:54:59 5 minutes left even! 21:55:01 not so much a defcore thing, but on the openstack compatible logo 21:55:04 he's typing. 21:55:07 :) 21:55:08 dougwig: lol 21:55:14 hogepodge: you need a louder keyboard 21:55:23 emagana: that's good right? 21:55:29 we'd like to ask vendors to test their compatible products, based on how projects define that testing 21:55:48 sc68cal: indeed! 21:55:59 so, would reviving some third party ci in neutron be a thing that could happen in 2016? 21:56:37 Is that not already a thing? 21:56:45 hogepodge: It could, it needs a leader 21:56:46 It's a larger topic, but I wanted to throw it out there for a possible future agenda. 21:56:53 hogepodge: the 3rd party CIs never died. They just mind their own business 21:56:56 but they're there 21:57:10 hogepodge: In Vancouver the team determined 3rd party CI didn't have a ton of value, but perhaps that opinion has changed 21:57:12 they don't follow a uniform testing standard really, which is what this implies. 21:57:16 dougwig: Right 21:57:18 The problem with that 21:57:21 is someone has to enforce it 21:57:29 And that job of enforcing 21:57:30 sucks 21:57:31 REally bad 21:57:33 mestery: to be fair we said that reporting from 3rd party CI does not have value 21:57:36 So unless someone steps upo 21:57:36 yeah, it would need to be uniform. Similar to what cinder is doing. 21:57:42 and policing is a PITA 21:57:48 mestery: that's what I keep hearing. 21:57:49 i don't think it was that it didn't have value 21:57:51 Unless someone steps up to enforce it and run it 21:57:54 It's not gonna work 21:57:57 it was more thatn enforcing rules around it wasn't worth it 21:58:06 emagana and I tried and it was a full time job 21:58:06 but if you run a plugin or a driver, 3rd party CI is surely valuable for you 21:58:10 So not trying to scare folks 21:58:12 But being honest here 21:58:20 so can I have time next week to make rough outline and also gather info? (say from salv-orl_) 21:58:22 and that it was up to the driver maintainers to decide how valuable it was to them, for the quality they wanted to achieve 21:58:28 hogepodge: Yes 21:58:41 mestery: honesty is what I want. Scary or not. I prefer scary. 21:58:42 * salv-orl_ so scared now 21:58:45 :) 21:58:48 to sugarcoated 21:58:49 * mestery trembles 21:58:59 hogepodge: It's worth trying again 21:58:59 For sure 21:59:07 OK 21:59:09 Thanks hogepodge! 21:59:09 Thanks for letting me ci bomb your meeting. :-D 21:59:13 I look forawrd to move discussions here :) 21:59:19 o/ 21:59:29 OK, lets focus on Liberty-rc1 now! 21:59:32 Not much time left :) 21:59:34 bye 21:59:36 Thanks folks! 21:59:38 #endmeeting