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