18:01:56 #startmeeting networking_policy 18:01:57 Meeting started Thu Jul 21 18:01:56 2016 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:01 The meeting name has been set to 'networking_policy' 18:02:40 rkukura: nothing much on my side today 18:02:56 anything you wanted to discuss? 18:03:05 same here - working on apic_aim MD, reviewing your stuff, etc. 18:03:22 oh yeah, good point about the spec 18:03:25 is there an update to your address scope spec? 18:03:37 i guess we could have discussed that if there were more people 18:03:39 * tbachman waves to SumitNaiksatam 18:03:47 tbachman: hi there :-) 18:03:52 SumitNaiksatam: hi! :) 18:04:26 rkukura: updated the spec yesterday after the discussion with you and the rest of the team 18:04:32 #link https://review.openstack.org/#/c/343929/ 18:04:59 ok, I’ll re-review 18:05:13 rkukura: thanks 18:05:33 rkukura: one more thing 18:05:50 for the record, my personal view is that GBP should stay as close to Neutron as possible, adding only what is absolutely needed, and avoiding need to constrain Neutron resources used by GBP 18:05:51 rkukura: i was thinking of having a integration job for AIM 18:06:08 rkukura: okay 18:06:28 nothing new on that, just figured I’d mention it here 18:06:37 rkukura: okay 18:06:39 so how would this integration job work? 18:06:55 rkukura: integration job meaning devstack based like how we have for nfp, rally 18:06:56 Would it use an APIC fabric? 18:07:15 rkukura: no, it would exercise the AIM layer 18:07:24 So no data plane 18:07:28 rkukura: right 18:08:06 Ideally, we’d have a 3rd party CI that runs against an ACI fabric 18:08:26 rkukura: right, and that would be a separate job 18:08:28 But are you proposing one that’s hosted in OpenStack? 18:10:10 rkukura: i am proposing a devstack based job that runs against the AIM layer, no dataplane, triggered by openstack infra 18:10:27 makes sense, but what test suite would it run? 18:11:30 rkukura: to begin with it could just be the same exercise script that runs in our other integration job (no service chain stuff), and perhaps also some functional tests from jishnu’s test suite 18:12:04 we are already using jishnu’s test suite for the CRUD operations in the other integration job 18:12:18 OK. Would it do anything to verify the AIM layer? 18:12:41 rkukura: probably not to begin with 18:12:55 guess we could add that 18:12:56 rkukura: if nothing else it would at least verify our devstack setup end to end :-) 18:13:07 makes sense to me 18:13:27 rkukura: okay 18:13:45 I usually run the UTs before pushing a patch, but not always devstack, so this would help prevent breakage 18:13:45 rkukura: so we would have to do this like we did it with NFP 18:13:53 rkukura: right 18:14:09 rkukura: actually that is currently my main motivation 18:14:54 rkukura: i will post a patch to first create the hooks in GBP, lets get that merged 18:15:04 +1 18:15:08 rkukura: then we can post a patch to openstack project-config 18:15:36 rkukura: and once that is merged we can come back to tuning the hooks on the GBP side 18:15:57 rkukura: okay 18:16:07 thats pretty much it from me today 18:16:12 so would there be some initial tests, or just the devstack deploy? 18:16:36 rkukura: it would run the gbp exercise script which will do basic crud operations with GBP resources 18:17:02 rkukura: it might not pass to beging with (but it will be a non-voting job anyway) 18:17:23 I wonder if there are Neutron API excercises we should also run? 18:17:41 rkukura: that would be a good idea too 18:18:06 rkukura: at some point we could just run neutron tempest tests 18:18:17 Don’t those require the data plane? 18:18:27 rkukura: i mean the API ones 18:18:37 that’s what I was thinking of 18:18:57 rkukura: can you review https://review.openstack.org/#/c/327033 again, ashutosh has addressed your earlier comments 18:19:01 sure 18:19:11 thanks 18:19:38 rkukura: regarding your question in the patch on why we are not allowing non-shared L2P on shared L3P 18:19:40 I’m a bit confused on this one 18:20:15 If its just the neutron user getting its own (service) tenant_id, I don’t see a need to use different authtoken stuff 18:20:34 Originally it needed admin rights, but as I understand it, now it doesn’t. 18:21:07 SumitNaiksatam: Please go ahead regarding the sharing! 18:21:27 admin role is required not for this check, but in other methods that plug interfaces into tenant netoworks 18:21:57 i thought we can merge this check now and address the addition of a different user in a subsequent changeset 18:21:58 rkukura: the check in the code is to ensure that the L2P tenant is the same as the L3P tenant 18:22:03 hemanthravi: Agreed that should use other credentials 18:22:23 hi all, just a quick update as I need to drop off now, expect updates on the QoS patch by monday 18:22:46 rkukura: for the resource mapping driver, my understanding is that the neutron rendering might not be possible if the L2P was in a different tenant from that of the L3P 18:22:50 rkukura: would like to merge this for the end of the month release and address the new user independntly as it affect other code 18:23:00 igordcard: great, thanks for the update 18:23:20 igordcard: i will be on vacation, but will check as soon as i am back 18:23:27 SumitNaiksatam: okay, thanks 18:23:42 hemanthravi: The patch looks good to me now - I’ll re-review soon. 18:23:50 igordcard: but i will make sure i alert the other team members as well 18:24:08 thanks, also noticed packstack by default adds admin role to neutron user 18:24:21 hemanthravi: interesting 18:24:21 hemanthravi: ah thats interesting 18:24:55 I wonder if RHEL OSP Director does as well? 18:25:06 hemanthravi: good work digging that, if other distros also do the same thing, it almost becomes the standard thing! 18:25:43 will check on that 18:26:02 SumitNaiksatam: but, devstack just adds neutron as a member. It adds heat and nova as admin.. 18:26:15 songole: ah okay 18:26:22 packstack adds all as admin 18:26:30 SumitNaiksatam: It would be good to eventually see if we really need to constrain the L2P to be the same project as the L3P. It seems useful to share the L3P more widely. 18:26:39 songole: interesting that it would add nova 18:26:58 rkukura: note that the check is in the resource mapping driver 18:27:05 If we really can’t share the L3P more widely than the L2P, then this might be an argument to think of the AS being a higher level that is shared more widely. 18:27:37 SumitNaiksatam: I’m never sure what parts of the RMD are used by the AMD(s) 18:27:40 rkukura: the constraint is not in the API or the model 18:28:17 rkukura: perhaps with neutron RBAC model on networks there is a way to do this, but we havent explored 18:28:24 AMD = [APIC|AIM] Mapping Driver 18:29:00 was trying to figure out AMD :) 18:29:04 SumitNaiksatam: There could definely be a good reason for the contraint, and if so, I agree RBAC might allow relaxing it. 18:29:16 rkukura: i love AMD, i knew a 3-letter acro was cooking up! :-) 18:29:45 MD == Mechanism Driver && Mapping Driver :) 18:29:48 SumitNaiksatam: What is your PTO schedule? 18:30:05 gone for a week starting tomorrow 18:30:14 tbachman: The “mapping drivers” are usually referred to as PDs (policy drivers) 18:30:21 ah 18:30:32 * tbachman will get the hang of neutron lingo soon… ;) 18:30:50 SumitNaiksatam: OK, you had told me about that last week - just wasn’t sure of the dates 18:30:58 rkukura: but i like tbachman’s interpretation to cover both 18:31:14 rkukura: that way AMD covers the PD, MD and AIM 18:31:35 OK, I’ll use APD and AMD from now on 18:32:01 So AMD is [APIC|AIM] Mechanism Driver 18:32:15 no wonder tbachman gets confused 18:32:18 lol 18:32:32 rkukura: I’m always confused. 18:32:36 :-( AMD was a good way to describe the whole solution 18:32:40 rkukura: just don’t use the word “context" 18:32:41 anyway 18:32:46 tbachman: lol 18:32:55 At least the two-letter acronyms MD, ED, and PD are mostly unambiguous 18:33:31 rkukura is hands-down the best 3-letter acronymyst! 18:33:47 I’m a 3LA? 18:34:02 rkukura: there you go! :-) 18:34:39 all right, if nothing else, i guess we can wrap up, i didnt have much of an agenda planned for today 18:35:07 +1 18:35:08 if nothing urgent comes up, we will skip next week’s meeting 18:35:25 thanks all for attending 18:35:29 SumitNaiksatam: thanks! 18:35:36 bye! 18:35:46 bye 18:35:47 bye 18:35:48 bye 18:35:55 #endmeeting