17:01:09 <LouisF> #startmeeting service_chaining 17:01:09 <openstack> Meeting started Thu Jul 28 17:01:09 2016 UTC and is due to finish in 60 minutes. The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:12 <openstack> The meeting name has been set to 'service_chaining' 17:01:22 <LouisF> hi all 17:01:24 <pcarver> hi 17:01:28 <igordcard> hi 17:01:33 <Bali_Bao> Hi 17:01:39 <bcafarel> hello 17:01:42 <doonhammer> hi 17:01:54 <mohankumar> Hi 17:02:18 <yamahata> hello 17:02:35 <LouisF> meeting agenda:https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#.5BProposed.5D_Agenda_for_the_Networking-SFC_Meeting_.287.2F28.2F2016.29 17:03:19 <LouisF> #topic move to Openstack Client (OSC) 17:03:34 <mohankumar> LouisF , some plugin support in neutronclinet repo and in-progress https://review.openstack.org/#/c/348097/1 , we have to wait still all the supporting changes are get in , as of now the osc sfc plugin is done and able to register our clis . 17:03:38 <LouisF> mohankumar: what is status? 17:04:09 <LouisF> mohankumar: thanks 17:04:39 <LouisF> mohankumar: what changes are you refering to? 17:04:51 <mohankumar> https://review.openstack.org/#/c/348097/1 17:05:39 <LouisF> mohankumar: ok thanks 17:06:17 <LouisF> #topic Tacker driver integration 17:06:54 <LouisF> looks like stephen is not on will come back to that 17:07:29 <LouisF> #topic api reference 17:07:40 <LouisF> that was merged 17:08:03 <pcarver> Is publishing enabled or is that another step? 17:08:09 <LouisF> pcarver: were you able to generate the html files? 17:08:18 <pcarver> LouisF: no, no luck 17:08:29 <LouisF> pcarver: that would be another step 17:08:32 <pcarver> tox gives errors on multiple machines 17:09:00 <LouisF> pcarver: i think you need to make chnages to tox.ini 17:09:02 <pcarver> maybe I'm missing some pre-req installation but I don't know what 17:09:45 <pcarver> LouisF: do you mean the tox.ini in the repo or is there a separate local one that I need to manually setup? 17:10:12 <LouisF> in the repo 17:10:26 <LouisF> should work 17:10:53 <pcarver> well I'm cloning the repo from Gerrit, so I should have what you have in the commit. 17:11:29 <pcarver> There must be some outside dependency that explains why you get success and I get failure. Maybe a version issue or some pre-req package missing or something 17:12:06 <LouisF> pcarver: i will check the prcoedure i used 17:12:47 <pcarver> and it's got to be something that Devstack doesn't setup either because one of the machines I tried on was a fresh install of Ubuntu 14.04.3 on which I had run stack.sh with the line in local.conf to pull in and install networking-sfc 17:12:47 <LouisF> pcarver: i will email you 17:12:52 <pcarver> Thanks 17:13:09 <LouisF> #topic port-pair group parameter 17:13:23 <pcarver> wait, on the API docs topic 17:13:34 <LouisF> pcarver: go ahead 17:13:49 <pcarver> Do we know what is needed in the infra repo to enable API docs publishing or is that still an unknown? 17:14:21 <pcarver> we need to get the output onto api.openstack.org 17:14:22 <LouisF> pcarver: i am looking into that 17:14:46 <pcarver> I've looked too and haven't found clear instructions 17:14:53 <LouisF> the neutron api docs are going to land in neutron-lib 17:15:16 <pcarver> There seem to be bits and pieces, but not the full picture 17:15:27 <LouisF> there is conversion work in progress 17:15:58 <LouisF> pcarver: armando will let us know when that is complete 17:16:24 <pcarver> ok 17:16:57 <LouisF> back to port-pair-group parameter; i done see george wang on 17:17:10 <LouisF> i will contact him for progress 17:17:31 <LouisF> #topic tempest tests 17:18:13 <LouisF> there is a patch in review for tempest testing 17:18:15 <LouisF> https://review.openstack.org/#/c/321870/ 17:18:31 <LouisF> please review 17:19:39 <mohankumar> LouisF , gate job failures are because of this ? 17:19:58 <mohankumar> gate-tempest-dsvm-networking-sfc-nv 17:20:13 <LouisF> mohankumar: right - i don't think so 17:20:32 <LouisF> mohankumar: its another issue 17:20:52 <mohankumar> LouisF , ok , i ll check .. i ve failures still in this patch set changes also 17:21:11 <LouisF> mohankumar: ok thanks 17:21:14 <s3wong> hello... sorry, late... 17:21:22 <LouisF> s3wong: hi 17:21:53 <LouisF> s3wong: what is status on the tacker / networking-sfc driver? 17:23:16 <s3wong> LouisF: patches are out 17:23:25 <LouisF> do you have a link? 17:23:48 <s3wong> LouisF: https://review.openstack.org/#/c/347563/ 17:23:59 <s3wong> and https://review.openstack.org/#/c/347568/ 17:24:09 <s3wong> the second one (really) is WIP at this point 17:24:28 <s3wong> LouisF: will put you in as reviewer also 17:24:52 <LouisF> s3wong: ok thanks 17:25:21 <mohankumar> LouisF, s3wong : i've an question about tacker . do we have duplicate effort by working heat and tacker in my understanding both are orchestration services to enable sfc right . 17:25:21 <mohankumar> s3wong: is there any difference/ advantage in tacker ? 17:25:33 <LouisF> s3wong: can you set workflow to -1 17:25:56 <s3wong> mohankumar: Tacker has a VNFM in place 17:26:11 <s3wong> mohankumar: which allows for config and monitoring driver 17:26:41 <s3wong> mohankumar: also, for Tacker, we really aren't just doing SFC, we are providing an implementation of VNFFG (forwarding graph) 17:26:44 <s3wong> LouisF: will do 17:27:05 <mohankumar> s3wong : okay thanks , have to read more :) 17:27:18 <s3wong> LouisF: done :-) 17:27:26 <s3wong> mohankumar: it is really quite fasinat 17:27:41 <LouisF> mohankumar: this is useful for networking-sfc as it provides another way to test and evaluate the api 17:27:49 <s3wong> fascinating what one can do on top of networking-sfc API 17:27:51 <LouisF> s3wong: thanks 17:28:00 <mohankumar> s3wong , LouisF: agree 17:28:55 <LouisF> #topic sfc agent naming issue 17:29:07 <LouisF> https://review.openstack.org/334398 17:29:37 <LouisF> fsunaval: you are looking into this 17:29:40 <fsunaval> I have something working. I will send out diffs tomorrow.... A rewrite is not necessary. 17:29:58 <LouisF> fsunaval: great 17:29:59 <fsunaval> But I have modified some core neutron files. Will need to see what the neutron folks say about the change. 17:30:39 <LouisF> fsunaval: ok thanks 17:30:51 <fsunaval> Will send out the diffs for internal review today and if all goes well send it out for external review tomorrow. 17:30:59 <LouisF> fsunaval: ok 17:32:16 <LouisF> #topic networking-sfc / OVN driver 17:32:30 <LouisF> there is a patch https://review.openstack.org/333172 17:33:18 <LouisF> there were some comments from Na Zhu - not sure they all got answered? 17:33:39 <LouisF> is Na Zhu on? 17:34:24 <doonhammer> Louis: probably not very late in China 17:34:25 <LouisF> Bali_Bao: do you know if Na Zhu is ok with the latest patch? 17:34:49 <LouisF> doonhammer: ok i will email her 17:34:51 <Bali_Bao> not sure..sorry 17:35:11 <LouisF> anyway please review 17:35:58 <LouisF> next topic is bug scrub. before that any other topics to discuss? 17:36:31 <mohankumar> LouisF,pcarver: there are patches correct minor nit(s) , fixing typos waiting for workflow approval , could you please review :) 17:36:50 <LouisF> mohankumar: can provide links 17:36:55 <igordcard> LouisF: I've submitted an early patch for the refactoring work around bringing SFP mgmt/gen to the SFC plugin 17:37:03 <mohankumar> https://review.openstack.org/#/c/338874/ 17:37:12 <mohankumar> https://review.openstack.org/#/c/337577/ 17:37:16 <igordcard> #link https://review.openstack.org/#/c/346175/ 17:37:22 <LouisF> all please review these 17:37:54 <igordcard> I will soon start working on the nsh patch using that one as a dependency, while still improving it 17:38:12 <igordcard> there is one thing I would like to raise here about the refactoring patch 17:38:19 <LouisF> igordcard: do those changes pass the unit tests? 17:38:36 <LouisF> igordcard: go ahead 17:38:37 <igordcard> LouisF: no, it's still a WIP and I will address the unit tests later 17:38:46 <LouisF> igordcard: ok 17:38:48 <igordcard> it works though, but no unit tests yet 17:39:12 <LouisF> igordcard: need the unit tests also 17:39:44 <igordcard> so because I have split the models that were mostly managed by the OVS driver, into abstract models managed by the plugin and specific models managed by the OVS driver, there is now more dependency in the order to the CRUD methods need to take place 17:40:01 <igordcard> especiall, when updating a port chain 17:40:18 <LouisF> igordcard: elaborate 17:40:36 <igordcard> there is no pre/post-commit-like interface with the SFC drivers, which makes it difficult to carry out the update port chain method correctly 17:41:56 <igordcard> the order for the update method should be: 1. tell OVS to undo previous chain and remove specific resources 2. remove old abstract resources 3. create new abstract resources 4. tell OVS to create new chain and generate new specific resources 17:42:39 <mohankumar> igordcard : agree 17:43:06 <LouisF> igordcard: are you refering to inserting/removing a PPG in the port chain? 17:43:08 <igordcard> we can discuss this in more detail in the patch that I've submitted, just wanted to raise the issue here... as such the update method is not yet working on the patch that I submitted 17:43:14 <igordcard> LouisF: for example 17:44:06 <LouisF> igordcard: how is the crud order significant? 17:45:05 <igordcard> LouisF: the OVS driver will not know what flows to generate until the abstract resources have been updated by the plugin... but the plugin cannot update them before telling the OVS driver to clean - or the old ones will be left dangling 17:45:37 <igordcard> another alternative is to force a full refresh in the OVS driver, but I couldn't find that functionality today.. I believe networking-sfc used to have that in the past 17:47:06 <LouisF> igordcard: a port chain update operation has both the previous PPG list and new PPG list 17:47:16 <igordcard> or every old resource can be hard copied and then sent to the driver so it can clean the old ones... which may entail changing the driver's interface 17:47:54 <igordcard> or the update port chain can simply call delete port chain and the create port chain, there are different alternatives but I prefer to have your feedback before implementing the update-port-chain 17:49:07 <LouisF> igordcard: the current implementation is the delete the port chain with old ppgs then create a new port chain 17:49:29 <LouisF> igordcard: i would have to check where that is done in the code 17:49:31 <igordcard> LouisF: yes but that is done inside the driver's update method... the plugin simply delegates all logic to the driver 17:50:18 <igordcard> but I will investigate a bit more in regards to the ppgs diff... there's also the fact that the other flow classifiers can be given 17:50:25 <LouisF> igordcard: different drivers may have differing implementations 17:50:59 <LouisF> igordcard: correct, port chain update may also chnage the flow classifiers 17:51:18 <igordcard> LouisF: right, but I'm attempting to abstract what should be common to all drivers (which essentially is nsp+nsi and the list of path nodes [without technical details]) 17:52:03 <LouisF> igordcard: agree the nsp generation should be common 17:52:44 <igordcard> here's what I'm gonna do, I'll leave some comments in my own patch so you can follow the reasoning here (instead of polluting it with python comments) and we can continue from there, sounds good? 17:53:04 <igordcard> I mean, gerrit comments 17:53:05 <LouisF> igordcard: ok 17:53:22 <mohankumar> LouisF,pcarver : Please check these patches also., (correct minor nit(s) , fixing typos) 17:53:22 <mohankumar> https://review.openstack.org/#/c/339911/ 17:53:22 <mohankumar> https://review.openstack.org/#/c/341310/ 17:53:22 <mohankumar> https://review.openstack.org/#/c/341293/ 17:53:22 <mohankumar> https://review.openstack.org/#/c/323783/ 17:53:22 <mohankumar> https://review.openstack.org/#/c/343402/ 17:53:24 <mohankumar> https://review.openstack.org/#/c/325838/ 17:53:26 <mohankumar> https://review.openstack.org/#/c/335717/ 17:53:59 <LouisF> mohankumar: thanks 17:54:16 <LouisF> all - please review these 17:54:22 <pcarver> ok 17:55:15 <s3wong> mohankumar: yikes, patches from OpenStack Proposal Bot 17:55:47 <s3wong> mohankumar: we have two +2s, why not just merge? 17:56:17 <mohankumar> s3wong: have to set workflow +1 , just want to make sure all are ok 17:56:58 <s3wong> mohankumar: well, both you and vikram has +A rights, you guys can go ahead :-) 17:57:10 <s3wong> mohankumar: in our cores we trust :-) 17:57:18 <LouisF> mohankumar: lets +1 on workflow 17:57:22 <mohankumar> s3wong : ;) 17:57:38 <mohankumar> LouisF : ok 17:57:52 <Bali_Bao> LouiseF: as the OVN SFC driver, I had a comment before that to update the lchain-add, you said you want to change to lchain-add lswitch lport-chain [lport-pair-group] ..., but it still lchain-add lport-chain [lport-pair-group] .. so do we need the l2switch in it? 17:57:53 <pcarver> yeah, no need for deep analysis of proposal bot reviews 17:58:14 <LouisF> ok thats it for today 17:58:31 <LouisF> Bali_Bao: no 17:59:03 <LouisF> Bali_Bao: the intention is the lchains to span multiple lswitches 17:59:49 <LouisF> thanks all will bug scrub next week 17:59:56 <Bali_Bao> ok, got that, so we can support SFC across multiple networks, right? 18:00:04 <LouisF> Bali_Bao: yes 18:00:18 <LouisF> bye all 18:00:24 <LouisF> #endmeeting