18:01:55 #startmeeting networking_policy 18:01:56 Meeting started Thu Jul 16 18:01:55 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:00 The meeting name has been set to 'networking_policy' 18:02:07 hi 18:02:18 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#July_16th.2C_9th_2015 18:02:27 hi 18:02:31 try to get to some of the items we did not cover in last weeks agenda 18:02:33 Yi: hi 18:02:55 update on the kilo release - we are still working on it 18:04:14 we have users who are also testing this, so it would be good to incorporate their input and provide any major fixes before we release 18:04:37 #topic Bugs 18:05:05 its not a bug, but a criticial issue is that the GBP py27 gate is broken 18:05:30 this happened after there was an update to the global requirements yesterday 18:05:42 @SumitNaiksatam: which bug are you referring to? 18:05:49 i have patch to update our test-requirements (thanks mageshgv for your input): 18:06:03 #link https://review.openstack.org/202668 18:06:11 ransari: did not file it as a bug 18:06:24 since update of requirements is an ongoing process 18:06:47 @SumitNaiksatam ok 18:06:54 the patch has passed the py27 gate now, but waiting on the integration test 18:07:05 the upstream gate is pretty busy and backed up 18:07:06 SumitNaiksatam: I was just testing that patch now 18:07:10 igordcard: ah ok 18:07:13 igordcard: thanks 18:07:27 one thing to note is that with the new hacking requirements, pep8 was failing on our code 18:07:45 so i slyly reverted back to the earlier hacking version 18:08:09 in a separate patch we should update the hacking version, and fix those pep8 issues 18:08:45 requesting the team to keep a watch on the above patch and help merge when you see it pass the integration job 18:09:02 we cant merge other patches until that fix merges 18:09:18 i dont think we are tracking any other critical priority bugs this week 18:09:27 any other bugs anyone wants to bring up? 18:10:30 #link https://review.openstack.org/#/c/198052/ 18:10:31 okay so moving on 18:10:49 oh 18:11:13 We have Service Node configuration as updateable parameter in the spec, but in implementation it is different today 18:11:21 mageshgv: this is #link https://launchpad.net/bugs/1470866 18:11:21 Launchpad bug 1470866 in Group Based Policy "Service node config should be an updateable field" [High,Confirmed] - Assigned to Magesh GV (magesh-gv) 18:11:35 @SumitNaiksatam important because without this support, service node config requires disruptive re-deploy of the chain 18:11:48 mageshgv: ransari: okay 18:12:03 mageshgv: i provided some minor comments 18:12:25 other than that, i believe the ratinale is that if a driver cannot support an update it will throw an exception? 18:12:31 *rationale 18:12:34 @mageshv: you mentioned it needs to be updated ? 18:12:42 SumitNaiksatam: Thanks. Will post an updated patch once our py27 gets fixed 18:12:51 mageshgv: ok 18:13:10 SumitNaiksatam: yes, a driver that does not support update will reject it 18:14:07 just a general comment that in the specs we are using different conventions to describe our resrouces 18:14:21 in #link https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/group-based-policy-abstraction.rst 18:14:34 we have the resource map 18:14:54 but in #link https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/group-based-policy-service-chaining.rst 18:15:02 we use a tabular convention 18:15:09 confusing for the reader and also to track 18:15:24 in the later we use “W” to indicate both create and update 18:16:09 anyone have any objections with allowing support of config updates to instantiated nodes? 18:16:27 i am referring to #link https://review.openstack.org/#/c/198052/ 18:16:54 ok 18:17:01 any other bugs to discuss? 18:17:30 moving on 18:17:34 #topic Integration tests 18:17:39 just a quick update here: 18:18:09 in #link https://review.openstack.org/#/c/202263/ i am experimenting with adding rally tests 18:18:21 ideally this should not be a part of the same integration job 18:18:37 but we are already setting up devstack, so i will try and see how this behaves 18:19:13 the rally tests are being pulled from here: #link https://github.com/group-policy/rally/tree/dev 18:19:23 written by ajay (we had discussed this a few weeks back) 18:19:50 comments/questions? 18:20:17 #topic Packaging Update 18:20:31 rkukura: anything you want to update the team on? 18:20:47 nothing new this week 18:20:54 perhaps based on your earlier meeting today ;-) 18:21:29 I did meet with some Red Hat people today, but we didn’t really cover much specific to GBP 18:21:59 I think we can get momentum going again on that, though 18:22:14 rkukura: okay 18:22:24 #topic Docs 18:22:37 @rkukura: do we expect updated Juno rpms? 18:22:46 #undo 18:22:47 Removing item from minutes: 18:23:38 I still hope to do those, but have been spending way too much time trying to get the nova node driver to work right 18:24:28 rkukura: you can let the team know if we can help in any way on the rpms 18:24:50 @rkukura: thnaks 18:25:04 #topic Docs 18:25:12 so we have #link https://github.com/stackforge/group-based-policy/tree/master/doc/source 18:25:28 the way most other projects are using this is for “devref” 18:25:40 e.g.: in nova #link https://github.com/openstack/nova/commit/47b233f988bddd1272e4a1bc02be97f15701a8ca 18:26:01 we currenly have GBP overview here 18:26:23 it will help to have devref for things like writing node drivers for the new node composition plugin 18:26:34 just wanted to bring it to everyone’s attention 18:26:50 currently we are lacking sorely on good API documentation 18:27:02 and on good developer documentation 18:27:18 so if you have ideas on how do this, and/or want to contribute, please let me know 18:27:37 on a related note, we are also missing a python SDK for GBP 18:28:24 @umitNaiksatam I can help out 18:28:25 similar to #link https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK 18:28:33 ransari: that will be great 18:28:43 SumitNaiksatam: What is needed for a python SDK beyond python-gbpclient? 18:29:13 mainly docs? 18:29:46 rkukura: i agree one case use the client lib, but people like to have a more evolved library to work with 18:29:55 this was the feedback from a few uses 18:29:57 *users 18:30:05 and, yes, it is self documenting 18:30:09 so a layer above python-gbpclient? 18:30:13 rkukura: yeah 18:31:14 rkukura: python-openstacksdk has python bindings for most openstack projects (which were earlier part of the integrated release) 18:31:31 its not clear to me if this uses the python-*client libs, or is something different. Also, how is it related to the old OpenStack client effort? 18:31:51 rkukura: this would be different from the openstack client efforts 18:32:20 and my understanding is that it would use the client libs 18:33:13 #link https://github.com/stackforge/python-openstacksdk/tree/master/openstack 18:33:16 ok moving on 18:33:30 #topic Stable branches for clients 18:33:48 i checked with the folks in the team if they were okay with this idea 18:33:58 other projects are already doing it 18:34:15 most everyone seems to be in agreement 18:34:30 this will allow us to backport fixes 18:34:59 if there is no disagreement, i can go ahead and create stable client branches for juno and kilo 18:35:16 this does not affect the client version numbering 18:35:56 rkukura: should we use 1.0.x for stable/kilo? 18:36:37 SumitNaiksatam: I have not looked into how the other client library stable branches are being versioned, so I’m not sure 18:37:37 rkukura: i am mostly asking (and this is to the team in general), if we can transition to client version 1.0 (currently we are 0.9.x) 18:37:59 we dont have to decide now, but we will soon get to that point 18:38:17 I’d think so - we can always go to 2.x if/when we make incompatible changes 18:38:26 rkukura: yeah 18:38:34 @SumitNaiksatam: good to have back ports to juno client branch 18:39:09 Are there API changes in kilo/master that we have not and are not backporting to juno? 18:39:11 ransari: okay, we will update the minor version number to reflect that 18:39:43 rkukura: there at least a couple i think of 18:39:49 @rkukura: We haven't back ported service profile changes to juno based client 18:40:02 ransari: yes, that is one of those tow 18:40:07 *two 18:40:08 OK 18:40:24 the other one is with mageshgv’s patch we discussed earlier today 18:40:35 there is at least a third one - 18:41:08 @SumitNaiksatam: mageshv patch is not merged in Kilo 18:41:18 ransari: yes, but we expect it will 18:41:23 when creating or updating a group there is a provide and consume attribute 18:41:25 this is a dict 18:41:37 but the format of the dict is confusing to most users 18:41:39 @SumitNaiksatam: ok . 18:41:43 (the use of scope) 18:42:23 so we are planning to change that, though the change can be done in a backward compatible way (such that you can support the old format as well for one cycle of deprecation) 18:42:44 a fourth change would have been to rename external-policy to external-group 18:43:24 yes, use of scope is confusing 18:44:00 in general, rkukura per your question, this might be a good time to indentify (and perhaps the last chance) to introduce a changes to the API 18:44:31 right 18:45:07 so everyone please thing through, and if you have any issues with the current usage, please dont hesitate to raise them 18:45:43 #topic Node drivers 18:45:59 igordcard: any updates you want to share? 18:46:51 rkukura: anything at your end with the nova driver? 18:47:14 I’m kind of stuck with some weird lockup between neutron and nova 18:47:21 SumitNaiksatam: I am now more focused on TS than before, so you can expect news during this month 18:47:43 igordcard: thats great 18:47:51 rkukura: okay 18:48:20 Neutron stops accepting new requests, including those being made from nova. 18:48:34 the nova node driver would be helpful, but I will temporarily create a dummy node driver that receives port IDs already created, to automate debugging and development 18:48:44 Having neutron call nova in a separate thread does not seem to help 18:48:47 igordcard: okay 18:49:05 rkukura: ah, so the multiple api threads did not work, darn 18:49:19 that didn’t solve it either 18:49:48 rkukura: so in your opinion this is because the nova driver is running inside the neutron process space? 18:50:17 the actual POST call to nova seems to return the instance ID to neutron, but then novaclient tries to do a get on that ID, and nova within that does a get_port, which neutron doesn’t respond to. 18:50:35 SumitNaiksatam: I have no theory on why it shoudn’t work inside neutron 18:50:45 I’m probably doing something blatently wrong 18:51:18 rkukura: would it possible to post a WIP patch so folks in the team can look and perhaps provide some ideas? 18:51:49 Maybe - the little bit of code is a real mess - I’ve really just been experimenting with different approaches 18:52:29 rkukura: okay 18:52:34 mageshgv: there are a few references to “reference” as regards the older “simple chain driver”, we should remove those 18:52:38 I’ve got a couple more ideas to try, but will try to post something for others to look at if I don’t get it solved this week 18:52:46 rkukura: thanks 18:53:21 SumitNaiksatam: ok 18:53:50 i think Ivar had to leave for another meeting, so we will skip his patches (but please do review them) 18:53:56 #topic Open Discussion 18:54:17 the deadline for talk submissions to Tokyo was yesterday 18:54:35 Ivar has submitted a proposal for the hands-on lab 18:55:10 anything else anyone wants to discuss today? 18:55:28 or we can wrap up early today ;-P 18:55:52 alright, thanks everyone for attending! 18:56:02 bye! 18:56:07 thanks SumitNaiksatam! 18:56:08 bye 18:56:11 #endmeeting