05:01:05 <yamahata> #startmeeting servicevm-device-manager
05:01:06 <openstack> Meeting started Tue Jun 10 05:01:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:01:10 <openstack> The meeting name has been set to 'servicevm_device_manager'
05:01:22 <yamahata> #topic Announcement
05:01:42 <yamahata> created irc channel on freenode #tacker
05:01:58 <yamahata> requested repository on stackforge. it's under review
05:02:08 <yamahata> #link https://review.openstack.org/#/c/97435/
05:02:30 <s3wong> OK
05:03:05 <hareeshpc> ok
05:03:30 <yamahata> #topic nfv follow up
05:04:24 <yamahata> As BP for NFV support,  two Blueprints for vlan trunking and unfirewall-unaddress  are proposed by Ian.
05:05:04 <yamahata> Regarding vlan trunking, I think it's mostly same to vlan-aware-vm/l2-gateway. So we need to coordinate it.
05:05:30 <alonha> Can you point to the blueprints?
05:05:53 <yamahata> #link https://review.openstack.org/#/c/97714/
05:06:00 <s3wong> yamahata: I think mestery agrees with your -1 on the VLAN trunking bp
05:06:03 <yamahata> #link https://review.openstack.org/#/c/94612/
05:06:12 <s3wong> it is redundant to what has been filed
05:06:17 <yamahata> #link https://blueprints.launchpad.net/neutron/+spec/l2-gateway
05:06:25 <yamahata> no neutron-spec for the last one
05:06:40 <yamahata> s3wong: Yes.
05:07:09 <bobmel> Hi all! bob melander here. Sorry for being late.
05:07:12 <yamahata> I pinged Eric, but haven't got any reply.
05:07:16 <yamahata> bobmel: hello
05:07:20 <yisun> but no one is working on L2 GW
05:07:20 <s3wong> yamahata: also, ijw filed another on having two interfaces to same network bp
05:07:33 <yamahata> bobmel: It's early morning there?
05:07:36 <s3wong> bobmel: changed your handle already? :-)
05:07:59 <sweston> yamahata: late evening :-)
05:08:03 <bobmel> yamahata: yes, early morning and I'm more of a evening guy :-)
05:08:08 <yisun> Does anyone know who is working on L2 GW?
05:08:15 <yamahata> I'm willing to write l2gw or update vlan-ware-vlan spec.
05:08:22 <yamahata> or anyone volunteer?
05:08:45 <s3wong> yisun: I believe someone from Ericsson
05:08:51 <yisun> But what is the problem to let Eric to continue?
05:08:58 <yisun> Eric is from Ericsson
05:09:08 <yisun> But L2 GW I don’t think so
05:09:15 <bobmel> yisun: Stephan baucke and Rasha Ben Ali, both ericsson
05:09:40 <yisun> But the owner of L2 GW is Rossella Sblendido
05:09:48 <yisun> I’m reading the wrong one?
05:10:11 <bobmel> ok, aha, has it changed recently?
05:10:26 <yamahata> yisun: the issues is Eric is not responsive recently.
05:10:26 <yisun> No, it was like that a year ago
05:10:29 <bobmel> Stephan and Rasha also have some l2gw blueprint I beleive
05:10:45 <garyduan> Hi, sorry, I am late
05:10:52 <yamahata> garyduan: hi.
05:11:01 <yisun> Ok, little history about these vlan or L2 thing
05:11:04 <garyduan> yamahata: hi
05:11:09 <yamahata> I'm wondering how we can accelerate or make things progress.
05:11:28 <yisun> In the Hongkong summit, I was trying to consolidate the efforts, only ERIC responsed and worked on it
05:11:47 <yisun> no one else make any progress since then other than Eric
05:11:54 <yamahata> Okay, I'll update BP unless Eric does.
05:12:08 <yamahata> Then we'll see how the spec review goes
05:12:09 <s3wong> the one rossella_s filed was a while back, so not sure if she is still going to work on it
05:12:34 <yamahata> s3wong: can you ping him?
05:12:35 <yisun> I really think she is from Midocura :-)
05:12:44 <s3wong> similar to the port mirroring bp, the one implementing it doesn't need to be the one filing the bp
05:12:45 <yamahata> her?
05:12:56 <s3wong> yisun: she used to be, she is now at SUSE :-)
05:13:06 <s3wong> yisun: she filed it when she was with Midokura
05:13:20 <yamahata> s3wong: okay
05:13:26 <s3wong> yamahata: yes, I can ping rossella_s to see if she is still interested in implementing it
05:13:45 <yamahata> #action yamahata update BP, see how review goes unless eric does.
05:13:57 <yamahata> #action s3wong ping rossella_s
05:14:07 <yisun> Yamahata, by the BP, you meant L2 GW?
05:14:17 <yamahata> Yes L2Gw.
05:14:33 <yisun> Ok
05:14:41 <yamahata> If rossella_s write it, it's great. otherwise I'll take it.
05:15:00 <yamahata> the next blueprint is unfirewall/unaddressed port
05:15:21 <yamahata> #link https://review.openstack.org/97715
05:15:28 <yamahata> It's also by Ian.
05:15:52 <yamahata> The proposal is, unfirewall == unaddressed.
05:16:08 <yamahata> Do we want to separate them?
05:16:26 <yamahata> I mean unfirewalled port with address and unfirewalled port without address.
05:17:08 <yisun> Yamahata: why do you want to separate them?
05:17:21 <alonha> Maybe the more proper term is 'trusted port'?
05:18:02 <yamahata> yisun: Yes, I though. I'm not sure if there is a use case.
05:18:13 <yamahata> Only unfirewalled port without address is okay?
05:18:42 <yisun> Gary: we have such a port, right?
05:19:04 <bobmel> Router ports would be one example
05:19:05 <garyduan> it could be unfirewalled but with address
05:19:06 <yamahata> For router vm case, port needs IP address without firewall.
05:19:20 <s3wong> yamahata: yisun: garyduan: this is port without security group, right?
05:19:38 <garyduan> right
05:19:47 <yamahata> s3wong: yes.
05:19:48 <yisun> s3wong: it does not have IP either
05:20:04 <s3wong> yamahata: we also need port that isn't attached to any subnet, thus port w/out IP
05:20:50 <yamahata> s3wong: Does it mean unaddressed? Is the port associated to only network?
05:20:53 <yisun> Here is one more case, that I don’t know which buck it fits
05:21:17 <yisun> I have a redundant ports to back up each other
05:21:32 <yisun> and both them have the same MAC and IP
05:22:19 <s3wong> yamahata: IP address assigned to VM is from user specifying which network the port belongs to; if we want to create VM with a port that is not attached to any network, it seems reasonable that it has to be without any IP address
05:22:22 <gongysh> for router vm,  we need to remove anti spoof chain.
05:23:41 <s3wong> yisun: sounds like a different bp
05:23:55 <s3wong> need to update that requirements on our list
05:23:56 <gongysh> w3wong:  not attached to any network -> not attached to any subnets?
05:24:04 <yisun> s3wong: could be
05:24:27 <yamahata> There are many requirements for port attributes. I'll create wiki page for it.
05:24:39 <yisun> all: bascially, for the service VM, we may have to disable all firewall checks
05:24:42 <yamahata> Then we can summarize use case and requirement. then break down to BPs
05:24:51 <yamahata> #action yamahata create wiki page for port attributes
05:24:53 <yisun> yamahata+1
05:24:57 <s3wong> gongysh: not attached to any network or subnet, in a serviceVM pool, ideally, we don't set the VM interface attachment and its IP address until we know which network we want to attach the port to
05:25:07 <s3wong> yamahata: that is definitely a good idea
05:25:29 <yisun> s3wong: in that case, we can create vnic and plugin network when we need
05:25:31 <bobmel> yamahata: +1
05:25:35 <garyduan> there is a case that one port can server multiple networks
05:25:49 <s3wong> yisun: can we create VM without any port initially?
05:26:07 <yamahata> At least the consensus is Ian's proposal should be split/enhanced into some BPs.
05:26:09 <s3wong> garyduan: is it supported today?
05:26:10 <yisun> s3wong, I think you need a vnic for mgt at least
05:26:26 <garyduan> s3wong: in neutron, no
05:26:32 <natarajk> yisub: that's correct
05:26:42 <natarajk> you need atleast one for mgmt for service vm
05:27:14 <s3wong> yisun: OK - that's cool, since yamahata is introducing mgmt interface concept, that could be the first interface for serviceVM
05:27:19 <yisun> natarajk: the is the basic requirement and any other interfaces can be create on daemon
05:27:34 <yisun> s/the/this/
05:27:54 <bobmel> natarajk: yisun: unless you do management by RPC proxy
05:28:02 <yamahata> I create wiki page
05:28:06 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
05:28:14 <yamahata> just blank yet.
05:28:24 <bobmel> natarajk: yisun: Then you may not have mgmt vnic
05:28:37 <yisun> bobmel: why?
05:28:43 <yamahata> #action anyone update wiki page with usecase/requirement
05:28:50 <natarajk> bobmel: i meant we need atleast one for mgmt
05:29:03 <yisun> natarajk:+1
05:30:28 <bobmel> yisun: natarajk: I was referring to mgmt done as specified here: https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server
05:30:59 <s3wong> bobmel: I think yisun and others are saying having a mgmt intf is a basic requirement for serviceVM
05:31:25 <yamahata> bobmel: the blueprint needs to be updated according to the discussion at the summit
05:31:55 <yamahata> The first target is to build RPC over marconi.
05:32:14 <yisun> bobmel: I need to read the bp, but shouldn’t we at least have an interface that we can send restful request?
05:32:48 <yamahata> I mean "enhancing neutron metadata agent and use notification over HTTP" section
05:33:22 <bobmel> s3wong: Ok, that I agree with. Just need not necessarily be a network interface,
05:33:52 <garyduan> Are we still talking neutron port attributes?
05:34:48 <yamahata> Seems no.
05:34:59 <yamahata> that's all from me as nfv follow up?
05:35:04 <s3wong> yamahata: mgmt interface is NOT Neutron port, isn't it?
05:35:07 <yamahata> anthing else?
05:35:32 <yamahata> s3wong: mgmt interface can be non-neutron port.
05:35:49 <yamahata> s3wong: But Neutron port can be mgmt port. That's the first goal.
05:35:52 <s3wong> garyduan: so what yamahata said above ^^^^^
05:36:03 <s3wong> garyduan: not necessarily about neutron port
05:36:10 <s3wong> yamahata: thanks!
05:37:12 <yamahata> #topic open discussion
05:38:12 <yamahata> When tacker-spec repository is created, I'd like to start spec review of Rest api of device manager.
05:38:14 <garyduan> yamahata: I was not able to attend last week's meeting
05:38:24 <yamahata> garyduan: no problem.
05:38:29 <garyduan> yamahata: do we have these BP listed somewhere?
05:38:45 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items
05:38:56 <alonha> What is the differenc between this group and the new NFV one? Aren't both deal with the same problems?
05:39:00 <yamahata> you also want to see
05:39:04 <yamahata> #link https://wiki.openstack.org/wiki/Meetings/NFV
05:39:23 <garyduan> thanks
05:39:29 <s3wong> alonha: at least at this point, the tacker team has not talked about things like how to saturate a 40G link
05:40:19 <alonha> Sorry, what is tacker team?
05:40:22 <yamahata> aloga: Maybe, we're understanding the difference. If BPs is covered by BP, it can be under NFV unbrella.
05:40:33 <s3wong> alonha: sorry, the ServiceVM team :-)
05:40:51 <yamahata> covered by *NFV*
05:41:23 <yamahata> aloga: serviceVM/device manager is not always covered by NFV.
05:41:43 <yamahata> aloga: off course we'll work closely with NFV. Maybe subteam of NFV?
05:41:54 <garyduan> In general, I think we are not able to address all of the requirements. We need to identify several issues we must address first.
05:42:32 <alonha> So, for now, two different groups?
05:42:35 <s3wong> garyduan: agreed, and based on last week's meeting, the general consensus is the serviceVM team will prioritize NFV use cases to address
05:42:54 <s3wong> alonha: at this point, the NFV subteam's mission is to gather requirements and file bps
05:43:06 <alonha> ok, thanks.
05:43:15 <s3wong> alonha: OTOH, serviceVM team is here to get implementation / design done
05:43:43 <alonha> got it, thanks,
05:44:39 <yamahata> anything else to discuss?
05:44:43 <yisun> BTW— I got a new requirement today, not solid, but worth to share
05:45:02 <yisun> We are doing performance tuning on our service VM.
05:45:29 <yisun> We were trying to add some early random drop logic
05:45:46 <yisun> but we can not find a good trigger for it. Since we have not clue on the hypervisro load
05:46:06 <yisun> Even in the VM, our CPU usage is ok, but hypervisor may be already out of CPU.
05:46:36 <yisun> So, in order to issue something accurate, some hypervisor resource usage visibility may be helpful
05:46:49 <yamahata> yisun: somthing like feeding some statistics of ceilometer to inside VM?
05:47:17 <yisun> yamahata: there was one of thing I was thinking
05:47:19 <yamahata> sounds interesting
05:47:46 <s3wong> yisun: yamahata: wonder if Ceilometer (used mostly for tenant) can cover hypervisor stats
05:48:01 <yisun> yamahata: since this is only the first a few day that I’m looking into this, so it is not a solid idea yet, I will report back when I get more
05:48:27 <yamahata> s3wong: At worst we can write a driver to gather such info
05:48:35 <yamahata> s3wong: I guess there already is, though
05:48:43 <s3wong> yamahata: OK
05:49:31 <garyduan> I remember there was discussion at Neutron pod at Atlanta
05:50:02 <garyduan> talking about gathering traffic info by agent
05:51:36 <yamahata> nothing more?
05:51:57 <yamahata> Okay let's review blueprint and update port attributes page
05:51:59 <s3wong> garyduan: so that is a fair requirements, you can put that into serviceVM wiki
05:52:18 <bobmel> yamahata: I just added one about the sec group disable
05:52:30 <yamahata> bobmel: thanks
05:53:00 <yamahata> see you next week or nfv meeting
05:53:06 <yamahata> #endmeeting