17:14:34 #startmeeting servicevm_device_manager 17:14:35 Meeting started Wed Dec 17 17:14:34 2014 UTC and is due to finish in 60 minutes. The chair is s3wong. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:14:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:14:39 The meeting name has been set to 'servicevm_device_manager' 17:15:10 #topic announcement 17:16:11 I don't think there is much to announce, other than Neutron SAD has passed 17:16:47 I noticed yamahata's spec for l3router vm was -2'ed by salv-orlando 17:17:30 #link https://review.openstack.org/#/c/105078/ 17:17:47 s3wong: that's because spec is not needed for l2 and l3 plugins 17:18:03 s3wong: because of vendor plugin decomposition 17:18:13 natarajk: correct 17:18:37 but it also true that I'm evil and feel pleasure in giving -2s 17:19:06 natarajk: really? the comment seems to indicate that it lacks consensus and the topic has multiple blueprints that need to be consolidated 17:19:09 salv-orlando: LOL 17:19:13 salv-orlando::) 17:20:13 s3wong: i just checked the spec. It is for modular L3 plugin. I haven't reviewed this yet 17:20:29 natarajk: sure 17:20:30 s3wong: to me that specs reads a bit like flavor framework for vm based l3 router 17:21:03 s3wong: There was another spec for l3routervm plugin related to mccafee proposed by Isaku 17:21:06 SridharRamaswamy: the topic sounds like ML3 :-) 17:21:14 s3wong: yep 17:21:33 natarajk: did that one get approved for Kilo? (do you have the link?) 17:21:46 so i'm not sure if decomposition would help in this case 17:22:15 s3wong: the mccafee plugin should follow decomposition principle 17:22:39 s3wong: I haven't reviwed the Modular L3 plugin spec yet 17:22:48 SridharRamaswamy: is L3 service considered part of vendor driver, or service plugin? 17:23:00 I am also not sure how will the vendor plugins for l3 are going forward 17:23:35 s3wong: L3ServicePlugin and reference implementation will be in-tree 17:23:42 s3wong: salv-orlando: correct me if i'm wrong, the current plan is to thin out l3 plugin as well 17:23:56 s3wong: Vendor plugins that extend L3ServicePlugin should be out-of tree 17:24:25 natarajk: exactly 17:24:30 natarajk: yes 17:25:08 But vendor plugins for services are in the services repo, right? 17:25:17 correct 17:25:33 natarajk: though I am curious to know if any vendor has implemented L3 Service only driver but has no Neutron core plugin implementation --- in that case, their L3ServicePlugin driver would remain in tree? :-) 17:25:35 but l3 still belong in neutron-core 17:26:30 hareeshp: currently the service repos that were split are FW/LB/VPNaaS, so metering and L3Service remained to be part of Neutron repo 17:26:35 So if they have a dependency on l3, there are three repos now 17:26:56 SridharRamaswamy: correct again 17:28:20 OK, let's move on then :-) 17:28:28 salv-orlando: thx 17:28:41 #topic workflow discussion 17:30:00 did everyone get a chance to comment on the doc? 17:30:07 #link https://docs.google.com/document/d/1xs8TvEVMszzND5uoWTHtd1tJnu7105Ekgq9hxiyXABQ/edit 17:30:23 s3wong: i provided some initial comments 17:30:37 Looks like the last edit was Dec 2nd, so probably not much :-) 17:31:22 I think once yamahata successfully migrates to US, we should have the webex session to talk about this 17:31:31 s3wong: that document badly needs a diagram to illustrate the flow 17:31:38 SridharRamaswamy: thanks 17:32:10 s3wong: as i've been asking earlier, we need a clear(er) separation of layers between service-vm-api and the users (l3 plugins, etc) 17:32:34 SridharRamaswamy: it does. TBH I still feel that the flow wasn't clear for the team in general 17:32:46 SridharRamaswamy: agreed 17:33:47 SridharRamaswamy: to me, Tacker should have the API for services (and users) to consume, and a plugin layer for different device/resource-mgmt to implement 17:34:43 s3wong: agreed, but there was some confusion while discussing this during kilo summit. 17:35:05 s3wong: so it will be better to document it and get everyone in the same page 17:35:15 SridharRamaswamy: yes, hence we need to add our thoughts in the document 17:35:49 s3wong: can u help documenting that ? i can volunteer to throw in a diagram 17:35:56 SridharRamaswamy: I suspect the coming webex session would be emphasizing on the general use case and architecture/workflow of Tacker, based on that document 17:36:03 SridharRamaswamy: sure 17:36:58 SridharRamaswamy: I will add a section at the bottom, and I welcome any team members to express his/her opinion on how you think Tacke should be in the document 17:37:04 *Tacker 17:37:58 since we are at K-1 now, and we need to get some consensus on how to proceed and what to (try to) accomplish in Kilo timeframe 17:38:05 s3wong: sounds good 17:38:34 S3wong: agreed 17:38:52 so, please comment or update (by adding content) the document, and we can have discussion on email as well 17:39:04 hareeshp: do you have write access to the doc? 17:39:31 I will review the doc this week now that the SAD date has passed 17:39:37 Not sure. Will check and let you know 17:39:44 vishwanathj: Thanks! 17:40:32 Irc Using a phone now :p 17:40:45 I see that SridharRamaswamy, vishwanathj , and natarajk all have write access 17:41:17 so let's have discussion on doc, and consolidate our thoughts on there directly 17:41:45 hareeshp: seems like you were left out :-) 17:42:03 Och! 17:42:10 hareeshp: do you want me to add you via your cisco email or gmail account? 17:42:26 Use Gmail, that's more convenient 17:42:43 hareeshp: done :-) 17:43:00 Less spam ☺ 17:43:25 while we at it .. i'd like to know the commit / review process for the tacker stackforge repo 17:43:36 #link https://github.com/stackforge/tacker 17:43:45 SridharRamaswamy: it should be the same as Neutron 17:44:39 s3wong: okay, Isaku or you have the approval privilege to merge a changeset ? 17:44:42 instead of neutron, the project is tacker 17:44:52 one example is here: https://review.openstack.org/#/c/121327/ 17:45:01 this is for tacker-spec, but you get the idea :-) 17:45:44 s3wong: sounds good, thanks 17:45:49 SridharRamaswamy: yes, yamagata, bobmel. and I all have +2/+A privileges 17:45:58 * yamahata 17:47:09 SridharRamaswamy: and though it is a stackforge project, we would still like to follow the same OpenStack procedure as (1) file spec, (2) get spec approved, then (3) post patches...etc 17:47:32 s3wong: okay 17:47:37 make sense 17:48:06 SridharRamaswamy: don't worry, we aren't as evil as neutron-cores :-) 17:48:17 (at least I hope we aren't) :-) 17:48:20 LOL 17:48:50 #topic Open Discussions 17:49:05 anything else you guys want to bring up for this week? 17:49:26 next Wednesday is the 24th, do you guys still want to have a meeting? 17:49:49 I am out next week 17:49:58 vishwanathj: OK 17:49:58 i'd vote to skip meeting next two weeks.. 17:50:06 +1 17:50:14 +1 17:50:23 OK --- consensus reached! 17:50:24 we can colloborate on google docs .. 17:50:36 we will reconvene in 2015 17:51:06 the next meeting will then be Jan. 7th 17:51:26 Happy holidays and a happy new year to all 17:52:08 Yes, Merry Christmas and Happy New Year 17:52:34 Any other topic to discuss? 17:53:23 See you guys next year! 17:53:30 Please comment on the document 17:53:40 ok, bye 17:53:44 #endmeeting