17:04:29 <yamahata> #startmeeting servicevm-device-manager 17:04:30 <openstack> Meeting started Wed Mar 4 17:04:29 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:34 <openstack> The meeting name has been set to 'servicevm_device_manager' 17:04:45 <yamahata> #chair SridharRamaswamy s3wong 17:04:46 <openstack> Current chairs: SridharRamaswamy s3wong yamahata 17:05:12 <yamahata> #topic Announcement 17:05:18 <yamahata> any announcement? 17:05:38 <yamahata> I suppose the notification of summit session proposal is not yet. 17:05:48 <s3wong> yamahata: no 17:05:59 <SridharRamaswamy> yamahata: haven't seen any 17:06:48 <yamahata> #topic Action Items from the last week 17:07:04 <yamahata> My devstack patch is at https://github.com/yamahata/devstack/tree/snapshot-adv-svc-vm 17:07:17 <s3wong> yamahata: nice 17:07:23 <yamahata> It's quite old unfortunately. 17:07:45 <yamahata> I thought I had new one, but I counldn't fine int 17:07:57 <yamahata> I counldn't find one 17:09:07 <yamahata> #topic Open Discussion 17:09:55 <yamahata> anything to discuss? 17:10:16 <SridharRamaswamy> folks - is there a list of functionality written down for the new scope of tacker ? 17:10:32 <s3wong> yamahata: not from me --- sorry, day job has been busy 17:10:47 <s3wong> SridharRamaswamy: not that I am aware of 17:10:56 <yamahata> everyone is busy.. 17:11:02 <SridharRamaswamy> if i may rattle out few :) 17:11:13 <yamahata> SridharRamaswamy: I'm not aware of it. 17:11:14 <s3wong> SridharRamaswamy: please go ahead 17:11:47 <SridharRamaswamy> 1) catalog of service-vm images 17:11:52 <SridharRamaswamy> 2) basic life-cycle of service-vm (start/stop) 17:12:05 <SridharRamaswamy> 3) basic health monitoring of service-vm 17:12:14 <SridharRamaswamy> 4) respin of service-vm on failure 17:12:34 <SridharRamaswamy> these are the top ones 17:12:43 <SridharRamaswamy> make sense? 17:13:03 <s3wong> SridharRamaswamy: we need to have infra for config saving and config push (in case of resin) 17:13:08 <s3wong> respin 17:13:17 <SridharRamaswamy> okay .. lets add it 17:13:41 <SridharRamaswamy> 5) maintaining VNF configuration state 17:14:08 <s3wong> SridharRamaswamy: that is a good initial list 17:14:20 <SridharRamaswamy> I stopped at (4) because there are remaining functions all go into being VNF specific 17:14:26 <SridharRamaswamy> which is fine 17:14:26 <yamahata> SridharRamaswamy: really good. 17:15:25 <s3wong> yamahata, SridharRamaswamy: we can aim for these as initial list of functions 17:15:49 <SridharRamaswamy> between (1) and (2) there is something missing .. atleast for me 17:16:21 <SridharRamaswamy> the network to land the service-vm .. 17:16:56 <SridharRamaswamy> is that VNF specific or one separate tenent and network to host all VNFs ? 17:17:30 <s3wong> SridharRamaswamy: the VNF spawned needs to have a network position for the tenant 17:17:57 <s3wong> SridharRamaswamy: but for management network, should it be a common management network which provider can access them? 17:18:46 <SridharRamaswamy> yeah, that make sense.. 17:19:26 <s3wong> SridharRamaswamy, yamahata: from yamahata's point last time, we will use provider-net from Nova to communicate with all the VNFs 17:20:12 <SridharRamaswamy> that is for mgmt network access for the VNFs, correct? 17:20:25 <s3wong> this also will allow admin/provider to access/manage VNFs created by tenants 17:20:59 <yamahata> Yes. For now provider-net is practical and easy way. 17:21:00 <SridharRamaswamy> how about the tenant workload traffic going to go to a VNF ? 17:21:05 <s3wong> SridharRamaswamy: yes, we will use it for admin access, as well as config fetch / push 17:21:20 <s3wong> SridharRamaswamy: that needs to be hot-plug 17:21:27 <s3wong> (which I hope is working well :-) ) 17:21:43 <SridharRamaswamy> it is working for us :) 17:21:49 <yamahata> hot-plug is issue. 17:22:00 <yamahata> SridharRamaswamy: cool. 17:22:25 <yamahata> Probably using l2-gateway or VLAN-aware-VM stuff as workaround. 17:22:46 <SridharRamaswamy> the question i'm leading to is .. what kind of metadata we need to capture in the VNF catalog per vnf 17:23:00 <yamahata> I proposed blueprint to allow to change tenant owner of port, it was rejected. 17:23:08 <s3wong> yamahata: you mean any additional networks that tenant wants the VNF to connect to, we will just hook it up via l2-gateway? 17:23:45 <yamahata> s3wong: correct. and hot-plug happens at l2-gateway so that servicevm doesn't need hot-plug 17:24:30 <s3wong> SridharRamaswamy: outside of the service type, associated config, network position, image...etc? 17:24:57 <SridharRamaswamy> s3wong: okay 17:25:28 <s3wong> SridharRamaswamy: we will likely add more (a lot more) as we evolve 17:25:43 <SridharRamaswamy> s3wong: sure, of course 17:25:56 <SridharRamaswamy> yamahata: thats an interesting proposal .. 17:27:18 <yamahata> the spec, https://review.openstack.org/#/c/135520/ was too radical. it needs re-think. 17:27:18 <s3wong> SridharRamaswamy, yamahata: that would work if the only insertion we would do is putting the VNFs in Neutron networks 17:28:31 <s3wong> -2 by salv-orlando 17:30:09 <s3wong> yamahata: assuming hot plug is working, wouldn't a way to allow VMs to start without connecting to a Neutron network useful? 17:30:23 <s3wong> yamahata: as well as allowing Nova instance to 'unplug' from Neutron network 17:30:48 <yamahata> s3wong: yes, it's quite useful. 17:31:06 <s3wong> yamahata: and perhaps not as controversial :-) 17:34:06 <yamahata> anything else to discuss? 17:34:18 <s3wong> yamahata: that's it for me 17:34:31 <SridharRamaswamy> thats it for me.. 17:34:37 <s3wong> SridharRamaswamy: although you may want to put the list of initial functionality on wiki page also 17:34:44 <SridharRamaswamy> will do 17:34:49 <yamahata> SridharRamaswamy: cool. 17:34:51 <s3wong> SridharRamaswamy: thanks 17:35:00 <yamahata> thanks everyone. bye 17:35:06 <SridharRamaswamy> bye folks 17:35:07 <yamahata> #endmeeting