21:00:31 #startmeeting networking 21:00:31 you choose which :) 21:00:33 Meeting started Mon Nov 23 21:00:31 2015 UTC and is due to finish in 60 minutes. The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:34 trying to keep myself awake 21:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:37 The meeting name has been set to 'networking' 21:00:38 hi 21:00:44 o/ 21:00:45 hi 21:00:49 hi 21:00:50 hi 21:00:58 o/ 21:01:16 #link https://wiki.openstack.org/wiki/Network/Meetings 21:01:18 hi 21:01:28 this may end up being a short meeting…but let’s see 21:01:30 o/ 21:01:50 o/ 21:02:10 armax: don't jinx it.... 21:02:10 no announcements/reminders on the agenda 21:02:13 armax: You just jinxed yourself 21:02:13 however 21:02:20 hi 21:02:30 there’s a couple of things worth announcing 21:02:41 * regXboi looks for the murphy lightning bolts to land... 21:03:03 tehre’s an ongoing conversation on how to deal with development vs release cycle 21:03:31 there are some big-tent/stadium initiatives that are trying to figure out what’s the best way to develop/release their code 21:03:52 http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html 21:03:55 hello all! 21:03:55 I am not sure of any outcome yet 21:04:06 Hi 21:04:26 amotoki: that was initiated by this one I believe 21:04:28 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079773.html 21:04:28 think I'm one of the guilty parties there 21:04:45 yes, right 21:05:02 either way, we’ll get to a resolution in the next few days and our release liasion, egregious mestery 21:05:09 will tell us what to do 21:05:21 certainly networking-infoblox has the same issue others have mentioned - we are coding now but the deliverables will be targeted at Liberty (though we can verify they will work with Mitaka too). Also, we delivered a minimally functional driver and cut a liberty/stable branch, but want to target our more functional version at liberty too 21:05:34 I will 21:05:42 That's what I do 21:06:17 * regXboi confirms the mestery is egregious :) 21:06:22 we’ll have to iterate a bit more on what it means to be part of the stadium 21:06:33 "The only thing constant in OpenStack is change." 21:06:41 and bikeshedding 21:06:44 and process :) 21:06:53 so that anyone has a clear idea on what are the benefits and the responsabilities 21:07:11 anyone? everyone? 21:07:44 anyone that cares to understand it :) 21:07:52 as of now please be patient and hold on the frustration :) 21:08:09 mestery: so long changes are for the better 21:08:16 mestery: then change is welcome 21:08:18 armax: We only know if they are after we've tested them 21:08:32 mestery: aye 21:08:51 we need to change everything to make sure things stay the same 21:08:52 anyone else has anything to announce? weddings, parties? 21:09:22 armax: only openstack or neutron wedding and parties here 21:09:25 Party at Armandos house 21:09:34 kevinbenton: on thursday, even? 21:09:44 kevinbenton: Is armax buying the drinks too? 21:09:45 armax: remind the team mitaka-1 is next week 21:09:48 big tent! 21:09:52 mlavalle: indeed 21:09:58 #topic blueprints 21:10:03 :( 21:10:26 #link https://blueprints.launchpad.net/neutron/+assignments 21:10:38 #undo 21:10:39 Removing item from minutes: 21:10:54 #link https://blueprints.launchpad.net/neutron/mitaka/+assignments 21:11:11 we have a couple of blueprints that have no assignee/approers 21:11:17 *approvers 21:11:25 in particular 21:11:36 #link https://blueprints.launchpad.net/neutron/+spec/add-tags-to-core-resources 21:11:43 anyone interested in taking it? 21:11:48 armax: that would be gal 21:11:55 garyk: as approver 21:12:03 that's an interesting one. does it depend on kevinbenton's attr table work though? 21:12:12 ihrachys: it does 21:12:25 kevinbenton’s change should be in the oven as we speak I think 21:12:35 i would be happy to sponsir that one as i think that it is super importnat 21:12:37 kevinbenton: unless something catastrophic happened 21:12:43 I could look at it since I looked at attrs these days already. 21:12:58 but I already have two (though mostly on hold/handled) 21:12:59 ihrachys: you got 2, gary got 0 21:13:07 did we decide to allow arbitrary vendor fuckage, err, i mean, tags? 21:13:07 garyk wins 21:13:10 :) 21:13:12 either way 21:13:15 i think that kevins lacks a lot of explanation and it may not cater for the tags 21:13:15 let’s pin this to gary 21:13:16 armax: 'xactly 21:13:25 ihrachys: but you’re more than welcome to eyeball it 21:13:30 dougwig: I hope not 21:13:57 then there’s regXboi’s instrumentation one 21:14:08 garyk: what is the issue? 21:14:10 armax: I will eyeroll it :) 21:14:24 kevinbenton: please see comments on the bug 21:14:24 mestery: +1 21:14:29 * regXboi want's to see ihrachys show an eyeroll on IRC 21:14:55 dougwig: the proposal is to add tags for API consumers, not for back-ends 21:15:10 amotoki: +1 21:15:25 anyone is interested in taking regXboi’s bp? 21:15:29 garyk amotoki: +1 21:15:36 armax: The instrumentation one? I could work with regXboi on that one. 21:15:38 then we need assignee and approver for the fwaas v2 21:15:53 that's me and xgearman? 21:15:58 Yep 21:16:10 mestery: you sure? 21:16:30 armax: I've got one, and between dougwig and HenryG, that one is under control 21:16:31 you already have neutron-lib one 21:16:35 amotoki, dougwig: indeed the idea is to not pass the tags down to the plugin. Of course, eventually someone will find this extremely unfair and then we'll allow that, but that's for another release ;) 21:16:38 Right, and it's going swimingly 21:16:48 is he? oh boy 21:16:51 is it 21:16:59 Yes 21:17:00 It is 21:17:01 Thank you :) 21:17:06 mestery: :) 21:17:15 sc68cal: ok, ack 21:17:18 i'd volunteer to be approver for fw v2, since sean and xgerman will be submitters? 21:17:22 salv-orlando: that's a fair concern :( 21:17:33 I also assigned get-me-network to HenryG 21:17:34 dougwig: awesome 21:17:45 russellb is neck deep with vlan-aware-vms 21:17:51 drowning 21:17:53 :-p 21:18:21 russellb: there are still bubbles at the surface, it can't be that bad :-P 21:18:25 sc68cal: who is going to do the bulk of the code for fwaas v2 you know? 21:18:27 I've looked at vlan-aware-vms today. It seems to me it mostly just a russellb vs armax thing now 21:18:38 * russellb hugs aranjan 21:18:40 Aish 21:18:41 err, sorry aranjan 21:18:44 * russellb hugs armax 21:18:53 last man standing wins 21:18:56 xgearman: uhhhh 21:18:58 :) 21:19:04 * armax hugs russellb 21:19:09 :) 21:19:24 sc68cal: ok 21:19:25 lots of love today 21:19:28 armax: we have not determined it yet. Aish is not primary assignee 21:19:28 vlnas are so 80's 21:19:39 vlans 21:19:41 garyk: they made a return with containers 21:19:43 Yep 21:19:59 the return of the mainframe :) 21:20:05 garyk: Hey! I resent that! 21:20:07 ;) 21:20:12 sc68cal: ah ok, I got it wrong…let’s take this offline 21:20:18 can we keep the cross talk to a minimum? 21:20:20 would you rather we go with mpls-aware-vms? 21:20:24 i could propose that instead 21:20:25 * regXboi hears faint strains of "the empire march" 21:20:31 russellb: ++ 21:20:41 yeah that works for me 21:20:44 * regXboi is so glad he isn't drinking anything - the computer would be drenched 21:20:46 russellb: why not sentient vms? 21:20:53 (vlan-aware-vms supports that as an additional segmentation_type actually :-) 21:20:54 russellb: mpls ? 21:21:04 manjeets: don't mind me 21:21:07 Token ring? 21:21:09 ok 21:21:10 there was a thread on review focus 21:21:18 and work being targeted for mitaka 21:21:32 rossella_s was working on a nice dashboard to keep us in check 21:21:36 how about slotted aloha? 21:21:50 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079816.html 21:21:56 armax yes! feedback is welcome :) 21:22:12 we seem to start getting lots of tools using launchpadlib lately 21:22:14 i see https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project at the bottom of the list. 21:22:37 is there a link for the dashboard? 21:22:48 rossella_s: I did provide some…btw if the assignee keeps the bp whiteboard current, then the approver should have an easy life to know what to review 21:22:57 do we have a plan to tackle this in mitaka? 21:23:00 armax: +100000 to that 21:23:18 i'd volunteer for the tenant one, but i think i'll have my hands full with neutron-lib. and i think that one is a sleeper. 21:23:23 amotoki: as of the keystone v3 one, there’s a bug assigned to mordred 21:23:41 that would make neutron work with v3 21:23:54 I initially thought that v2 was going away but then I found out that it’s no longer the case 21:23:59 russellb can vouch for that 21:24:01 I believe 21:24:26 armax: got it. thanks 21:24:36 armax: yeah. both v2 and v3 in keystone ought to be supported 21:24:37 having API consistency across the wider ecosystem is nice though 21:25:08 but I don’t see any volunteers stepping up 21:25:13 nice to knock that out earlier, rather than being a straggler (says the guy not volunteering for it) 21:25:34 even though from what I can see we should have fire power in order to handle it 21:25:48 I look here: 21:25:49 https://blueprints.launchpad.net/neutron/mitaka/+assignments 21:25:59 and I see lots of core dudes and gals missing 21:26:26 gals meaning ladies not gal sagie 21:26:29 I hope we don't need to call out names ;) 21:26:35 ihrachys: no need 21:26:43 ihrachys: names are right there for anyone to see :) 21:26:53 lol 21:26:57 or not 21:26:58 armax: no, those names are NOT there 21:27:08 ihrachys: right, same difference 21:27:19 and that's exactly the issue 21:27:38 ihrachys: well, call out names then ;) 21:27:50 Salvatore! 21:27:52 truth to be told the assignments do not capture the whole story 21:28:00 salv-orlando: I am still young to believe in humanity 21:28:07 armax: There are subtleties? 21:28:07 so let’s move on, I did say this meeting was indeed going to be short 21:28:13 armax: if no one wants to look at renaming tenant to projects, i can try to do this. 21:28:37 dasm: devising a plan to start with would be helpful 21:28:43 we don’t even have that at the moment 21:28:50 dasm: several of us want to, but are over-subscribed. i'd be happy to review. 21:28:50 +1 21:29:11 dasm is your LP handle? 21:29:17 smigiel-dariusz 21:29:42 dasm: thanks for taking it. my idea is that API accepts both (project/tenant_id). 21:29:57 i am sorry to push the process here but i think that we need a spec for the tenant-id <=> project 21:30:07 it’s right here: 21:30:08 it requires discussion and there are a lot of implications here 21:30:11 https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project 21:30:21 will it restricted to project only or both will be supported ? 21:30:36 that is just the BP and it does not really discuss things 21:30:40 I think this has been discussed for quite some time. The first time was back in Portland. 21:30:42 i think armax referred to needing a plan first. whether that's a spec, or devref, or ML thread, we can discuss there. 21:30:52 we’ll have to elaborate on the plan and a spec is most likely the place where the discussion will happen 21:30:58 but we never managed to put a plan together 21:31:33 salv-orlando: we never wanted to 21:31:45 armax: that is true as well. 21:31:51 armax: Someone's gotta actually sign up, propose a plan, and then do it. 21:31:51 salv-orlando: :) 21:32:12 and not mess up the delicate things like upgrade and db migrations. :) 21:32:16 mestery: I am mulling over some retaliation strategy :) 21:32:17 as you know this is a merge conflict train wreck. If it were me doing this, I would limit myself to the API level change 21:32:21 dougwig: Details, details 21:32:28 leaving 'tenant' in all internal data structures and in the db schema 21:32:50 * armax digresses 21:32:53 salv-orlando: +1 21:32:57 column rename will obliterate rolling upgrade, but that's a digression for another time. 21:33:08 but since it is not me doing this... meh! I'll just pick up a paintbrush and a random color ;) 21:33:16 lol 21:33:16 i like salv-orlando's idea as a first step. 21:33:18 it is also an expensive unneeded contract migration. 21:33:21 salv-orlando: xD 21:33:39 armax: I thought you said this meeting would be short? 21:33:42 just reading the blueprint now 21:33:48 (hey all) 21:33:48 mestery: it’s still 33 minutes pat 21:33:49 past 21:33:52 * mestery waves at mordred 21:33:52 mestery: he jinxed it 21:34:05 api only sounds good to me too 21:34:15 mordred: hi, I shamlessly pulled you in for bug 1503428 21:34:15 bug 1503428 in neutron "Support keystone V3 API" [Medium,Confirmed] https://launchpad.net/bugs/1503428 - Assigned to Monty Taylor (mordred) 21:34:16 I don't think updating the schema is particularly as useful as adding support for the word project to the API 21:34:25 armax: yup. ossum 21:34:26 mordred: +1 21:34:41 I'm guessing there are places in teh neutron api where tenant is used then? 21:34:52 mordred: yes there are 21:34:56 _awesome_ 21:35:43 let’s have dasm look into it 21:35:48 woot 21:35:55 * mordred hands dasm a nice ham 21:35:56 and we’ll discuss during next week’s meeting 21:36:09 agree 21:36:16 thanks dasm! 21:36:30 #topic Bugs!!! 21:36:51 garyk: it looks like it was a quite week? What’s your take? 21:36:56 * armax hands over the mic 21:37:03 ok, a few things: 21:37:11 last week the majority of bugs were lbaas 21:37:18 yay for lbaas! 21:37:22 this week they were access-control (aka rbac) 21:37:27 kevin was on top of most 21:37:42 there is one that is blocking - https://review.openstack.org/247019 21:37:54 https://launchpad.net/bugs/1514810 21:37:54 Launchpad bug 1514810 in neutron "Turning on 'enable_dhcp' on subnet update cause request failure for pluggable IPAM" [High,In progress] - Assigned to Gary Kotton (garyk) 21:37:54 I noticed we got a lot fewer bug reports than usual 21:38:21 * armax looks 21:38:38 i still feel like we should have separate bugs repos for each stadioum project 21:38:44 stadium project 21:38:56 garyk: blocking how? 21:39:09 garyk: you mean it’s a gate failure? 21:39:22 I thought we already have per-project bug repos 21:39:35 what i means is that is some one decide to create a subnet without dhcp and then wants to enable it they cannot when using ipam 21:39:45 neiljerram_bb: we do, but neutron + neutron *-aas is a single deliverable 21:39:46 neiljerram_bb: perhaps it was meant to be "reps" not "repos" 21:39:52 neiljerram_bb: no, not for lbaas, fwaas, etc. 21:39:56 and as such they are tracked with a single LP project 21:40:13 garyk as per governance current status 21:40:15 Ah yes, I remember that case now 21:40:16 Yes, the single LP project keeps it simple 21:40:22 gary should that change, we’ll revisit 21:40:29 but as of now, one LP project it is 21:40:39 mestery: i think that it complicates the triage and gives a misrepresentation of the core neutron bugs. 21:40:54 it doesn’t complicates it 21:40:57 bugs are bugs 21:40:59 garyk: How so? I don't agree 21:41:00 right 21:41:06 whether they target one project or another 21:41:07 armax: yeah but regardless of how they're tracked I think that from the neutron perspective it might make sense to have bug deputys which are comfortable enough with the subject matter. I just don't know if the community has enough volunteer 21:41:21 when say 70% are lbass, fwaas and vpaas are those core? 21:41:41 * salv-orlando I shot the sheriff, but I did shot no deputy 21:41:41 i'm not sure that's a typical week, is it? if so, that's surprising. 21:41:52 salv-orlando: the deputy should reach out the sme in the areas to get help 21:42:04 armax: makes sense 21:42:08 no-one is asking a single individual to do the whole heavy-lifting 21:42:08 anyways, i pass the baton on to …? 21:42:22 rossella_s: ? 21:42:23 as soon as you can see that a bug affects, let’s say vpnaas 21:42:30 what’s so complicated about it? 21:42:38 garyk, yes 21:42:40 * salv-orlando this is thanksgiving week... it's going to be lighter ;) 21:42:43 cool 21:42:44 garyk: find the LT for that area, pass on the triage. 21:42:46 having a different project would only make the bug report go to a differnt project 21:42:53 i thinks tags is enough for now 21:42:55 actually 21:43:22 I almost wonder if we should fold the client bug reports into the neutron 21:43:24 but let 21:43:30 but let’s not go there 21:43:49 armax: as the client has a different release model that might be tricky 21:43:54 salv-orlando: right 21:43:55 since the interface always get the filing, i can see the 'almost', yeah. 21:44:07 salv-orlando: that’s why I am saying…let’s not go there 21:44:29 garyk: anything else worth raising besides the blocker bug you pointed out? 21:44:49 manjeets: fixed a bug that would have broken the gate if the client got updated. 21:44:53 as for splitting the LP project into the aas ones 21:45:07 prolly the best course of action is to start bike shedding on a governance patch change 21:45:10 i am in a minority here. moving on douglass 21:45:13 garyk: feel free to post it 21:45:55 and then we can see whether we can split the LP projects 21:45:55 nope, no more updates on the bugs. 21:46:20 but without that I think we’d be putting the kart ahead of the horse 21:46:29 garyk: ok, cool thanks very much for your help this week 21:46:33 next week deputy is rossella_s 21:46:40 what about the week after that 21:46:42 any takers? 21:46:54 come on, you know you want to 21:46:57 i can 21:47:06 armax: pass around the straws - short one gets the node 21:47:16 we have a winner of a $100 amazon gift card! 21:47:24 who 21:47:50 wow!!! do I hear bribes going on here? 21:47:55 you didn’t see that coming did you? 21:48:15 #action dougwig bug deputy for teh week of Nov-30 21:48:21 Sukhdev: not bribes 21:48:22 armax: is that gift card branded with Monty Python's Inquisition? 21:48:23 incentives 21:48:26 * ihrachys is back to being highly motivated 21:48:30 Sukhdev: it's after volunteering, so it's _probably_ not a bribe 21:48:46 moving on 21:48:50 #topic Docs 21:48:57 emagana is not here :( 21:49:20 #topic Open Discussion 21:49:30 dougwig: you’re up 21:49:35 * armax hands over the mike 21:50:00 armax: I am actually here! 21:50:03 i think dougwig is gone 21:50:06 work on neutron-lib has started, and we pulled over neutron.i18n, because so many use it. amotoki mentioned that each repo needs its own, so it gets its own catalog. but we have not been doing that. it's only about six lines of code, so i'm cool either way, but what do the i18n folks have to say? 21:50:14 edgar: oops 21:50:19 kevinbenton: no, dougwig is driving through nevada, hoping his LTE connection holds 21:50:21 armax: n.p. 21:50:26 dont want to change the meeting 21:50:30 just keep going 21:50:43 dougwig: that is my understanding on i18n. I need to investigate more. 21:50:45 edgar: ok, feel free to chime in, I didn’t see your usual handle 21:51:06 I believe catalog is defined by a string. so I would have a wrapper that gets the string and does remaining magic. 21:51:11 armax: yeap.. I got a new laptop and all needs to be re-configured! 21:51:24 dougwig: it is not a blocker at the moment. I can investigate the right approach. 21:51:29 amotoki: we'll need to merge the one in neutron-lib either way; the question is whether we export it for other projects to use. and if we go fix all the subprojects that are grabbing it from neutron. 21:51:41 amotoki: ok, thanks. 21:51:44 dougwig: as far as I can tell it makes sense to move it, I have seen many projects using it 21:51:51 dougwig: my vote is to leave i18n stuff as-is. 21:51:55 dougwig: I wonder if it needs to be wrapped as ihrachys suggested 21:52:20 amotoki: it's not a leave or not issue. it's a use it once from neutron-lib, or clone it everywhere. because they all have strings, even the lib. 21:52:24 dougwig: what I mean, is we can have one in neutron-lib that neutron will eventually move on to 21:52:41 armax: right, the old entry point sticks around until N no matter what. 21:52:50 dougwig: and anything else that cares about it can use it from there 21:53:37 well my understanding of i18n stuff from old times when I did led some i18n work suggests that every project should have its own catalog, otherwise there is no way for them to provide translations because you don't merge compiled i18n .mo files, so they just use whatever is translated for neutron, and nothing for their own unique messages, and most of their i18n marks are wasted. 21:54:06 armax: i think the point is how we libify in a way that lets neutron and networking-vendorA have different message catalogs. not how we invoke the code. and i'm not clear enough on openstack i18n to know the answer. 21:54:15 I guess each repo should have its own catalog, *aas repos included. 21:54:32 ihrachys: and is it the gettext call in the base __init__ that sets that up? or something else? 21:54:47 dougwig: do we know who would know the answer to this question? 21:55:02 dougwig: perhaps we’re not even the right crowd 21:55:06 armax: no, i was hoping someone here would know, or who to ask. i'll head to the ML next, if not. 21:55:14 but amotoki volunteered to research 21:55:48 dougwig: ok cool 21:55:51 dougwig: you can go :-) 21:56:07 haha, ok. 21:56:18 i think we can move to the next topic now. 21:56:23 ooh, down to one bar of signal. 21:56:33 dougwig: text and drive? 21:56:39 not good 21:56:40 armax: rose is driving. 21:56:44 dougwig: ah ok 21:56:46 dougwig: https://github.com/openstack/neutron/blob/master/neutron/i18n.py#L17 all that is different per project is that domain= string. so that should be a param for the wrapper that would probably return a set of _L* functions. 21:57:25 we got 4 mins left to what seemed to be a very short meeting for me 21:57:26 * armax ducks 21:57:45 anyone else has to mention anything else? wedding, parties? 21:57:47 armax: you jinxed it 21:57:53 mlavalle: I did it on purpose 21:57:59 LOL 21:58:10 they always say that afterwards 21:58:22 mlavalle: what would I do otherwise? I though the PTL dude only chore was startmeeting/stopmeeting on irc 21:58:52 That sounds like your cue for... 21:58:58 #endmeeting