05:01:01 #startmeeting servicevm-device-manager 05:01:02 Meeting started Tue Jul 15 05:01:01 2014 UTC and is due to finish in 60 minutes. The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:01:05 The meeting name has been set to 'servicevm_device_manager' 05:01:26 Do we have bob? 05:01:45 Give him a minute 05:01:52 bmelande: hi 05:02:02 hello 05:02:04 yamahata: Hi 05:02:11 s3wong: Hi 05:02:18 bmelande: hello 05:02:20 hi 05:02:30 Only two minutes late, improving... :-) 05:02:37 hi everyone, let's start 05:02:47 #topic Announcement 05:02:52 natarajk: hi 05:02:57 This week not so much to announce 05:03:03 bmelande:hi 05:03:16 sorry I haven't keep up with the api review. 05:03:35 #action yamahata process api back log 05:03:47 yamahata: only that it is 3 days away from the spec approval deadline, so we are all busy trying to get specs approved :-) 05:04:00 s3wong: yeah. Definitively. 05:04:04 yamahata: I'm also behind 05:04:46 The spec review is moved to gerrit system. 05:05:00 So please move the discussion to gerrit. 05:05:04 yamahata: i added my comments last week 05:05:18 #link https://review.openstack.org/#/c/103724/ servicevm api review 05:05:22 yamahata: will do 05:05:32 natarajk: Yes, thank you. I'm aware of it. 05:05:48 sorry for not timely response. 05:06:30 I surely will review it. It might be after Neutron spec approval deadline 05:06:41 i know you are busy with Juno specs :) 05:06:59 any announcement from anyone? 05:07:37 #topic api discussion 05:08:05 It seems every one is try to catch up the discussion. Do we have special issues to discuss here? 05:08:36 yamahata: I put my comments on gerrit already (as well as the gdoc) 05:08:54 s3wong: thanks, okay let's continue discussion there. 05:09:03 let's move on 05:09:13 #topic terminology 05:09:39 Last week we discussed a bit to unify servicevm and dnrm. 05:09:59 The first difference is terminology. hosting device vs resource 05:10:18 I think everyone has their opinion on terminology. 05:10:33 yamahata: after reviewing your specs, i am fine with the terminologies documented in the api spec 05:10:38 personally I don't stick which terminology, but we need to come consensus 05:11:00 natarajk: So hosting device and template is acceptable for you? 05:11:06 yes 05:11:23 natarajk: wow great. 05:12:07 This issue is resolved. 05:12:10 next topic 05:12:28 #topic l3-routervm-plugin 05:12:55 For reference l3-servicevm-plugin, I've started with Bob's implementation 05:13:20 I'm trying to identify which is common and which is the csr specific. 05:13:36 yamamata: have you gotten any indication if your BP will get clearance for Juno? 05:14:02 bmelande: Not yet. 05:14:18 There are no response yet. I'm still waiting from Kyle. 05:14:27 yamahata: Ok. 05:14:39 #linke https://review.openstack.org/#/c/101002/ csr1kv routervm 05:14:45 I started this source code. 05:15:16 bmelande: This repo is the preferable one for me to start with? Or do you have any better public repo? 05:15:35 yamahata: which repo? 05:16:09 I mean the gerrit repo or github repo whose branch is csr1kv_for_routing_juno 05:16:50 I chose the gerrit repo above because the patch size is smaller 05:17:25 yamahata: The cisco repo contains the "full" version in that csr1kv_for_routing_juno branch. Then what I submit for review is a boiled down minimal version, to have any chance of getting it in by Juno. 05:18:34 The one on gerrit does not involve managing a pool of VMs, the full one does. 05:18:43 bmelande: I see. 05:19:13 bmelande: I'm wondering how to manage a pool of VMs 05:19:36 It's because both csr1kv and dnrm implements VM pooling 05:19:51 So I'm trying to figure out where the feature live in. 05:20:04 I believe the gerrit patch is more similar to the Brocade patch (without having actually seen that code) 05:20:10 yamahata: you can look at the supervisor service in dnrm for VM pool management code 05:20:13 DNRM implement pooling in dnrm server. 05:20:44 On the other hand csr1kv implements in Neutron server for now. 05:20:55 So It's a issue. 05:21:04 yamahata: we are planning a separate OpenStack service anyway 05:21:15 natarajk: yes. 05:21:40 so you can take a look at dnrm and start from there 05:22:00 natarajk: Yes, I had a look at it. 05:22:17 And I'm looking at csr1kv code trying to firgure out the difference 05:22:31 yamahata: the pool management in the full version is kept as a separate device manager plugin so it is quite self-contained. 05:23:14 bmelande: great. 05:23:56 So the first working version won't implement pooling, and then as the second phase, we would like add pooling feature. 05:24:08 Does this approach make sense? 05:24:10 yamahata: +1 05:24:13 Or won't work? 05:24:17 +1 05:24:28 yamahata: +1 - we should do it phase by phase 05:24:39 yes 05:24:52 gives more time to discuss it too 05:24:57 #agreed the first version won't implement pooling feature. it will be addressed at 2nd phase. 05:25:01 similarities, differences 05:25:25 One thing regarding the router servicde plugin for neutron: 05:26:34 if the flavor framework actually converges and gets done by Juno I belivee the way to go is to make a router serviuce plugin aligned with that. 05:26:54 bmelande: +1 05:26:57 bmelande: I think it will, it is on schedule for J-2 05:27:23 bmelande: in fact, I believe enikanorov has already started coding it (and the spec is the one from markmcclain) 05:27:29 It would mean that there could be drivers in such a plugin for the different VM-based routers 05:27:56 s3wong: yes, I got that understanding too. 05:28:35 #topic open discussion 05:29:09 So it is good to keep that flavor framework in mind for any new router service plugin. 05:29:22 bmelande: +1 05:29:28 bmelande: surely +1 05:29:46 +2 05:30:10 Also, Gary Duan (varmor) started a modular router service plugin for the old service type framework that he might have plans to rework for flavor framework, 05:30:49 bmelande: sounds great. any link? 05:31:02 bmelande: hmm... OK, we should contact garyduan (he is online?) for his patch 05:31:16 garyduan: hello? 05:31:24 So we might want to check with him about that, and (especially if rtouter service plugin gets pushed to K), have a joined effort on the plugin. 05:32:15 bmelande: honestly we would probably have to expect it to get pushed out to 'K' 05:33:18 s3wong: Yes that is not unlikely unfortunately given the number of BPs around... 05:34:27 Gary's old BP for router service plugin for service type framework: #link: https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type-framework 05:35:09 bmelande: thanks for the link 05:35:20 It uses the pre-/post-commit pattern from ML2. 05:35:29 bmelande: wow, November of last year... 05:35:38 We are running out of time. any other topic? 05:36:10 s3wong: Yeah, ages ago.... :-) 05:36:34 bmelande: of course, who would do anything with service type framework now :-) 05:37:39 Let me raise the last topic(from me) 05:37:42 s3wong: Nah, let's throw that one back in the flavor discussion so that it can take another 40 iterations... :-) 05:38:00 The tacker repo is empty now. 05:38:26 Do you have any objections for me to self-approve my first patches to push them into the repo? 05:38:51 The code may not be in so good shape, 05:39:11 but it's very early development stage. 05:39:34 So it would make sense to have a kind of working code in repo. 05:39:47 yamahata: sure, do you need bmelande and my +2's? :-) 05:40:19 s3wong: If you're fine, I'll go without your +2. 05:40:37 I just wanted to make sure before self-approving 05:41:03 let's get some code in :) 05:41:17 yamahata: damn, wanted to exercise the privilege :-) --- please go ahead and push it in 05:41:19 yamahata: I'm ok with that, especially the early ones, remove neutron code etc 05:41:29 +1 05:41:54 thanks, I'll push it tonight. 05:42:15 Until that, feel free to add +2 and get familiar with it. 05:42:57 any other issues? 05:43:49 Okay, thanks and see you next week. 05:43:57 thanks! 05:44:02 bye 05:44:06 If we like, we can continue discussion on #tacker 05:44:20 #endmeeting