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