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