17:00:47 <LouisF> #startmeeting service_chaining
17:00:52 <vks1_> Hi all
17:00:53 <openstack> Meeting started Thu Jun  8 17:00:47 2017 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:57 <openstack> The meeting name has been set to 'service_chaining'
17:00:59 <LouisF> vks1_: hi
17:01:07 <bcafarel> hello
17:01:11 <igordcard> hi all
17:01:14 <LouisF> bcafarel: hi
17:01:18 <LouisF> igordcard: hi
17:01:18 <pcarver> hi
17:01:22 <LouisF> pcarver: hi
17:01:35 <LouisF> #topic agenda
17:02:01 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
17:02:09 <LouisF> doonhammer: hi
17:02:25 <LouisF> aby items to add?
17:02:31 <LouisF> any
17:02:43 <igordcard> pcarver: awesome commit message :p
17:02:57 <pcarver> igordcard: thanks, I think
17:03:42 <bcafarel> quick item: igordcard added a project-config review to get the bot in #networking-sfc
17:03:43 <LouisF> +1
17:03:57 <bcafarel> most of you should already be in the review list I think
17:04:13 <LouisF> https://review.openstack.org/#/c/472282
17:05:03 <LouisF> #topic CLI
17:05:04 <LouisF> https://review.openstack.org/#/c/409759/
17:05:35 <LouisF> mohan has posted a new patch
17:05:47 <igordcard> I'll review soon hopefully
17:05:57 <LouisF> igordcard: thanks
17:06:22 <LouisF> #topic API reference
17:06:37 <LouisF> pcarver: thanks for update
17:07:00 <pcarver> LouisF: Yeah, this is just excruciating
17:07:18 <pcarver> I have to trace back the chain of imports and figure out what can be done differently.
17:07:42 <pcarver> We can't keep the networking-sfc or neutron.api imports in neutron-lib
17:08:53 <LouisF> pcarver: did neutron-lib folks have any suggestions?
17:09:00 <igordcard> pcarver: the big dependencies are the ones in sfc.py and flowclassifier.py right?
17:09:13 <pcarver> LouisF: I haven't asked yet. Way to many meetings internal to AT&T.
17:09:39 <pcarver> I think the only networking-sfc import is for the i18n translations of exception messages
17:10:07 <pcarver> I don't really know the details of how translations work, but I assume the translations can be moved from networking-sfc's i18n to neutron-lib's i18n
17:10:08 <igordcard> pcarver: oops, wrong files
17:10:38 <igordcard> pcarver: I just wanted to mention neutron_lib/api/definitions/flowclassifier.py
17:10:39 <pcarver> The neutron imports have to do with the API extension mechanism
17:11:09 <pcarver> igordcard: yes, flowclassifier imports from neutron.api and neutron.api.v2
17:11:32 <igordcard> pcarver: the i18n thing doesn't seem to be used in the extension file though..
17:11:49 <pcarver> one of the imported functions is pretty trivial, but the other depends on yet other imports
17:12:06 <igordcard> and the import of extensions should come from neutron-lib I expect?
17:12:32 <igordcard> pcarver: looking at ExtensionDescriptor
17:12:35 <pcarver> igordcard: the i18n import is the _ used on all of the text of the exceptions
17:12:53 <vks1_> pcarver:i18n Shud not be issue in neutron-lib
17:13:06 <igordcard> pcarver: oh yes
17:13:10 <pcarver> I assume I can use the equivalent function in neutron-lib but need to figure out if I also need to relocate translated message text from somewhere.
17:13:26 <vks1_> I think we are moving for fwaas
17:13:43 <igordcard> pcarver: ExtensionDescriptor will come from here https://github.com/openstack/neutron-lib/blob/ae5efb1ee47d0868e25caee4e0aaf1c857ec9eaa/neutron_lib/api/extensions.py
17:14:05 <igordcard> pcarver: pcarver i18n from here https://github.com/openstack/neutron-lib/blob/master/neutron_lib/_i18n.py
17:14:07 <pcarver> igordcard: thanks. I just haven't had time to go looking for it
17:14:11 <igordcard> pcarver: messages stay in the api def
17:15:13 <pcarver> igordcard: I know the English messages remain in the exceptions in neutron-lib, but if I just switch to the neutron_lib/_i18n.py will it find the other language translations?
17:15:50 <bcafarel> in neutron translated messages are in locale/ so is it just that we do not have other translations for now?
17:15:59 <igordcard> pcarver: just a moment, I've never seen where the other languages are stored
17:16:04 <pcarver> I haven't looked to find out where the other language message strings are stored or whether the logic in neutron-lib's i18n is identical to what's in networking-sfc
17:16:28 <pcarver> bcafarel: I don't know. I just haven't had time to go tracking it down yet.
17:16:51 <pcarver> I don't know why networking-sfc implemented its own i18n module, but I'm defaulting to assuming there was some reason
17:17:22 <pcarver> otherwise I would think it would have just imported i18n from upstream rather than implementing a module in networking-sfc
17:17:50 <LouisF> is it possible to get rid od the networking-sfc i18n?
17:18:09 <pcarver> LouisF: that's what I haven't had time to figure out yet.
17:18:24 <igordcard> bcafarel: pcarver: so it should be as easy as having the default english + i18n import in neutron-lib, and then openstack/networking-sfc will store the remaining messages right?
17:18:31 <pcarver> I assume there was some reason why that module exists in networking-sfc rather than being imported from elsewhere
17:18:36 <bcafarel> https://wiki.openstack.org/wiki/Translations#Internationalization_.28i18n.29 <- yep the locale/ path seems pretty standard
17:18:56 <bcafarel> igordcard: looks like so indeed
17:18:56 <pcarver> but I haven't read through the implementation to figure out what, if anything, it does that justifies its existence
17:19:21 <igordcard> LouisF: shouldn't be too hard
17:19:26 <igordcard> https://github.com/openstack/neutron-lib/blob/master/neutron_lib/_i18n.py
17:19:26 <pcarver> if it's really just copy/paste code and doesn't need to exist then I will definitely remove it and just use neutron-lib's implementation
17:19:36 <vks1_> +1
17:19:38 <igordcard> https://github.com/openstack/networking-sfc/blob/master/networking_sfc/_i18n.py
17:19:59 <pcarver> but I want to compare them before assuming that the networking-sfc one doesn't do anything unique
17:20:00 <LouisF> pcarver: +1
17:20:33 <pcarver> I assume that if it were 100% generic then it shouldn't have been implemented in networking-sfc in the first place
17:20:45 <LouisF> pcarver: not sure  why it  was
17:20:56 <bcafarel> apparently it's the recommended way: https://docs.openstack.org/developer/oslo.i18n/usage.html
17:20:57 <pcarver> So, I'm thinking there's probably at least something it does that might need to be migrated
17:21:07 <bcafarel> so the domain is set in each project
17:22:03 <vks1_> What possibly can break if neutron-lib's i18n gets used?
17:22:20 <pcarver> bcafarel: I need time to read the docs, but assuming that "domain" has something to do with how it finds the language strings to replace with other language strings, then that's what I meant about seeing if there are translation string files that need to be moved
17:22:54 <pcarver> vks1_: most likely won't break, but I'm thinking maybe it won't find the text strings needed to translate the messages
17:23:35 <pcarver> I know practically nothing about i18n, so I just need to read docs and figure out how it all works to make sure I don't break it
17:23:46 <LouisF> pcarver: what is behavior if text strings are not found?
17:24:17 <pcarver> LouisF: I'm guessing it probably just displays English messages, but again, I know practically nothing about i18n
17:24:40 <LouisF> pcarver: ok
17:24:46 <pcarver> I'm American so I assume everybody is fine with 7 bit ASCII in English :-)
17:25:11 <pcarver> I have no experience with running software in non-English languages
17:25:16 <vks1_> Doug can clarify
17:25:26 <bcafarel> pcarver: domain is mostly for the locale file name, so yes you should be fine just using neutron-lib module (so generated translation files will end up properly in neutron-lib)
17:27:08 <LouisF> moving on
17:27:14 <LouisF> #topic Tap SF
17:27:26 <LouisF> vks1_: what is status?
17:28:07 <vks1_> LouisF hv added notes in doc. Need reviews
17:28:21 <LouisF> vks1_: thanks for the update to the Tap spec https://review.openstack.org/#/c/471725/
17:28:37 <LouisF> vks1_: added some comments
17:28:46 <bcafarel> I should have time tomorrow to finally take a look at these (hopefully)
17:28:59 <vks1_> All please review
17:29:33 <vks1_> Also I have to add UTs for agent
17:29:50 <LouisF> vks1_: thanks
17:29:53 <vks1_> bcafarel thnx
17:30:37 <igordcard> I might take a bit longer to review..
17:31:02 <bcafarel> igordcard: stop sleeping, you could do reviews and write code instead!
17:31:17 <igordcard> bcafarel: genius
17:31:35 <LouisF> #topic SF Graph
17:31:46 <LouisF> igordcard: status?
17:31:59 <igordcard> the 3 patches are essentially finished
17:32:07 <igordcard> but I have to do actual manual testing
17:32:34 <igordcard> so at the moment I'm making the cli for service graphs so I can easily test them and fix anything along the way
17:32:46 <igordcard> but I don't expect the code to change much at this point
17:33:07 <LouisF> igordcard: ok thanks - will  review
17:33:35 <igordcard> documentation will come later
17:33:52 <LouisF> igordcard: ok
17:33:55 <igordcard> heat support and OSC will also come later, probably someone else from my side will do those 2
17:34:25 <LouisF> igordcard: ok
17:34:38 <LouisF> #topic OVN work
17:34:51 <LouisF> doonhammer: how is the OVN SFC work?
17:36:11 <LouisF> moving on
17:36:13 <doonhammer> I have been sucked into getting ready for our annual user conference - but that has involved building demos for containers and sfc
17:36:15 <bcafarel> some recent comments ovs-dev (like 20 min ago) for the ovs part
17:36:29 <doonhammer> I need to get a patch sumbitted asap
17:36:32 <LouisF> doonhammer: ok
17:36:43 <doonhammer> I will be free after tomorrow
17:37:16 <LouisF> doonhammer: ok thanks
17:38:07 <LouisF> #topic other items
17:39:12 <LouisF> support for legacy SF using the SFC proxy is seen as useful
17:39:34 <LouisF> in particular non-transparent SF
17:39:48 <LouisF> we added support for that
17:40:07 <igordcard> LouisF: and what about L2 insertion modes?
17:40:11 <igordcard> LouisF: without mac rewrites
17:40:37 <LouisF> igordcard: can you elaborate?
17:40:50 <vks1_> I guess we discussed we will add that
17:41:00 <vks1_> After tap
17:41:01 <igordcard> LouisF: just being able to push frames into a VM, with the VM running its interfaces in promiscuous mode
17:41:19 <igordcard> LouisF: and running e.g. an OVS instance inside that VM, to do multiple networking functions
17:41:20 <vks1_> insertion-mode support
17:42:39 <LouisF> igordcard: are you thinking of containers inside a VM?
17:43:11 <igordcard> LouisF: not necessarily, just simply VMs in promiscuous mode
17:43:35 <igordcard> LouisF: right now (without nsh) it still looks like packets are routed to the VM
17:43:48 <igordcard> LouisF: instead of "switched" to the VM
17:43:59 <vks1_> LouisF: It's a L2 mode insertion
17:44:05 <igordcard> vks1_: yeah
17:44:10 <LouisF> igordcard: so how would a promiscous VM affect current port-chain OVS  operation
17:44:24 <vks1_> We have in ML
17:45:34 <igordcard> LouisF: I might have to investigate that a bit more, there might be some loss of information that makes the steering ambiguous (if we don't match on the mac addresses inserted by the groups anymore)
17:45:48 <igordcard> LouisF: particularly in multi node
17:46:25 <LouisF> igordcard: can you maybe put ideas into a BP?
17:46:33 <igordcard> LouisF: but basically, everything regarding writing or matching on mac addresses would disappear
17:47:04 <LouisF> igordcard: nsh would achieve that right?
17:47:28 <igordcard> LouisF: I can but will take a long time, as I have to finish on my current tasks..
17:47:44 <igordcard> LouisF: yeah NSH makes insertion modes irrelevant
17:48:22 <igordcard> LouisF: L2 insertion mode would be simply an increase in the scope of legacy service chaining achieved by networking-sfc
17:48:58 <igordcard> LouisF: so I was just wondering what was the interest around that, I personally don't have any interest
17:49:37 <LouisF> igordcard: vks1_ is looking at that
17:49:59 <LouisF> igordcard: however, regarding non-transparent SF, I have added a new BP that outlines a scheme mapping SFC to SF instances
17:50:11 <LouisF> https://blueprints.launchpad.net/networking-sfc/+spec/sfc-proxy-port-correlation
17:50:43 <igordcard> LouisF: thanks, yes I still have to review what has been done so far around that
17:51:12 <LouisF> this avoids need for re-classification of packets from SG egress port
17:52:06 <LouisF> ok, other items?
17:52:21 <igordcard> call for presentations at the summit is now open
17:52:49 <igordcard> and since bcafarel's adoption of the ovs l2 agent extension, kolla can't deploy networking-sfc...
17:53:11 <igordcard> there's someone working to fix that though, and correctly deploy networking-sfc with ovs
17:53:29 <LouisF> igordcard: who is working on that?
17:54:08 <igordcard> a person from my team, I'll send the review link when there's something up
17:54:22 <LouisF> igordcard: thanks
17:54:31 <bcafarel> I think I saw some discussion on containerization of neutron agents (and related modules)
17:54:44 <bcafarel> igordcard: I think I will find it interesting :)
17:54:59 <LouisF> bcafarel: +1
17:55:40 <LouisF> all i have for  now
17:55:59 <LouisF> btw, i will be way for next two weeks
17:56:27 <LouisF> cathy will run the meetings
17:56:59 <LouisF> thanks all
17:57:02 <LouisF> bye
17:57:03 <igordcard> LouisF: alright!
17:57:04 <igordcard> bye
17:57:08 <bcafarel> ok, see you later
17:57:14 <LouisF> #endmeeting