18:01:06 <bh526r> #startmeeting gluon
18:01:07 <openstack> Meeting started Wed Feb  1 18:01:06 2017 UTC and is due to finish in 60 minutes.  The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:10 <openstack> The meeting name has been set to 'gluon'
18:01:16 <bh526r> #topic Roll Call
18:01:22 <bh526r> #info Bin Hu
18:01:30 <krenczewski> #info Kamil Renczewski
18:01:30 <bh526r> Hi guys
18:01:33 <krenczewski> Hello
18:01:35 <pcarver> #info Paul Carver
18:01:49 <bh526r> #topic Admin Update
18:02:35 <bh526r> #info Our next F2F is Monday Feb 6 and Tuesday Feb 7. The logistics information is:
18:02:43 <bh526r> #link https://wiki.openstack.org/wiki/Meetings/Gluon/Logistics-2017020607
18:02:54 <bh526r> #info Tentative agenda is:
18:03:08 <bh526r> #link https://wiki.openstack.org/wiki/Meetings/Gluon/Agenda-2017020607
18:03:28 <bh526r> #info Hope to see many of you there
18:03:49 <bh526r> #topic Gluon Tasks
18:03:51 <jinli> Hi all
18:03:55 <jinli> #info JinLi
18:04:17 <bh526r> #info The primary goal is to review the status of task completion.
18:04:29 <bh526r> #link https://wiki.openstack.org/wiki/Gluon/Tasks-Ocata
18:05:13 <bh526r> #info and decide/close actions
18:05:42 <bh526r> #topic Status Update
18:06:27 <bh526r> #info Synchronization Issues: (1) Between MySQL and etcd; (2) Bind operation with SDN controllers
18:06:49 <bh526r> #info We need to see how far we go when Ian attends the meeting next week
18:07:09 <bh526r> #info 2. OpenContrail's Mechanism Driver
18:07:24 <bh526r> #link https://review.openstack.org/#/c/402071/
18:07:42 <bh526r> Kamil, any update?
18:07:55 <krenczewski> I am still having some issues with my test environment
18:08:13 <krenczewski> It turns out that my first config was wrong
18:08:39 <bh526r> I see, hope that the issues will be addressed soon
18:08:43 <krenczewski> Szilard helped me with some network issues
18:08:59 <bh526r> #info Kamil is continuing on setting up test environment
18:09:16 <krenczewski> I think I am now close to finish this
18:09:18 <bh526r> Great that he helped
18:09:29 <bh526r> Excellent, thank you Kamil
18:09:41 <krenczewski> I'll let you know when I fix those
18:09:51 <bh526r> Sounds good
18:10:22 <bh526r> #info 3. Configuration files to replace hardcoded constants
18:10:54 <bh526r> #info we need to look through all code, and find those hardcoded constants first, and then put them into config files
18:11:19 <bh526r> #info 4. Testing
18:11:39 <bh526r> #link https://review.openstack.org/#/c/420165/
18:12:04 <bh526r> #info Darla re-tested the test code after we merged new code of new API model.
18:12:21 <bh526r> #info So this was approved and merged on Jan 27
18:12:33 <bh526r> #link https://review.openstack.org/#/c/419210/
18:12:49 <bh526r> #link https://review.openstack.org/#/c/422338/
18:13:18 <bh526r> Jin, did you have a chance to re-test those 2 test code based on most recent repo that merged new API code?
18:13:31 <jinli> I will need make some changes to these two
18:13:52 <jinli> will get it done by end and tomorrow and send you email to notify the change
18:14:09 <bh526r> Great, and thank you Jin
18:14:33 <bh526r> #info Jin will make some changes to those 2 test patches in order to support new API model
18:15:10 <bh526r> #info 5. Devstack Integration
18:15:24 <bh526r> #link https://review.openstack.org/#/c/404069/
18:15:48 <bh526r> #info We will see how far it goes at the f2f next week
18:16:16 <bh526r> #info 6. Use of “etcd” approved by infrastructure team
18:17:05 <bh526r> #info I (or Ian) will work with infrastructure team. But low priority for Ocata because of "unofficial" nature
18:17:24 <bh526r> #info 7. Fuel Plugin
18:17:39 <bh526r> #link https://review.openstack.org/#/c/417876/
18:18:04 <bh526r> #info Good progress. Szilard submitted patch 8 this morning.
18:18:19 <bh526r> #info All are encouraged to review and comment
18:18:51 <bh526r> #info 8. Nova enhancement and related Neutron work
18:19:43 <bh526r> #info this is another goal of F2F next week so as to lock down all details and Sukhdev will represent Gluon to work with Nova and Neutron in PTG in Atlanta
18:20:03 <bh526r> #info 9. Misc
18:20:53 <bh526r> #info Tom and Kamal have done great job in new API model, and RBAC. We also need to see if any house cleaning work needed for those 2 features
18:21:34 <bh526r> #info And I am working on user guide of how to develop Proton YAML
18:21:53 <bh526r> That's all from my side
18:22:11 <bh526r> any other update or issue from your side?
18:22:28 <pcarver> I have a design question
18:22:40 <bh526r> sure
18:23:01 <pcarver> does a port have to be owned by a single SDN controller?
18:23:49 <bh526r> Port is bound to one backend at one time
18:24:14 <bh526r> So at any moment, a port is owned by one SDN controller
18:24:18 <pcarver> So is something like Neutron's hierarchical port binding impossible?
18:24:45 <bh526r> But a port can be re-bound to another SDN controller at another time
18:24:52 <pcarver> I'm thinking of an SR-IOV use case where there may be different controllers managing the server side and switch side configuration
18:25:51 <pcarver> ML2 handles this by dispatching the port events to multiple drivers simultaneously
18:25:52 <bh526r> That is the service binding model, the hierarchy described in Georg's service binding mode patch and Tom's API spec patch
18:26:53 <bh526r> what does this "multiple drivers simultaneously" exactly mean?
18:27:13 <bh526r> A port is owned by multiple drivers simultaneously?
18:27:43 <pcarver> yes, for example the OvS driver and a physical switch driver is an example that has been done with Neutron
18:27:54 <bh526r> Then when VM sends the traffic to the port, will all of the drivers also handle the traffic simultaneously?
18:28:22 <pcarver> the drivers don't handle traffic but the things they configure do
18:29:22 <pcarver> So if the OvS driver configured OvS and the Arista driver configured an Arista switch then the traffic would pass through both OvS and the Arista switch.
18:29:53 <bh526r> In above example, will OVS driver and physical switch driver then be managed by one SDN controller?
18:29:57 <pcarver> The particular use case I'm thinking of is when we need to configure an SR-IOV virtual function (VF) and a physical switch.
18:30:21 <pcarver> Not in the Neutron hierarchical port binding case. The drivers are the controllers.
18:30:43 <bh526r> Can SR-IOV VF and physical switch be handled by SDN Controller simultaneously?
18:31:11 <pcarver> hypothetically they could, but the the software we're currently using can't
18:31:37 <bh526r> If yes, then the port is bound to one SDN controller which handles those drivers including SR-IOV VF and a physical switch
18:31:49 <pcarver> We're currently using one controller that only manages VFs and a different controller that only manages physical switches
18:34:14 <bh526r> I see. Refer to the service binding model patch:
18:34:18 <bh526r> https://review.openstack.org/#/c/400012/
18:35:15 <bh526r> In the first diagram, a port can have multiple interfaces. An interface can have multiple services
18:35:56 <pcarver> I've read that, but it doesn't appear to give enough info to bind to multiple controllers
18:40:04 <bh526r> So we need to define 2 service interfaces that subordinates of the port, and bind each service interface to one SDN controller respectively
18:41:04 <bh526r> Let me work offline to give an exemplary model description for you
18:41:09 <pcarver> ok
18:41:30 <bh526r> Very good question
18:41:38 <bh526r> Any other question?
18:43:06 <bh526r> If no other question, I will work offline with Paul for this model of multiple service interfaces
18:43:26 <bh526r> And we can adjourn the meeting, and give back everyone 17 minutes
18:43:36 <bh526r> #info Meeting Adjourned
18:43:48 <bh526r> Thank you everyone, and bye all
18:44:00 <bh526r> #endmeeting