05:02:06 <yamahata> #startmeeting servicevm-device-manager
05:02:07 <openstack> Meeting started Tue Oct 14 05:02:06 2014 UTC and is due to finish in 60 minutes.  The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:02:10 <openstack> The meeting name has been set to 'servicevm_device_manager'
05:02:28 <yamahata> #topic Announcement
05:02:51 <yamahata> #chair s3wong
05:02:52 <openstack> Current chairs: s3wong yamahata
05:03:04 <yamahata> #info Neutron RC2 was cut
05:03:15 <yamahata> #info Neutron spec for Kilo cycle is open now
05:03:27 <bmelande> hi yamahata:
05:03:40 <yamahata> bmelande: hi. glad to see you.
05:03:43 <s3wong> bmelande: hello
05:04:14 <yamahata> that's all from me. Any other announcement?
05:04:31 <bmelande> s3wong: Hi
05:06:25 <bmelande> yamahata: nothing from me either. Apologies for running behind on the reviews
05:07:15 <yamahata> bmelande:  no problem. What do you think the direction itself? The patch is implementation detail. How about the overall direction?
05:07:34 <yamahata> #topic Open Discussion
05:08:05 <bmelande> yamahata: overall looks good.
05:08:46 <bmelande> yamahata: have not seen brocade in these meetings for some time. Have you heard from Kartik?
05:08:57 <yamahata> Carl Brown is planning a blueprint for l3-agent refactoring. According to L3 service irc meeting log, he is going to publish a blueprint for it.
05:09:33 <s3wong> yamahata: Carl Brown? Not Carl Baldwin (carl_baldwin)?
05:09:34 <yamahata> Ideally router service handler of config agent can share codes with l3 agent.
05:09:52 <yamahata> s3wong: Oops. Carl Baldwin.
05:11:12 <yamahata> I'm also looking at l3 agent myself, so we'll see how to cooperate with him.
05:11:53 <yamahata> So far the blueprint doesn't published yet, though.
05:11:59 <bmelande> yamahata: Yes I saw that.
05:13:16 <bmelande> yamahata: one limitation of the l3 plugin and l3 agent is the implicit assumption that l3 agent is colocated with the host/device where the Neutron routers runs
05:14:43 <yamahata> bmelande: Sure. That's the fundamental difference and the reason why config agent was introduced, I understand. Correct?
05:14:53 <bmelande> yamahata: Yes
05:15:36 <bmelande> s3wong: What is the plan for K and your BP on service port?
05:16:06 <s3wong> bmelande: we plan to propose it --- and elicit more support from the advanced services
05:16:32 <yamahata> bmelande: I haven't heard from Kartik recently. Maybe we should ping him before summit for logistics.
05:17:00 <bmelande> yamahata: yes, would be good if he/they participated here.
05:17:04 <s3wong> bmelande: I am going to meet with some folks this Thursday to talk about how to get community support during the K-Summit
05:17:59 <yamahata> any link to service port?
05:18:06 <bmelande> s3wong: Perhaps you saw that a patch from McClain was merged a few days ago that adds a router port table to the router inmplemenation
05:18:19 <yamahata> #action yamahata try to contact Kartik or brocade people
05:18:20 <bmelande> s3wong: Yes I heard about that from SridarK
05:18:32 <s3wong> bmelande: no, actually I didn't...
05:19:04 <bmelande> s3wong: that routerport construct in ways has similarities with the service port construct
05:19:44 <s3wong> bmelande: it is specific to router? so we now have another table for router interfaces?
05:20:23 <bmelande> s3wong: Yes it is specific to the router. Yes, there is now a table for it.
05:20:52 <s3wong> bmelande: Kanzhe and I built the table as a result of API support
05:21:27 <yamahata> This one? http://git.openstack.org/cgit/openstack/neutron/commit/?id=93012915a3445a8ac8a0b30b702df30febbbb728
05:21:34 <s3wong> bmelande: as we implemented at the feature freeze day, we tried hard to figure out how to go from service port table to reference back to the actual service
05:21:39 <yamahata> "Add database relationship between router and ports"
05:22:05 <s3wong> bmelande: but I guess if you KNOW you are a router interface, you can always just reference to the router table...
05:22:17 <bmelande> yamahata: That is the one.
05:23:28 <bmelande> s3wong: Yes, true. Did you come up with a way of dealing with that?
05:24:02 <s3wong> bmelande: yes - but quite a brute force way
05:24:34 <s3wong> bmelande: we added an abstract method in servicebaseplugin to register service with service port table as a lookup
05:24:59 <s3wong> bmelande: so all services would have to implement it... though we basically only implemented it for VPNaaS
05:25:08 <bmelande> s3wong: Aha. Ok.
05:25:29 <s3wong> bmelande: Kanzhe and I posted a patch right at 11:30pm :-)
05:25:55 <s3wong> bmelande: we aim to come up with something more elegant before bringing it to community this time around
05:26:17 <s3wong> the spec was approved for Juno; but will need to revise and resubmit for Kilo
05:26:52 <s3wong> Nova has the policy of putting approved (but unimplemented) spec into an UNIMPLEMENTED directory in repo
05:27:03 <s3wong> but I guess Neutron doesn't have that
05:28:06 <bmelande> s3wong: Yes, I guess you'd want a  kind of inheritance for the DB for the service ports.
05:28:35 <bmelande> s3wong: No, I don't think Neutron has that.
05:29:12 <s3wong> bmelande: SumitNaiksatam and Kanze/me talked about a generic "service table"... we would like to have advanced service common info in some accessible table
05:29:35 <s3wong> bmelande: that could be something to explore with the community in Paris
05:31:10 <bmelande> s3wong: I'm asking because I recall vagely that we hit something like that issue too. Would like to undertand better if there is a good solution to such cases.
05:31:41 <s3wong> bmelande: did you build a router interface table in your driver as well?
05:33:13 <bmelande> Sort of, but we called it something like 'hostinghostedportbinding' table.
05:34:20 <s3wong> bmelande: yes... there are so many things that can be put in a common infrastructure
05:34:22 <bmelande> hosted port = Neutron port for router service instance (=Neutron router), hositing port = Neutron port that CSR service VM plugs a VIF into
05:35:15 <bmelande> s3wong: indeed.
05:35:39 <s3wong> bmelande: I guess that's why our project (serviceVM) exists :-)
05:36:06 * yamahata fully agreed
05:36:11 <bmelande> yamahata: with your worked on patch sets, will the Brocade implemenation map well into that?
05:36:51 <yamahata> bmelande: I think they can. I need their feedback though.
05:37:36 <yamahata> I investigated their code and CSR1kv code to accomodate them.
05:39:08 <yamahata> It's 8mins over. Do we want to continue on #tacker channel?
05:40:15 <bmelande> yamahata: Oh, right. For me, we can close the meeting.
05:40:50 <yamahata> Okay, let's close.
05:41:04 <yamahata> thank you every one. See you next week.
05:41:06 <s3wong> yamahata, bmelande: well, seems like freenode is kicking people out anyway :-)
05:41:10 <yamahata> #endmeeting