17:04:06 #startmeeting servicevm-device-manager 17:04:07 Meeting started Wed Feb 18 17:04:06 2015 UTC and is due to finish in 60 minutes. The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:11 The meeting name has been set to 'servicevm_device_manager' 17:04:48 hello 17:04:56 s3wong: hello 17:05:32 seems only two. 17:05:40 #topic Announcement 17:05:53 yamahata: bobmel is online, but he hasn't been attending Tacker meetings for a while 17:05:54 summit topic vote has started 17:06:24 #link https://www.openstack.org/vote-vancouver/ 17:06:27 hi 17:06:34 SridharRamaswamy: hi 17:06:53 our session link is https://www.openstack.org/vote-vancouver/presentation/tacker-virtual-network-function-life-cycle-management-for-openstack 17:06:56 #link https://www.openstack.org/vote-vancouver/presentation/tacker-virtual-network-function-life-cycle-management-for-openstack 17:06:57 SridharRamaswamy: hello 17:07:07 s3wong: hi 17:08:09 any other announcement? 17:08:26 yamahata: no 17:08:44 #topic Open Discussion 17:08:55 #chair s3wong SridharRamaswamy 17:08:57 Current chairs: SridharRamaswamy s3wong yamahata 17:09:15 yamahata: I would like to ask --- you have a section on oslo proxy, what is the intent of oslo proxy for Tacker? 17:10:30 s3wong: it was proposed for Juno cycle, but was rejected by oslo project. 17:10:48 yamahata: was the intention health check on VM? 17:10:50 So it's suspended. 17:11:20 the intention is to introduce side communication channel instead of provide net. 17:11:57 communication between openstack servers and service inside VM. 17:12:26 yamahata: so this was supposed to run in the context of the VM? 17:12:45 Yes. 17:13:40 yamahata: interesting, not in hypervisor / host-OS context like all the other agents then 17:14:17 Yea, but it was though of backdoor and big security flaw. So it was rejected. 17:14:35 yamahata: OK 17:15:07 yamahata: what communication did you expect Tacker to have with service VM besides health monitoring? 17:16:44 folks - sorry got disconnected :( 17:16:46 control communication. push/pull configuration/event notification 17:18:15 yamahata: OK. Since Tacker manages the VMs, we need to identify which set of config to push in case we restart a VM 17:19:03 s3wong: yamahata: are we are imagining a "friendly" ServiceVM where you can put tacker-agent in ? 17:19:21 to do these health / config push & pull ? 17:19:55 SridharRamaswamy: is that even possible? that we ask the service VM to include tacker-agent during launch? 17:20:13 Right. 17:20:28 It's possible with providernet now. 17:20:37 or can we have Tacker agent in hypervisor / host OS to do these? 17:20:43 No. Mostly likely not and thats what we need to design for... 17:21:14 yamahata: how is that accomplished with providernet? 17:22:10 We can create providernet which is connected openstack management network. 17:22:40 Then openstack servers and VMs can communicate freely by assigning the providernet to VMs. 17:22:58 I heard some cloud providers do so. 17:23:46 yamahata: Tacker has management interface abstraction --- so previously Tacker just creates such mgmt intf without plugging it into some mgmt network? 17:25:30 we need to write driver to connect the intf into mgmt network. 17:25:54 yamahata: but the mgmt network needs to be created outside of Tacker? 17:26:28 s3wong: Right. 17:27:02 yamahata: OK 17:27:41 what is the relation of this providernet to the actual tenant network ? At the end the traffic from tenant VMs need to be steered to one of these providernet towards the ServiceVM 17:28:06 I'd assume that would be different from the tacker-mgmt-network 17:29:19 SridharRamaswamy: sounds like yamahata was saying Tacker should leverage provider-net as the mgmt network for all Tacker managed VMs 17:30:16 s3wong: exactly. 17:30:58 yamahata: is it possible that Tacker an auto-create such provider-net? to ease up operators' work? 17:31:31 With some information from admin, it's quite possible. 17:32:38 yamahata: OK 17:33:35 yamahata, SridharRamaswamy: as mentioned in the email, my friend and I will be spending some 20% of time on Tacker, so we will be looking for things to do to shape Tacker into VNF Manager 17:33:52 Sorry, I missed the part why we are using provide-net ... i've always seen scenarios where ServiceVMs have it own mgmt-network 17:34:07 s3wong: +2 17:34:18 s3wong: +2. I'm surely willing to help 17:34:33 same here 17:35:03 SridharRamaswamy: yeah... sounds like this new provider-net unifies the VM mgmt network interface 17:35:51 yamahata: that said, so now all VMs would be launched with a vport connecting to the provider-net, in addition to having another vport connecting to Neutron network? 17:36:10 Yes. 17:36:25 yamahata: interesting, so this is a Nova thing then? 17:37:12 Right. That's the reason why a driver which talks to nova is needed. 17:37:25 yamahata: I see 17:37:30 yamahata: good to know 17:39:08 we can certainly try this as the communication channel between Tacker and VMs 17:40:47 any other topics? 17:40:54 yamahata: that 17:40:57 that's it for me 17:41:27 regarding the talk, are we going to demo some of these concepts ? 17:41:49 SridharRamaswamy: well, we will know if our talk will be voted in in two week :-) 17:42:09 SridharRamaswamy: so, if it is, then we can meet f2f to see if and what we want to demo 17:42:20 we will see. I'll afraid after it's accepted... 17:42:40 s3wong: +1 17:42:47 SridharRamaswamy, yamahata: until then, we march along to build Tacker without worrying too much about the talk first :-) 17:44:22 okay, thank you everybody. 17:44:27 Thanks! 17:44:28 let's vote for summit talk. 17:44:43 #endmeeting