05:01:07 #startmeeting servicevm-device-manager 05:01:08 Meeting started Tue Aug 5 05:01:07 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:01:11 The meeting name has been set to 'servicevm_device_manager' 05:01:25 today Karthic is absent 05:01:33 #topic Announcement 05:02:17 our proposal for openstack summit is here 05:02:25 hello 05:02:44 #link https://www.openstack.org/vote-paris/Presentation/introducing-tacker-service-vm-project 05:02:56 Let's promote it 05:03:27 Bob may want to fulfil his bio 05:03:55 FYI: i voted 3 stars for it 05:03:56 s3wong: Hi 05:04:04 #action bobmel fulfil the bio 05:04:22 bobmel: hello - seems like you aren't using bmelander today :-) 05:05:09 I uploaded WIP code for l3 routervm 05:05:16 #link https://github.com/yamahata/neutron/tree/l3-routervm/neutron l3 routervm WIP code 05:05:23 It's not yet ready for review. 05:05:37 Yamahata: where do I update bio? 05:05:48 Probably only interesting code is https://github.com/yamahata/neutron/blob/l3-routervm/neutron/services/l3_router/vrouter/l3_vrouter_plugin.py 05:05:54 https://github.com/yamahata/neutron/blob/l3-routervm/neutron/services/l3_router/vrouter/l3_vrouter_driver.py 05:06:23 bobmel: Login the rfp page, then you'll find your bio page 05:06:58 #link https://www.openstack.org/summit/openstack-paris-summit-2014/call-for-speakers/ login page for call-for-proposal 05:07:07 yamahata: ok, thanks 05:07:39 I still working on l3 routervm plugin code. 05:08:05 Sorry delay for api review. I'll do it today 05:08:35 #topic open discussion 05:09:06 anything to discuss? 05:09:43 I'd like to raise the issue of auth token in neutron context 05:09:57 #link https://review.openstack.org/#/c/111756/ patch to add auth token to neutron context 05:10:09 Does it help? 05:11:19 Although just admin account would be used for simplicity for now, in future we'd like to use per tenant token or something 05:13:19 Seems no idea. Anyway it doesn't harm. I'll just push the patch. 05:13:53 Another topic is attach/detach interface to/from vm 05:14:23 Last week, we discussed a bit. But Bob wasn't there. 05:14:56 On behalf of router-interface-attach or plugging driver, we need to interface-attach/detach to vm. 05:15:18 yamahata: yes, it could be useful. We currently use admin to a void the issue. 05:15:18 it should be done by servicevm server, not neutron server. 05:16:09 yamahata: you mean the servicecm 05:16:11 bobmel: thanks, that encourages me. So I try to make it for Juno. 05:16:15 bobmel: yes. 05:16:56 So I'm thinking of servicevm api like /device//attach/detach-interface 05:17:06 oops attach-interface or detach-interface 05:17:33 body includes {"port_id": } 05:17:34 yamaha: sorry, typo, you mean service VM server makes the call to add/remove vif to service VM? 05:17:42 bobmel: Right. 05:18:00 the api eventually calls nova attach/detach interface with neutron port id 05:18:22 bobmel: Does it make sense for you? 05:18:29 yamahata: ok 05:18:34 Or plugging driver should handle it? 05:18:59 can a vif be added after the vm is launched? 05:19:17 hemanthravi: Yes 05:19:25 hotplug? 05:19:43 not all os's support hotplug 05:19:46 s3wong: yes, pci hot plug 05:20:04 guest OS support is another story 05:20:05 properly 05:20:36 yamahata: well, the operation needed to plug a logical service instance, e.g., neutron router, to a Neutron network/subnet, depends on what mechanism is used. 05:20:50 Vif hotplug is on such mechanism. 05:21:01 bobmel: Do you mean plugging driver? 05:21:15 bobmel: If so, I agree. we need to tell service 05:21:54 yamahata: in our implementation we tried to capture that in what we call a plugin driver. 05:22:54 bobmel: can you be more specific? Hopefully which code? 05:23:05 yamahata: one plugging could then handle case with vif hotplug, another could handle case with plugin capable of VLAN trunking all the way to the VM, etc 05:24:51 yamahata: The code submitted for review contains a plugging driver for VLAN trunking case (as supported by the Cisco N1kv plugin). 05:24:54 bobmel: I see. A sort of abstraction will be necessary. i.e. plugging driver in your case 05:25:22 _get_unused_service_vm_trunk_port ? 05:26:22 yamahata: yes, that's what we tried to achieve. Perhaps the abstraction needs to evolve but it can handle VLAN trunk case and vif hotplug case. 05:27:17 bobmel: Agree, the abstraction will be evolved from simple cases. 05:27:33 yamahata: that's an internal function in the VLAN trunk case, the interface is in the __init__ file in the plugging driver directory 05:29:13 anything else to discuss? 05:30:14 The driver interface is here: #link: https://review.openstack.org/#/c/101002/12/neutron/plugins/cisco/l3/plugging_drivers/__init__.py 05:30:16 thank you everyone. see you next week 05:30:28 Ok, bye! 05:30:30 Thanks! 05:30:37 bobmel: thanks. Now I know where I should look at. 05:30:57 #endmeeting