18:02:20 #startmeeting networking_policy 18:02:21 Meeting started Thu Feb 11 18:02:20 2016 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:24 The meeting name has been set to 'networking_policy' 18:02:35 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Feb_11th.2C_4th.2C_2016 18:03:26 #topic Bugs 18:03:32 hi 18:03:57 the fix for the critical bug which we was reported last week in the UI, is still making its way through the backports 18:04:00 hemanthravi: hi 18:04:10 hi 18:04:27 other than that i dont see any critical priority pending bugs 18:04:31 songole: hi 18:04:57 Hi SumitNaiksatam 18:05:03 speak up if anyone has any high priority bugs to discuss 18:05:39 #topic Packaging 18:05:54 rkukura: still no new releases of the stable branches 18:06:13 since i noticed that we still seem to be fix some issues in the drivers 18:06:14 right, but a bit of news on the RDO front 18:06:24 rkukura: yes, saw the email 18:06:27 please go ahead 18:06:58 The Red Hat folks are proceeding with setting up our kilo and liberty branches in Delorean 18:07:12 rkukura: nice! 18:07:36 So package builds for RDO on CentOS 7 will be generated on each commit to those branches 18:07:54 rkukura: sweet! 18:07:55 I believe some CI is done on those as well. 18:08:03 rkukura: ok, that was my question 18:08:13 do they run a CI, and if so what does it do? 18:09:07 They run tempest smoke tests on the packages. Initially I think this will just verify that installing our packages doesn’t break those tests. 18:09:28 rkukura: ok, that sounds reasonable 18:09:43 I think we will need puppet modules integrating GBP with the base RDO install to actually configure GBP 18:10:06 Then it should be possible to get additional tests run against the deployment 18:10:30 rkukura: is there a specific time frame by which we need to get this done? 18:10:43 and/or is it a requirement for “certification”? 18:11:46 I don’t think this is directly a requirement for vendor product certification that is based on RHEL OSP, not RDO. 18:12:03 rkukura: okay 18:12:17 We do need to make a bit of a commitment though 18:12:36 rkukura: committment to add the puppet modules? 18:12:42 Once GBP is turned on in Delorean, we are obligated to fix issues that show up. 18:13:01 I don’t think we are commited to add the puppet modules, at least not yet 18:13:35 But if we commit something that breaks whatver testing is being done with Delorean, we are expected to promptly fix it 18:14:10 There would be automated email notification to the maintainer(s) if something breaks 18:14:16 rkukura: okay 18:14:39 Right now, I’m the only maintainer listed. But we should add at least one more to make sure we can always respond quickly 18:14:56 rkukura: until there are no tests are not run against GBP, then no GBP modules will get loaded 18:15:36 rkukura: so the chances that it breaks their tests (say tempest tests for neutron) is pretty slim, right? 18:15:40 Right, but it is still possible something could change that prevented RPMs from building or installing, and that would need to be fixed 18:15:51 rkukura: absolutely 18:15:58 Like dependency issues, etc. 18:16:22 rkukura: right 18:16:22 Of course, we will want to enable this for master too as soon as possible 18:16:36 rkukura: yes, since you bring up master 18:16:52 Which I think requires our master to depend on the other projects’ master branches rather than liberty 18:17:01 i hit a bit of a speed bump on syncing our master with openstack master 18:17:17 having some problems with extension loading in the tests 18:17:34 so i am working on that 18:17:59 one thing to note, all extension definitions should always extend ExtensionDescriptor 18:18:14 SumitNaiksatam: I wouldn’t be surprised if something has changed that would require our monkeypaching to be updated 18:18:28 rkukura: true, but i have not reached that point yet 18:18:36 OK 18:18:52 my thinking was that some of the monkey patching would not be needed any more 18:19:10 that would be ideal 18:19:11 our Group_policy_mapping extension was not extending ExtensionDescriptor and that was preventing it from being loaded 18:20:00 the next problem i am facing is that our tests fail at loading a new extension “router_availability” extension that was just introduced in neutron 18:20:11 ideally we should not have to load this extension 18:20:39 but the way our UTs are setup its getting into some wierd extension dependency issue 18:20:40 * tbachman wonders if that has to do with our L3 plugin inheriting from DVS 18:20:46 s/DVS/DVR/ 18:20:50 tbachman: good point 18:21:11 tbachman: however, I dont think our UTs use the DVR based extension 18:21:38 SumitNaiksatam: ACK 18:21:41 * SumitNaiksatam cant help notice that tbachman also lives in DVS in land, chuckle!! 18:21:45 lol 18:22:11 SumitNaiksatam: if only I had a nickel for everytime I mis-typed GBP and BGP 18:22:18 so anyone, just wanted to say that i am slowed up on that front 18:22:19 too many TLAs 18:22:24 tbachman: lol! 18:22:49 ;) 18:23:19 so the other thing about sycing up with the master, i am only doing things that will get the UTs and integration tests to pass 18:23:35 SumitNaiksatam: Let me know if I can help (although I’ll be on PTO next week) 18:23:39 i anticipate that we will have to add follow up patches to incorporate some of the newer “features" 18:23:54 rkukura: yes sure, will definitely ping you when you are available 18:24:07 rkukura: thanks for the update on packaging 18:24:12 np 18:24:32 #topic Design Specs 18:24:50 QoS #link https://review.openstack.org/#/c/275358/ 18:24:53 igordcard: hi 18:25:25 i noticed igordcard posted an update on the spec 18:25:54 not sure if folks got a chance to take a look 18:26:10 if not we can spend a couple of mins reading this section: 18:26:12 #link https://review.openstack.org/#/c/275358/3/specs/mitaka/initial-qos-support.rst 18:26:15 its short 18:26:30 i meant “REST API impact” section 18:26:33 SumitNaiksatam, hi 18:26:44 igordcard: ah you are back 18:26:51 thanks for the updated spec 18:27:03 SumitNaiksatam, yes I'm here but I'm splitting my attention, unfortunately 18:27:13 igordcard: np 18:27:37 igordcard: so i am leaning towards an abstracted resource definition for QoS in GBP 18:27:45 what does the rest of the team think? 18:29:08 SumitNaiksatam: I think that makes sense 18:29:14 rkukura: okay 18:29:49 any one else have thoughts on this please comment on the review 18:30:17 SumitNaiksatam: will do 18:30:18 igordcard: could you provide a strawman of what the abstracted QoS definition would look like in this spec? 18:30:22 ivar-lazzaro: thanks 18:30:30 QoS was one of the actions we had from the start, will go through and post my comments 18:30:37 hemanthravi: ok thanks 18:30:45 SumitNaiksatam, yes I'll come up with something 18:30:51 igordcard: great thanks! 18:30:59 SumitNaiksatam, can you leave a comment on the spec with the abstract resource idea? 18:31:06 igordcard: ok 18:32:04 next one, “NFP” #link # https://review.openstack.org/#/c/239743 (we have a new TLA ;-) _ 18:32:17 SumitNaiksatam: ;) 18:32:32 hemanthravi: thanks for posting the update 18:32:51 hemanthravi: but i dont think the team would have had a change to go through your latest rev 18:32:55 *chance 18:33:16 update has most of the structure and the apis, would like to get comments on this once they have a chance to review 18:33:41 i had some comments (probably the same as what i had communicated offline) but i did not get a chance to note them 18:34:06 hemanthravi: is this spec complete at your end, or is it still WIP? 18:34:09 SumitNaiksatam:addressed some of them in the updated one, will respond to the other 18:34:37 hemanthravi: specifically my question in the context of the API definition and data model 18:34:54 some of the api's might change, but i think it'c complete enough to get reviews 18:35:33 hemanthravi: okay 18:35:38 hemanthravi: what is NSD? 18:35:58 network service device 18:36:09 for eg a vm that renders the service 18:36:31 i'll add the description in the spec, if it's missing 18:36:33 hemanthravi: okay, i see that you have it defined, sorry did not find that earlier 18:37:03 addressed that from the last set of comments 18:37:44 any questions for hemanthravi at this point? 18:38:04 there was an offline meeting to discuss some of this context, at which most of this team was present 18:38:35 hemanthravi: assignees - “Rukhsana Ansari (rukansari)” still valid? 18:38:55 i'll change that 18:39:25 after i check with her 18:39:38 hemanthravi: thanks 18:39:47 it will be great to have her contribute 18:39:48 after everyone had a chance to review, we could do another hangout if reqd 18:39:59 SumitNaiksatam:yes 18:40:02 hemanthravi: does “network_service_healthmonitor” have anything to do with the lbaas healthmonitor or is it an independent definition? 18:40:19 this is independent of lb 18:40:48 hemanthravi: okay 18:40:55 and will apply to any type of service, the impl abstracted by a driver 18:41:21 hemanthravi: okay, the status will be something binary, like UP or DOWN? 18:41:31 yes 18:41:36 i can check later if its defined in the spec somewhere 18:41:39 hemanthravi: okay thanks 18:42:03 requesting everyone in the team to take a look at this revised version of the spec 18:42:30 hemanthravi: should we expect to see WIP implementation patches while we are discussing this spec? 18:43:08 SumitNaiksatam:yes, magesh, ahmed should be submitting patches soon 18:43:48 hemanthravi: okay great, thanks for the update and looking forward to the patches as well 18:43:50 will go in parallel for some time 18:44:00 hemanthravi: cool 18:44:10 #topic Open Discussion 18:44:46 last week rkukura brought up the topic of Austin Summit submissions 18:45:35 some of use submitted this: 18:45:42 #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/6894 18:45:48 as a hands on session 18:46:00 please vote 18:46:13 anyone submit anything else specific to GBP? 18:46:40 https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/8724 18:46:47 vote on this one too 18:47:24 hemanthravi: thanks 18:47:38 few more below 18:47:39 https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/7359 18:47:58 https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/8595 18:48:10 from a GBP based cloud deployer 18:48:46 anything else to discuss today? 18:49:12 * tbachman wonders if his IRC client is stuck 18:49:35 tbachman: we see you 18:49:51 if nothing else, we can wrap up for today! 18:49:55 thanks all for joining 18:49:57 bye! 18:50:01 bye! 18:50:01 thanks SumitNaiksatam! 18:50:03 #endmeeting