18:00:46 #startmeeting networking_policy 18:00:47 Meeting started Thu Apr 23 18:00:46 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:51 The meeting name has been set to 'networking_policy' 18:01:03 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#April_22nd.2C_2015 18:01:33 #chair mageshgv ivar-lazzaro igordcard_ s3wong yapeng Yi 18:01:34 Current chairs: SumitNaiksatam Yi igordcard_ ivar-lazzaro mageshgv s3wong yapeng 18:01:37 in case i drop off like last time 18:01:44 hello 18:01:59 s3wong: hi 18:02:10 any announcements from anyone upfront? 18:02:32 per discussion last week we have pushed out the k-3 release 18:03:05 i will probably do it today, and add a k-4 milestone 18:03:14 #topic Bugs 18:03:42 the one critical that shows open in launchpad is #link https://bugs.launchpad.net/group-based-policy/+bug/1432779 18:03:42 Launchpad bug 1432779 in Group Based Policy "redirect actions don't work with external policies" [Critical,In progress] - Assigned to Ivar Lazzaro (mmaleckk) 18:03:51 however the patch for this was merged in master 18:04:00 ivar-lazzaro: can you confirm that this was completed? 18:04:30 SumitNaiksatam: I think we had an action for testing this? 18:04:43 ivar-lazzaro: okay 18:05:00 ivar-lazzaro: had anyone specifically take that action item? 18:05:24 *taken 18:05:34 IIRC it was on mageshgv plate 18:05:38 okay 18:05:49 i dont see it in the meeting logs 18:06:11 mageshgv: is this something you are planning or you wont have time? 18:06:40 SumitNaiksatam: I did test test it once before the patch was merged in master 18:06:57 i believe the difficulty was with crafting the right service and the infrastructure to test this 18:07:00 mageshgv: thats great 18:07:22 mageshgv: thank you! 18:07:27 ivar-lazzaro: so perhaps we can close this in launchpad for now 18:07:31 Sumitnaiksatam, ivar-lazzaro: I would like to bring up another issue here 18:07:41 SumitNaiksatam: not sure we have to backport this 18:07:45 mageshgv: can you add a note in LP to the effect that you tested it manually? 18:07:51 The current model only addresses one armed devices 18:08:01 SumitNaiksatam: for which I mean that I don't remember if I already sent the stable/juno patch :) 18:08:09 ivar-lazzaro: okay 18:08:12 i think you did 18:08:25 ivar-lazzaro: we will discuss stable/juno backports as next topic 18:08:32 mageshgv: go ahead 18:08:46 mageshgv: so your concern is with this specific patch or our model in general? 18:09:25 SumitNaiksatam: Yes, I think we are missing one main thing when we have redirect from an External policy. 18:09:42 mageshgv: okay, what is that? 18:10:15 When we have a redirect from a normal PTG, for two armed services, the services would get one port on consumer and one port on provider PTGs 18:11:22 mageshgv: can't this happen even with External Policies? Even though you can't explicitly create Policy Targets you can still implicitly use the Neutron external network for creating ports 18:11:47 But in case of redirect from External Policy, one of the ports will be on provider PTG, but the External policy represents the whole internet, and we cannot instantiate a two armed service in this case (especially L3 services) 18:12:25 ivar-lazzaro: Neutron does not allow us to plug a VM into an external network right ? 18:12:37 mageshgv: per ivar-lazzaro’s comment, i think any configuration on the external network is considered out of the scope of GBP 18:12:40 mageshgv: I'm pretty sure it does! SumitNaiksatam? 18:13:15 mageshgv: i believe as an admin you can, but i am not totally sure 18:13:48 mageshgv: unless we see a need for final users to deploy PTs on External Policies, I would not add this capability to the API 18:14:09 mageshgv: whether this happens internally though, that's a different story 18:14:33 ivar-lazzaro: sorry, i lost you there, why would the API need to change one way or the other? 18:14:35 mageshgv: service drivers could implicitly figure out how to plug to external policies 18:14:52 SumitNaiksatam: to allow Policy Target CRUD on External Policies 18:15:08 ivar-lazzaro: ah okay, got it 18:15:24 ivar-lazzaro,SumitNaiksatam: okay, let me explore on that a bit more, but I think we will need a model in place in Service Chain driver/GBP I think rather than the Node driver 18:15:53 mageshgv: sure, please keep me in the loop so I can include this in the SC refactor 18:15:56 mageshgv: okay, fair point, would wait to hear back from you on the investigation 18:16:14 ivar-lazzaro,SumitNaiksatam: okay 18:16:25 an orthogonal point - the use of the “external policy” terminology confuses an lot of people 18:16:39 i wish we had called this “external PTG” or something similar 18:16:50 that is much easier to related to with the rest of the model 18:16:57 we are still in time aren't we? :) 18:17:07 that's what Juno was for, gathering feedback 18:17:14 Right, now that you mention it it does sound different :) 18:17:34 ivar-lazzaro: mageshgv: i thought i did just bring it up 18:17:39 based on the feedback i got 18:17:42 If anything, I would also go back to the notion of "Contract", policy rule set really is a little weird 18:17:53 ivar-lazzaro: :-) 18:18:28 i am definitely in favor of moving “external policy” to “external PTG” 18:18:37 i also like “contract” over “PRS” 18:19:02 however, it has propagated in the documentation and collateral quite a bit 18:19:07 just to be sure, do you mean a new class called "External Policy Target Group" 18:19:17 ivar-lazzaro: I also like contract more --- the motivation behind name change was to get rid of endpoint, a wholesale change back then seems a bit drastic looking back now 18:19:18 or a traditional Policy Target Group with external attributes? 18:19:18 so we would need to check with folks before we can make that call 18:19:24 SumitNaiksatam: ^^^ 18:19:41 ivar-lazzaro: i meant rename “external policy” to “external policy target group" 18:20:01 s3wong: true 18:20:21 ok we are digressing a bit here, we can circle back to this in the open discussion 18:20:31 any other bugs to discuss today? 18:20:32 s3wong: endpoint still has some conflicts in the openstack world, but I don't really see anything wrong with Contract 18:20:42 ivar-lazzaro: true 18:20:50 we wont go back on PT and PTG 18:21:04 ivar-lazzaro: correct, that was the point. Changing EP was necessity, changing everything else along with it seems a bit drastic looking back 18:21:12 s3wong: true 18:21:26 ok seems like no other bugs to discuss 18:21:29 #topic Functional/Integration Tests 18:21:49 i posted this patch #link https://review.openstack.org/#/c/174267 which triggers jishnu’s test suite 18:22:10 jishnu’s test suite - gbpfunc - is an integration test suite 18:22:26 that jishnu has developed 18:23:29 there were a couple of failures and i am trying to work with jishnu to idnetify the root cause (whether they are actual failures or test issues) 18:23:55 currently the gate job is not instrumented well to get the results of the tests 18:24:07 so you have to manually go through the console log to see if there are any failures 18:24:14 we will try to enhance this soon 18:24:39 other than that, the experimental job has now been moved to a check queue 18:25:04 so you need not do a “check experimental” to trigger this functional/integration job run 18:25:29 the job runs on all the branches, stable/juno, master and feature/refactor 18:25:41 its non-voting for now 18:26:02 once we clean it up and get more confidence in the job, we will make it fully voting 18:26:09 any questions/comments? 18:26:49 i believe rkukura is out today 18:26:56 so i will skip packaging 18:27:15 i have vancouver summit preparation as standing item, i will take that up later 18:27:29 #topic Backports to stable/juno 18:27:36 #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:stable/juno,n,z 18:28:02 ivar-lazzaro: i had a question on #link https://review.openstack.org/#/c/175556/ 18:28:10 you can respond on gerrit 18:28:25 mageshgv: can you take a look at #link https://review.openstack.org/#/c/170972/ 18:28:35 its a cherry-pick that you have reviewed before 18:29:10 SumitNaiksatam: It looked okay to me, but rkukura raised some concerns on the migration initially 18:29:32 Did we conclude on that 18:29:47 SumitNaiksatam: ok 18:30:24 mageshgv: i believe the earlier mentioned patch will resolve that issue, ivar-lazzaro? 18:30:32 SumitNaiksatam: I think that the reason why that part is missing is that the counterpart was not backported in Juno yet 18:30:41 ivar-lazzaro: okay 18:31:10 ivar-lazzaro: mageshgv’s question, does the second patch need to wait for the earlier one to merge? 18:31:29 SumitNaiksatam: so this #link https://review.openstack.org/#/c/164920/ has no backport yet 18:32:22 SumitNaiksatam: which one is which? :) 18:33:08 ivar-lazzaro: the commit titles are confusing - this one #link https://review.openstack.org/#/c/170972/ has the same commit title as #link https://review.openstack.org/#/c/164920/ 18:33:42 ivar-lazzaro: perhaps we can resolve this offline, and let mageshgv and me know which ones to look at in the backport queue and in which order 18:33:45 SumitNaiksatam: yeah the first one is a backport 18:33:56 SumitNaiksatam: the second one is in master 18:34:12 ivar-lazzaro: but you said that the one in the master does not have a backport 18:34:26 SumitNaiksatam: in the sense that it's not merged 18:34:31 ivar-lazzaro: ah okay 18:34:43 SumitNaiksatam: after it merges, I will need to update #link https://review.openstack.org/#/c/175556/ 18:34:54 SumitNaiksatam: per your previous point 18:35:21 SumitNaiksatam: I probably should make it dependent, or Workflow -1 for now 18:35:28 ivar-lazzaro: yeah makes sense, okay we will watch out for that, nag us anyway :-) 18:35:47 ivar-lazzaro: thats okay, dont have to make it dependent 18:36:10 #topic Kilo sync 18:36:37 apart from the testing the UI, i believe the #link https://review.openstack.org/#/c/170845 is the last remaining the patch, mageshgv? 18:37:42 SumitNaiksatam: yes, one more thing that we missed is a devstack update on kilo branch, realized it today when I tried to test on a new devstack 18:37:55 mageshgv: yeah, i will do that 18:38:29 mageshgv: hopefully, it will be there before you rise again tomorrow ;-) 18:38:39 SumitNaiksatam: Thanks :) 18:38:43 np 18:38:53 #topic Floating IP support 18:39:00 mageshgv: over to you 18:39:10 Spec: #link https://review.openstack.org/#/c/167174 18:39:23 Impl: #link https://review.openstack.org/#/c/167174/ 18:39:31 we are getting close to wrapping this, right? 18:40:31 SumitNaiksatam: Yes, I think it is in final stages of iteration, may be you and ivar-lazzaro could take a look at it once more 18:40:44 mageshgv: yes sure 18:40:46 I will update the spec 18:40:50 mageshgv: yup 18:40:51 mageshgv: yes 18:41:11 please update the spec so that the whole team will have the right context to review 18:41:23 i believe earlier Yi and yapeng were also reviewing this 18:41:37 mageshgv: anything to discuss here? 18:41:38 SumitNaiksatam: yes, will post it first thing my morning 18:41:52 mageshgv: thanks 18:42:09 i think mageshgv is going to be PTO soon, so we need to wrap this up 18:42:14 SumitNaiksatam: I think there is more consensus now, nothing from my side 18:42:17 *be on 18:42:24 mageshgv: okay thanks 18:42:36 #topic Service chain driver refactor 18:42:48 Spec #link #https://review.openstack.org/#/c/174118 (still WIP) 18:43:07 a number of people are co-authors on this and will update it in parallel 18:43:24 implementation patches: #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/sc-refactor,n,z 18:43:38 ivar-lazzaro: noticed that you started adding some structure around this, great 18:44:04 SumitNaiksatam: yeah, that would be needed anyway even while the spec is WIP 18:44:07 i was also on the hook for doing some initial iterations on this, so i will post as we go along 18:44:16 ivar-lazzaro: yeah, i will look at it 18:44:29 SumitNaiksatam: I have a question on #link https://review.openstack.org/#/c/176580/ 18:44:32 anyone want to discuss anything in this context? 18:44:45 ivar-lazzaro: yes, shoot 18:45:16 SumitNaiksatam: the functional tests broke, I guess it may be because of some backward incompatible changes (hopefully not) 18:45:37 SumitNaiksatam: while I investigate this, how could I fix the devstack installation if needed? 18:45:37 ivar-lazzaro: oh, i will take a look 18:46:06 SumitNaiksatam: Is there anything I can merge together with my patch in order to make this work? 18:46:32 ivar-lazzaro: devstack artifacts are not in-tree 18:46:45 ivar-lazzaro: let me try to investigate what is working 18:46:50 SumitNaiksatam: also I can't really see the Neutron logs 18:47:05 ivar-lazzaro: the script which clones the devstack is in tree 18:47:49 SumitNaiksatam: but can I modify things like the local.conf? 18:48:17 ivar-lazzaro: that will have to be done in the relevant devstack branch which gets pulled when this job is run 18:49:08 let me take a look and see if i can fix it 18:49:28 is hemanthravi here? 18:49:36 SumitNaiksatam: that sounds painful, any relevant configuration change would require multiple iteration before fixing the gate 18:49:50 SumitNaiksatam: shall we bring at least the local.conf in our tree? 18:50:24 ivar-lazzaro: i dont understand how you can avoid multiple iterations by bringing local.conf into the tree 18:50:36 i am not opposed to bringing the local.conf into the tree 18:50:56 in fact the plan is to be able to move to the devstack plugin model 18:50:59 SumitNaiksatam: the patch breaking the configuration can also push the fix at the same time 18:51:16 so that we have all the relevant devstack artifacts in tree 18:51:26 SumitNaiksatam: ++ 18:51:28 and we can just pull the upstream devstack branch and patch it 18:51:35 however that will take some more time 18:52:08 ivar-lazzaro: regardless of whether we fix the local.conf in tree or in the devstack branch, we will need to recheck 18:52:30 and we know which patch breaks the branch, becuase the gate job is going to fail on that patch 18:53:08 ivar-lazzaro: but i think you have a good point 18:53:36 let me try to see how much of the devstack artifacts i can bring in right away 18:53:41 into the tree 18:53:46 SumitNaiksatam: thanks! 18:54:01 i was pushing this down the road, but perhaps needs to be done sooner 18:54:11 so i will first fix the kilo branch 18:54:15 and then try this out 18:54:33 igordcard_: you are keeping a track of the spec? 18:55:59 perhaps he is not around 18:56:00 moving on 18:56:11 #topic Refactor feature branch 18:56:20 #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:feature/refactor,n,z 18:56:28 currently only Yi’s patch 18:56:40 Yi: apologies for not getting to this 18:56:45 np 18:56:48 but i believe this is ready to merge 18:56:57 yes 18:56:59 it's ready 18:57:18 it got delayed because we move to feature branch and caused you a lot of pain! 18:57:37 ivar-lazzaro and i will try to get this merged by tomorrow latest 18:57:42 ivar-lazzaro: sound okay? 18:57:53 great 18:57:53 SumitNaiksatam: ok 18:57:53 unless someone else has objections 18:58:15 Yi: yapeng: thanks for your patience on this 18:58:20 #topic Liberty/Vancouver Summit 18:58:36 posted an etherpad to gather ideas for discussion #link https://etherpad.openstack.org/p/gbp-liberty-design-summit 18:58:59 some of us have been discussing the hands-on lab 18:59:04 ivar-lazzaro: want to give an update? 19:00:01 SumitNaiksatam: yeah we are preparing the USB sticks for the lab session 19:00:10 actually we are in the process of getting them 19:00:27 ivar-lazzaro: okay great 19:00:29 I'd like to request help in some task though 19:00:34 ivar-lazzaro: sure 19:00:56 There are two main items that would be great to have in Horizon 19:01:11 1) shared attribute for all the concerned objects 19:01:22 2) external connectivity UI 19:01:36 anyone is willing to take these 2 items? :) 19:02:16 ivar-lazzaro: i am not holding my breath! :-( 19:02:39 ivar-lazzaro: we are already able to showed the shared resources, right? 19:03:21 SumitNaiksatam: yeah, but we can't set them yet 19:03:49 ivar-lazzaro: them being, the shared attributes? 19:04:18 SumitNaiksatam: yeah, IIRC the UI doesn't have the "shared" flag for any GBP resource at creation time 19:04:37 ivar-lazzaro: okay let me follow up with you offline on this one 19:04:48 ivar-lazzaro: for the external connectivity UI, i am not sure 19:05:09 ivar-lazzaro: as we discussed, perhaps best not have the workflow being driven from the UI for this hands-on 19:05:13 we drive it through the CLI 19:05:29 and use the UI feedback 19:05:41 okay we are 5 mins over, thankfully not kicked out yet 19:05:46 #topic Open Discussion 19:06:07 we can continue the earlier discussion, but want to give anyone else a chance to bring something else up 19:06:58 if nothing else, we can end for today 19:07:29 alrighty thanks everyone, keep up the good work 19:07:38 and apologies for going over 19:07:41 bye! 19:07:45 thanks, adieuuuu 19:07:47 bye 19:07:55 #endmeeting