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