05:02:06 #startmeeting servicevm-device-manager 05:02:07 Meeting started Tue Jun 24 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:02:10 The meeting name has been set to 'servicevm_device_manager' 05:02:37 #link https://wiki.openstack.org/wiki/Meetings/ServiceVM agenda 05:02:49 #topic announce 05:03:14 the repo on stackforge isn't created yet. It's too slow 05:03:35 So I create temporal repo until the creation on stackforge 05:03:45 #link https://github.com/yamahata/tacker-specs for specs 05:03:53 #link https://github.com/yamahata/tacker 05:04:03 #link https://github.com/yamahata/python-tackerclient client 05:04:22 the main server is still WIP, but I think it's fine for api review 05:04:48 yamahata: nice! 05:05:11 Once the repo is created, we can move to stackforge 05:05:23 does anyone have anything to announce? 05:05:55 Brocade's DNRM code is available in github now 05:06:07 https://github.com/Karthik-Natarajan 05:06:16 It can be used in tacker project 05:06:49 DNRM? 05:06:49 natarajk: cool. Now we have 4 independent implementations. We should consolidate somehow 05:07:01 #link https://github.com/Karthik-Natarajan brocade DNRM 05:07:09 Dynamic Network Resource Management (DNRM) 05:07:27 natarajk: do you have any documentation? API documentation? 05:07:55 I'll add the design docs as well 05:08:16 Cisco implementation with CSr1kv as first VM appliance is here: https://github.com/CiscoSystems/neutron/tree/csr1kv_for_routing_juno 05:08:17 yamhata: what is the url for reviewing of the code and BP spec? 05:08:19 I saw the quite old one, https://wiki.openstack.org/w/images/7/71/Dnrm-blueprint-001.pdf it doesn't seem to match the implementation 05:08:53 #link https://wiki.openstack.org/w/images/7/71/Dnrm-blueprint-001.pdf dnrm spec seems too old 05:09:06 yamahata: with these implementation, what is the plan to consolidate or integrate (in case they are all addressing different aspects of serviceVM)? 05:09:10 The supervisor service will maintain a pool of VMs 05:09:29 If some parts can be reused, we are happy to help 05:09:46 I think the plan is implement l3_plugin that talks with servicevm project as PoC. 05:10:32 yamahata: but what is the scope of serviceVM in tacker? 05:10:37 Then we can validate that routerVM(cisco, brocade) can be consolidated to tacker. 05:10:40 s3wong: yes. 05:11:00 And we can also confirm tacker API is enought (at least) rounterVMs. 05:12:00 At first cisco/brocade router implementation may/can differ, eventually we should consolidate the implementations somehow. 05:12:25 I'm willing to implemente l3 service pluging for PoC. 05:12:48 Cisco and Brocade can work on their implementation in parallel. 05:12:57 yamahata: so we can try to put L3 plugin to integrate with serviceVM project, then see if Cisco and Brocade router VM implementation can be integrated? 05:13:20 s3wong: that's what I have in mind. any opinions? 05:13:29 That's fine. 05:13:31 yamahata: Are you talking about the l3 plugin in Neutron tree? 05:13:40 bmelande: yes. 05:14:15 L3 plugin in Neutron that talks to tacker to spin up/down VM 05:14:33 yamahata: Are the tacker API's ready for review ? 05:14:55 yamahata: why not l3 agent? 05:14:58 natarajk: not ready for code review. ready for API review. 05:14:58 yamahata: Ok. One thing though. I think that plugin needs to be properly modularized. 05:15:09 gongysh: including l3-agent 05:15:11 yamahata: It is not at the moment. 05:15:49 bmelande: Do you mean l3pluging needs to be refactored for modularity? 05:16:07 l3pluging l3-plugin 05:16:09 yamahata: Yes, it really needs that IMHO. 05:16:25 bmelande: I have same feeling. 05:16:34 bmelande: is that part of serviceVM project though? 05:17:22 yamahata, s3wong: No it is not part of service VM. Just that if we target to add to the existing l3 plugin, it will get even worse. 05:18:22 s3wong: bmelande Without actual service, servicevm project won't have any value. I think servicevm project needs real example 05:18:39 yamahata: agreed 05:19:35 yamahata: That I agree with too. Just wanted to mention that aspect. We don't need to go deeper into that issue here/now. 05:20:15 So we have 5 tasks now 05:20:46 #action natarajk write DNRM API documentation 05:20:50 yamahata: I wonder about the service instance etc. Is that stuff really needed in service VM? 05:20:56 #action tacker api review 05:21:36 bmelande: I'll drop it because we haven't reached consensus. 05:21:46 bmelande: Just template and hosting device 05:21:56 yamahata: ok 05:22:04 the code is there, but I'll remove it. 05:22:26 #action yamahata start 3-plugin poc code/blueprint 05:22:55 #action someone l3-plugin refactoring blueprint/spec/code 05:23:37 Is there any announcement? 05:24:11 yamahata: you were saying 5 tasks? you listed 4, what is the last one? 05:24:38 s3wong: ouch, 4. I can't count numbers. 05:24:42 yamahata: how to review tacker api? is there gerrit review URL set up? 05:24:45 yamahata: OK :-) 05:25:03 #link https://github.com/yamahata/tacker-specs/blob/master/specs/juno/api.rst api spec 05:25:22 I'll remove service resource. 05:25:43 Does github support commenting or something? 05:25:48 yamahata: will the REST API implementation be based on some particular framework? 05:26:13 If no, I'll move it to google-doc. 05:26:27 I don't think github support comment 05:26:33 bmelande: What do you mean by 'some particular framework'? 05:26:35 yamahata: google-doc is better 05:26:53 #action yamahata move api document google-doc and announce it 05:27:22 yamahata: yes, putting it in .rst format but not on gerrit basically negates the reason why it was in .rst in the first place :-) 05:27:40 Now it's 5 tasks. :-) 05:29:08 bmelande: I plan to implement tacker based on neutron one. Do you have any preference? 05:29:35 yamahata: That's fine with me. Just asked given that there's been discussions to migrate Neutron to pecan. 05:30:12 bmelande: Yes, that's my concern. Any idea? 05:30:40 I just use neutron because it is there. No other special reason 05:31:00 yamahata: Yes that makes sense to get going fastest. 05:31:00 yamahata: i think markmcclain was planning to migrate to pecan 05:31:07 we can check with him 05:31:52 yes fastest way for working code. later we can fix it. 05:32:05 #topic api discussion 05:32:10 we already discussing on api 05:33:22 Do we have anything else on servicevm api/implementation? 05:33:54 Okay let't move on 05:33:55 yamahata: i wanted to bring up with cross-tenant port attachement issue in nova 05:34:04 does anyone have a solution for it ? 05:34:32 natarajk: do you have any links? 05:35:06 i don't have any links. I sent you a e-mail last week on that issue 05:35:15 natarajk: There was a recent reveiw out for change to policy 05:35:47 bmelande: link please 05:36:07 natarajk: searchign for it... 05:36:22 one sec... 05:37:22 Speaking of that, I almost forgot. Last week at the LBaaS mid-cycle, there was some work done on creating a new "advanced service" role (in addition to admin and tenant) 05:37:34 the review is here: #link https://review.openstack.org/#/c/101281 05:37:40 Here is the review I was mentioneing:https://review.openstack.org/#/c/101281 05:37:50 s3wong: you were faster. :-) 05:37:54 bmelande: that's the one :-) 05:38:01 s3wong: thanks 05:38:36 bmelande: turns out we were talking about the same thing :-) 05:39:45 cool. 05:40:04 s3wong: indeed. :-) 05:40:38 #topic neutron review 05:40:53 we already covered one 05:41:25 We have three specs floating. 05:41:54 l2-gateway/vlan-aware-vm, portsecurity extension and unaddressed port 05:42:30 l2-gateway and unaddressed port needs more review to make progress 05:42:31 yamahata: aren't those reviews marked as NFV ones? 05:42:49 s3wong: yes, they are marked as NFV ones. 05:43:03 yamahata: you can add the 101281 to that list. 05:43:34 bmelande: Sure. Can you please add it to the wiki page? 05:43:47 yamahata: ok 05:43:49 bmelande: that one is sent out by mestery, don't you dare to give him a -1 :-) 05:43:56 #action bmelande add 101281 to code review tracking list 05:44:31 s3wong: Yes, let's not go near that one. :-) 05:44:58 we can some +1s :) 05:45:04 we can give 05:45:08 some +1s 05:45:15 natarajk: :-) 05:46:19 anything else for review? 05:46:41 #topic open discussion 05:47:14 yamahata: the 2 interfaces to same network one is picking up traction as well 05:47:29 s3wong: agree. link? 05:47:35 #link https://review.openstack.org/97716 05:48:02 #action s3wong add 97716 to review tracking page 05:48:13 #action everyone review specs/codes 05:48:20 s3wong: thanks for the link 05:49:07 natarajk: I had a quick look at the code, the concept looks quite different from servicevm. Could you please explain a bit here? 05:49:28 especially what does resource mean and it's action. 05:49:44 yamahata: every VM is a resource 05:49:59 Resource manager will maintain the pool of VMs 05:50:33 l3 plugin will talk to the resource manager service to get the list of VMs 05:50:51 scheduler will allocate the VM satisfying the policy 05:51:15 natarajk: I see. 05:51:53 i'll also send out the design doc for DNRM 05:52:14 natarajk: Yes, please. Then we can make discuss on it. 05:52:19 https://docs.google.com/document/d/1_A2UJDGngzkicY3Zx95TgXg5Fu6wn5ZL_Gx2zJt4m18/edit?pli=1 05:52:26 Can you access it ? 05:52:54 natarajk: I also looked at neutron and code. But they have only master branch. It is difficult to get diff from plain neutron/nova 05:52:55 natarajk: the doc is a Mirantis doc? 05:53:15 natarajk: I'm seeing mirantis doc 05:53:16 Brocade used Mirantis consultants 05:53:42 natarajk: can you please add the link to the wiki page? 05:53:48 natarajk: from your description, it is a service VM pool manager? 05:54:02 Yamahata: Yes, that's correct 05:54:11 #action natarajk add dnrm page to the wiki 05:54:44 natarajk: The scheduler is not part of resource manager, right? 05:54:57 yamahata: Correct. It's part of Neutron 05:55:22 yamahata: But we had a very simple scheduler to start with 05:57:11 natarajk: thanks for explanation. 05:57:19 anything else to discuss? 05:57:37 yamahata: Welcome. DNRM's Neutron/Nova code is based on havana. Resource manager can be reused now 05:58:16 Okay let's meet next week. (or on nfv meeting) 05:58:26 #endmeeting