18:01:16 <SumitNaiksatam> #startmeeting networking_policy
18:01:17 <openstack> Meeting started Thu May 10 18:01:16 2018 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:22 <openstack> The meeting name has been set to 'networking_policy'
18:01:41 <annakk> Hi
18:02:07 <SumitNaiksatam> annakk: i had a couple of minor comments on your patch
18:02:13 <SumitNaiksatam> but otherwise looks fine to me
18:02:22 <SumitNaiksatam> happy to merge it as is, if you want to go ahead
18:02:25 <annakk> yes, thanks for that!
18:02:51 <annakk> yes, lets merge, I'll address the comments in next patch
18:02:59 <SumitNaiksatam> annakk: okay sure
18:03:08 <SumitNaiksatam> so for master and stable/pike, right?
18:03:14 <annakk> correct
18:03:26 <rkukura> hi SumitNaiksatam, annakk
18:03:35 <SumitNaiksatam> rkukura: hi
18:04:02 <SumitNaiksatam> annakk: done
18:04:20 <annakk> thanks!
18:04:27 <annakk> hi rkukura!
18:04:43 <SumitNaiksatam> rkukura: were you planning to introduce testing the validation script in the aim gate job?
18:05:12 <rkukura> I do plan to
18:05:34 <SumitNaiksatam> okay thanks
18:05:39 <SumitNaiksatam> i went through most of the patch
18:06:17 <rkukura> I’m not sure if I should add that in the current patch, or once the GBP validation is added
18:06:32 <SumitNaiksatam> hsve to admit, its a bit more difficult to review than regular patches
18:06:55 <rkukura> I’ve been working on making validation fail (even with repair) when any GBP (or other features for which validation isn’t implemented) are in use
18:07:20 <SumitNaiksatam> i would vote in favor if adding it right away even if it means it doesnt cover the GBP resources
18:07:26 <SumitNaiksatam> at some level of sanity check
18:08:05 <rkukura> right - I had looking into it a bit, and wasn’t sure exactly what runs as the AIM gate tests
18:08:24 <SumitNaiksatam> rkukura: i can help you with that, will send you some pointers
18:08:28 <rkukura> there is also the GBP exercise script, but I don’t think that runs in the gate, right?
18:08:36 <SumitNaiksatam> rkukura: it does
18:08:58 <rkukura> There is a similar script somewhere under contrib, too, isn’t there?
18:09:04 <SumitNaiksatam> so we can similarly add another sript
18:09:23 <SumitNaiksatam> i will send you a follow up email as to exactly what runs in the aim gate job, and from where
18:09:29 <rkukura> I’d rather not do a new script, but instead would like to add validation calls to existing scripts
18:09:55 <rkukura> the idea being to make sure scenarios tested in the scripts can be validated
18:09:57 <SumitNaiksatam> yes, you can update the existing one, we have separate one for the aim gate job
18:10:17 <SumitNaiksatam> so it wont affect the other gate jobs
18:10:24 <rkukura> Is it easy to run the AIM gate script manually in a devstack?
18:11:06 <rkukura> you are right that adding validation to the regular exercise script would have to work with other PDs, not just AIM
18:11:14 <rkukura> And that is the goal
18:11:28 <SumitNaiksatam> #link https://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/exercises-aim/gbp_aim.sh
18:11:33 <SumitNaiksatam> rkukura: ^^^
18:11:46 <SumitNaiksatam> you shoulkd be able to run that manually in a devstack
18:12:33 <rkukura> maybe I’ll start with that, and add validation to the normal exercise script once the generic GBP->Neutron validation is implemented
18:12:38 <SumitNaiksatam> the different between this one and the one for the other gate jobs is that we dont spin VMs here since we dont expect the data path to work (in the gate)
18:12:48 <rkukura> right
18:12:53 <SumitNaiksatam> rkukura: yeah, that sounds perfect to me
18:13:01 <SumitNaiksatam> *difference
18:13:28 <rkukura> ok
18:13:32 <SumitNaiksatam> i don’t have anything else planned to discuss for today
18:13:42 <SumitNaiksatam> rkukura: annakk: if nothing else, we can wrap up?
18:13:44 <rkukura> SumitNaiksatam: One question about GBP I ran into working on the validation
18:13:52 <SumitNaiksatam> rkukura: ah  okay
18:14:22 <SumitNaiksatam> ?
18:14:44 <rkukura> I noticed that several model classes (like L2P and PTG) have nullable references to their parent model classes (L3P and L2P in these cases)
18:14:55 <rkukura> why did we do it that way?
18:15:36 <rkukura> I can’t think of a way to use the REST API to make those references null
18:15:53 <rkukura> But it seems we’ll need to validate that they aren’t null
18:16:16 <SumitNaiksatam> hmmm
18:16:25 <SumitNaiksatam> about the REST API, checking
18:16:39 <rkukura> I can test by using sqlalchemy API to null them, etc..
18:17:42 <SumitNaiksatam> so create PTG REST API will allow you to create PTG withough specifying a L2P
18:17:48 <SumitNaiksatam> the driver might fail
18:17:55 <SumitNaiksatam> but the REST API allows you
18:18:11 <SumitNaiksatam> same thing with L2P/L3P
18:18:30 <SumitNaiksatam> i think the thinking was that linear workflow does not have to imposed
18:18:43 <rkukura> If I create an L2P without an L3P, and L3P gets implicitly created
18:18:52 <rkukura> s/and/an/
18:19:08 <SumitNaiksatam> rkukura: good point, but i think that’s the implicit driver behavior
18:19:30 <rkukura> I think you are right
18:19:51 <SumitNaiksatam> also you can think of as PTG and L2P as being different concerns
18:20:00 <rkukura> I guess I could try configuring tests without the implicit PD
18:20:03 <SumitNaiksatam> the former being a policy concern, and the latter being networking
18:20:29 <SumitNaiksatam> so the backends might model them indepedently and hence we didnt want to enforce a strict dependency
18:20:41 <rkukura> but I suspect most PDs will not work without these dependent resources existing
18:21:32 <rkukura> Unless you’ve got a better ideal, I think I’ll test using a normal configuration, and using sqlalchemy to null out the references
18:21:41 <SumitNaiksatam> yeah, agree
18:22:07 <SumitNaiksatam> so of more modeling might have also been too idealistic :-)
18:22:12 <rkukura> but it seem the implicit PD is what should do validation that these dependencies exist
18:22:23 <SumitNaiksatam> more -> our
18:22:52 <rkukura> I’m generally not trying to validate things that the DB enforces
18:23:09 <SumitNaiksatam> that makes sense
18:23:24 <SumitNaiksatam> otherwise it will be too many things
18:23:40 <SumitNaiksatam> also things should be modeled in the right way
18:23:46 <SumitNaiksatam> and if they are not i guess we need to fix them
18:24:00 <SumitNaiksatam> so very good point to bring up
18:24:18 <rkukura> OK, I’m just dealing with making validation fail now when GBP resources exist, and will include some tests for this in the update to the current patch. The follow-on will try to put validation into each PD that validates what that PD is responsible for
18:24:31 <rkukura> OK, I think I’m set for now
18:24:41 <SumitNaiksatam> rkukura: thanks for that update and discussion
18:24:48 <rkukura> I should have an updated patch soon - hopefully tomorrow
18:24:54 <SumitNaiksatam> thanks
18:25:06 <SumitNaiksatam> rkukura: annakk: thanks for joining
18:25:09 <SumitNaiksatam> see you next time
18:25:10 <SumitNaiksatam> b ye
18:25:12 <rkukura> bye
18:25:13 <annakk> thanks! bye
18:25:13 <SumitNaiksatam> #endmeeting