18:02:18 <SumitNaiksatam> #startmeeting networking_policy 18:02:19 <openstack> Meeting started Thu Oct 8 18:02:18 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:23 <openstack> The meeting name has been set to 'networking_policy' 18:02:40 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Oct_8th_2015 18:03:12 <SumitNaiksatam> #topic Packaging 18:03:38 <SumitNaiksatam> starting with this since rkukura mentioned we were on the edge with regards to the fedora packages :-) 18:03:46 <SumitNaiksatam> rkukura: any blockers for you? 18:03:59 <rkukura> no blockers - need to do some testing 18:04:40 <rkukura> then we’ll get the updated packages pulled into RDO and/or Delorean 18:05:05 <SumitNaiksatam> rkukura: okay, so we will make the cut off? 18:05:33 <rkukura> SumitNaiksatam: The drop-from-fedora cutoff? 18:05:44 <SumitNaiksatam> rkukura: yeah 18:06:10 <rkukura> I think we are already clear of that since the packages have been updated to build without broken dependencies 18:06:47 <SumitNaiksatam> rkukura: ah nice, did not realize that you already had their packages into their system 18:06:51 <SumitNaiksatam> mageshgv: hi 18:06:54 <mageshgv> SumitNaiksatam: hi 18:07:03 <SumitNaiksatam> rkukura: thanks for the update on the packaging 18:08:16 <SumitNaiksatam> no updates on the integration testing from me 18:08:29 <SumitNaiksatam> #topic Bugs 18:09:07 <SumitNaiksatam> rkukura: you are working on #link https://bugs.launchpad.net/group-based-policy/+bug/1503135 ? 18:09:07 <openstack> Launchpad bug 1503135 in Group Based Policy "Concurrent subnet allocations from pool can overlap" [High,In progress] - Assigned to Robert Kukura (rkukura) 18:09:11 <SumitNaiksatam> saw the WIP patch 18:09:41 <rkukura> yes, initial patch just added logging so I could verify my theory of what the problem is 18:09:50 <SumitNaiksatam> rkukura: okay 18:09:56 <rkukura> working on the fix and should have non-WIP patch later today 18:10:18 <SumitNaiksatam> currently this seems like highest priority for us 18:10:31 <SumitNaiksatam> not marked as critical since it does not always happen 18:10:56 <rkukura> hopefully this will let us make rally require 100% success 18:11:35 <SumitNaiksatam> rkukura: absolutely, fingers crossed! 18:11:35 <ivar-lazzaro> rkukura: nice! With how many workers? 18:12:24 <rkukura> ivar-lazzaro: we can turn it up until it breaks 18:12:25 <SumitNaiksatam> ivar-lazzaro: i believe the fix should be independent of the number of workers 18:12:36 <SumitNaiksatam> rkukura: :-) 18:12:54 <ivar-lazzaro> just wondering if it's more than 1 right now 18:13:16 <ivar-lazzaro> of course we will go over 9000 eventually :D 18:14:36 <SumitNaiksatam> mageshgv: #link https://bugs.launchpad.net/group-based-policy/+bug/1489090 or #link https://bugs.launchpad.net/group-based-policy/+bug/1418839 ? 18:14:36 <openstack> Launchpad bug 1489090 in Group Based Policy "GBP: Resource intergrity fails between policy-rule-set & external-policy" [High,Confirmed] - Assigned to Magesh GV (magesh-gv) 18:14:37 <openstack> Launchpad bug 1418839 in Group Based Policy "Service config in yaml cannot be loaded" [High,In progress] - Assigned to Magesh GV (magesh-gv) 18:15:31 <mageshgv> SumitNaiksatam: I did not get a chance to work on this yet, right now busy with the NCP testing 18:15:38 <SumitNaiksatam> mageshgv: okay 18:15:51 <SumitNaiksatam> any other critical bugs that we need to discuss 18:15:58 <SumitNaiksatam> ? 18:16:31 <SumitNaiksatam> ivar-lazzaro: our devstack has default number of worker threads, which is 0, and it means essentially one worker thread 18:16:54 <SumitNaiksatam> ivar-lazzaro: rally is instrumented to exercise with a concurrency of 10 18:17:18 <ivar-lazzaro> SumitNaiksatam: cool! Thanks 18:17:19 <SumitNaiksatam> by increasing the concurrency we do see these errors 18:17:34 <rkukura> ivar-lazzaro: Were you talking about neutron workers or rally workers? 18:17:51 <SumitNaiksatam> rkukura: i believe ivar-lazzaro was referring to neutron workers 18:18:23 <ivar-lazzaro> rkukura: SumitNaiksatam yes, Neutron workers 18:18:35 <SumitNaiksatam> it seems that setting the concurrency configuration in rally should not impact if we have only one worker on neutron 18:18:37 <SumitNaiksatam> however it does 18:19:18 <rkukura> Its clear from the logging that neutron is executing GBP requests concurrently in the rally tests. 18:19:18 <ivar-lazzaro> SumitNaiksatam: not sure default is 0 though, I think this was changed in Kilo to the number of cores running on the host 18:19:21 <SumitNaiksatam> and we are seeing the same error in a systemt where we have increased the nubmer of neutron api workers 18:19:58 <SumitNaiksatam> ivar-lazzaro: the devstack job is defaulting 0 in the conf 18:20:04 <ivar-lazzaro> ok 18:20:20 <SumitNaiksatam> ivar-lazzaro: if internally it executes on multiple cores, then that might explain 18:21:14 <SumitNaiksatam> however we are seeing teh same pattern of concurrency rally results across juno and kilo 18:21:29 <SumitNaiksatam> wiht, what i understand, to be the same devstack job 18:21:58 <SumitNaiksatam> perhaps best to test on a local system where we have better control over these parameters 18:22:21 <SumitNaiksatam> ivar-lazzaro: but certainly good to investigate if there is some automatic mapping to cores happening 18:22:54 <SumitNaiksatam> on juno, i we set api workers to 0, and rpc workers to 0, then i have verified that only neutron server process gets spawned 18:23:03 <SumitNaiksatam> i -> if 18:23:21 <SumitNaiksatam> *only 1 18:23:33 <rkukura> There are multiple greenthreads processing API requests within each worker process, aren’t there? 18:24:47 <SumitNaiksatam> rkukura: ivar-lazzaro perhaps that is decided by the number of cores? 18:25:16 <ivar-lazzaro> SumitNaiksatam: that would be the Neutron default 18:25:29 <ivar-lazzaro> SumitNaiksatam: so unless we force it otherwise on devstack, then that's the case 18:26:01 <SumitNaiksatam> ivar-lazzaro: yeah 18:26:28 <SumitNaiksatam> rkukura: will be good to investigate how is the threading model/number controlled 18:27:20 <rkukura> SumitNaiksatam: agreed 18:27:22 <SumitNaiksatam> #topic Protocol number support 18:27:42 <SumitNaiksatam> mageshgv brought up this user requirement #link https://bugs.launchpad.net/group-based-policy/+bug/1499916 18:27:42 <openstack> Launchpad bug 1499916 in Group Based Policy "GBP classifier create API does not support custom IP protocol numbers" [High,Confirmed] 18:28:14 <SumitNaiksatam> is there any objection to allowing integer protocol numbers in teh policy classifier? 18:29:09 <ivar-lazzaro> SumitNaiksatam: does Neutron allow that on SGs? 18:30:05 <mageshgv> ivar-lazzaro: As far as I know it does 18:30:25 <SumitNaiksatam> ivar-lazzaro: i was thinking this is something that can be rejected at the driver level if not supported, no? 18:31:07 <mageshgv> SumitNaiksatam, ivar-lazzaro: Just checked, Security groups does accept protocol numbers 18:31:08 <ivar-lazzaro> SumitNaiksatam: also, we can have some level of translation for well known protocol numbers 18:31:21 <SumitNaiksatam> ivar-lazzaro: for neutron #link https://github.com/openstack/neutron/blob/master/neutron/extensions/securitygroup.py#L135-L142 18:31:25 <SumitNaiksatam> mageshgv: thanks 18:31:40 <SumitNaiksatam> ivar-lazzaro: the translation i believe is available in the UI currently 18:32:00 <SumitNaiksatam> well i know it is, we added that support a few weeks back 18:33:43 <SumitNaiksatam> since this will be an additive change, i believe it should not create any backward incompatibility? 18:35:04 <SumitNaiksatam> okay, so i think we can go ahead and make this minor update to the API (basically in the validation function) 18:35:15 <SumitNaiksatam> now our favorite part of the meeting 18:35:26 <SumitNaiksatam> #topic Node Composition Plugin/Driver/Plumber enhancements 18:35:55 <SumitNaiksatam> last week and over the weekend we reviewed and merged a number of patches on this topic 18:36:31 <SumitNaiksatam> there are two specs which we have still not merged (mostly because they have been evolving as ivar-lazzaro has been implementing them): 18:36:35 <SumitNaiksatam> #link https://review.openstack.org/#/c/228693 18:36:44 <SumitNaiksatam> and https://review.openstack.org/#/c/203226/ 18:37:46 <SumitNaiksatam> igordcard: you had a question on the proxy ptg spec? 18:38:22 <igordcard> yes, just a simple technical question that can be answered by testing the current impl as well :) 18:38:31 <igordcard> but it is: "How does TScP currently flow traffic? By routing?" 18:39:03 <ivar-lazzaro> igordcard: it depends on the attached services 18:39:36 <ivar-lazzaro> igordcard: TScP creates a topology where many networks are connected by "Services", these can be L2/L3 services 18:39:37 <SumitNaiksatam> igordcard: both routing and switching 18:40:26 <igordcard> ivar-lazzaro, SumitNaiksatam : and is that the current state or the final state after the changes are merged? 18:40:55 <ivar-lazzaro> that's already the case 18:41:06 <ivar-lazzaro> not sure the heat driver still supports it though 18:42:09 <igordcard> thanks ivar-lazzaro SumitNaiksatam 18:43:12 <SumitNaiksatam> ivar-lazzaro: thanks 18:43:39 <ivar-lazzaro> by the way, there's a "bonus" patch on top of the current chain 18:43:45 <ivar-lazzaro> https://review.openstack.org/#/c/179327/ 18:43:50 <ivar-lazzaro> #link https://review.openstack.org/#/c/179327/ 18:44:19 <ivar-lazzaro> We used to have one patch for remote SG implementation 18:44:21 <SumitNaiksatam> ivar-lazzaro: thanks, i noticed 18:44:33 <ivar-lazzaro> which however is not supported/working in Neutron 18:44:39 <SumitNaiksatam> ivar-lazzaro: its great that you split it form the other patch 18:45:02 <ivar-lazzaro> I removed that part, but I at least kept the part where we split the SG mapping into a pluggable component 18:45:28 <ivar-lazzaro> Starting from there, it should be easy to move to a model where sharing PRSs is possible 18:45:35 <SumitNaiksatam> ivar-lazzaro: yeah, this makes it easy to merge now and very useful 18:46:13 <SumitNaiksatam> ivar-lazzaro: for the remaining patches in the chain, https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/node-centric-chain-plugin,n,z 18:46:26 <SumitNaiksatam> ivar-lazzaro: is there any update to the spec for the HA/cluster model? 18:46:28 <ivar-lazzaro> with that, and the SC mapping split, we finally have a RMD with less than 2000 LoC :D 18:46:52 <ivar-lazzaro> I haven't posted the spec yet 18:46:56 <SumitNaiksatam> ivar-lazzaro: i believe there is some change to the internal API for the HA/clustering support? 18:47:01 <SumitNaiksatam> ivar-lazzaro: okay 18:47:15 <SumitNaiksatam> mageshgv: were you able to test these patches? 18:47:23 <ivar-lazzaro> SumitNaiksatam: actually, the API would be public 18:47:36 <SumitNaiksatam> ivar-lazzaro: okay 18:47:49 <ivar-lazzaro> SumitNaiksatam: although we can change it in the default policy.jsonm 18:48:00 <mageshgv> SumitNaiksatam: Yes, in progress, I should be able to complete by this weekend 18:48:07 <SumitNaiksatam> mageshgv: nice! 18:48:12 <SumitNaiksatam> ivar-lazzaro: okay 18:48:49 <SumitNaiksatam> mageshgv: so are we at a point where we are comfortable with the two posted specs? 18:49:02 <SumitNaiksatam> igordcard: wanted to check with you as well, since you reviewed 18:49:17 <mageshgv> SumitNaiksatam: Yes 18:49:30 <SumitNaiksatam> mageshgv: nice, thanks 18:49:48 <igordcard> SumitNaiksatam, yes 18:49:56 <SumitNaiksatam> igordcard: great, thanks 18:50:04 <SumitNaiksatam> ivar-lazzaro: thanks for the update and all the hard work here! 18:50:26 <SumitNaiksatam> #topic Open Discussion 18:50:55 <SumitNaiksatam> there was another request from a user to be able to model remote CIDRs in our classifier to filter N-S connectivity 18:51:38 <SumitNaiksatam> i believe some of us had the discussion earlier, and were considering associating a CIDR with the external policy 18:52:09 <SumitNaiksatam> just wanted to bring this up, something we should think through and follow up on 18:52:43 <SumitNaiksatam> there was also another request from a user regarding this #link https://bugs.launchpad.net/group-based-policy/+bug/1501657 18:52:43 <openstack> Launchpad bug 1501657 in Group Based Policy "Explicit router provided for L3 Policy creation is not used" [High,New] - Assigned to Robert Kukura (rkukura) 18:53:03 <SumitNaiksatam> which was supposed to work, but in my testing did not work 18:53:09 <rkukura> I have not looked into that yet, but will 18:53:22 <SumitNaiksatam> rkukura: thanks for volunterring on that 18:53:48 <SumitNaiksatam> anything else that we missed for today? 18:54:32 <SumitNaiksatam> alright, thanks everyone 18:54:37 <SumitNaiksatam> bye! 18:54:40 <rkukura> bye 18:54:41 <mageshgv> bye 18:54:54 * tbachman sneaks off 18:54:57 <SumitNaiksatam> #endmeeting