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