05:07:49 <yamahata> #startmeeting neutron/servicevm
05:07:50 <openstack> Meeting started Tue May  6 05:07:49 2014 UTC and is due to finish in 60 minutes.  The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:07:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:07:53 <openstack> The meeting name has been set to 'neutron_servicevm'
05:08:08 <yamahata> #link https://wiki.openstack.org/wiki/Meetings/ServiceVM
05:08:15 <yamahata> For agenda
05:08:27 <yamahata> #topic status update
05:09:12 <yamahata> In the community, there is a consensus that servicevm should be an independent project moving out of Neutron
05:09:34 <yamahata> A session will be held at the next summit.
05:09:45 <bmelande> Last day, last session :-)
05:10:04 <s3wong> still consider a Neutron design session
05:10:13 <yamahata> Yea, the last session. So we don't have discussion time after the session.
05:10:35 <yamahata> Wondering unconference before neutron session. i.e. Monday or Tuesday
05:10:54 <hareeshpc> yes..it is a good idea..
05:11:04 <s3wong> need to go there early to grab an unconference slot
05:11:14 <hareeshpc> friday evening is too late to get some discussion
05:11:35 <yamahata> Does monday works for you?
05:11:49 <hareeshpc> yes
05:11:53 <yamahata> I'm arriving there on Sunday.
05:12:05 <bmelande> works for me too
05:12:18 <yamahata> Great
05:12:32 <s3wong> Monday is good, I only have a group-policy get-together from 2-3pm
05:13:11 <yamahata> Okay. Then morning or evening?
05:13:53 <s3wong> around 5pm maybe, before dinner?
05:14:14 <hareeshpc> ya
05:14:19 <bmelande> Yes that could work
05:14:38 <yamahata> #agreed unconference Monday 5pm-
05:15:10 <yamahata> I'm not sure about the place. Maybe we can secure the unconference room. At worst developer loundge.
05:15:16 <s3wong> whatever goes to the unconference board earliest sign up for the Monday 5pm slot :-)
05:15:22 <s3wong> s/whatever/whoever
05:15:32 <yamahata> nice idea.
05:15:59 <yamahata> #action whoever geots to the unconference board and secure the room
05:16:05 <hareeshpc> ok
05:16:21 <yamahata> #link https://etherpad.openstack.org/p/servicevm
05:16:28 <yamahata> It's summit etherpad
05:16:37 <yamahata> #action yamahata update the etherpad
05:17:16 <yamahata> The etherpad already include the schedule at the real session.
05:17:33 <hareeshpc> We need to add more details into the etherpad. hows your plan and division of work to do that?
05:18:07 <hareeshpc> or what all should go there?
05:19:02 <yamahata> I think, at the session we would discuss a plan for shortterm and longterm.
05:19:30 <bmelande> Sorting out and getting agreement on that is important yes.
05:19:33 <yamahata> I mean what Cisco want to include in Juno and introducing new independent project and its transition plan
05:19:56 <yamahata> bmelande: agree. Do you have items?
05:20:59 <yamahata> As for long term plan, tasks to do is terminology and api/datamodel design, determine review way with stackforge
05:21:02 <bmelande> Basically what is covered by the blueprints that we now have on review
05:22:28 <yamahata> bmelande: I think it's for Juno plan, right?
05:22:34 <bmelande> For review process mayby adopt the neutron way from day 1, is that feasible=
05:22:36 <bmelande> ?
05:22:59 <yamahata> bmelande: Yes, that's exactly what I'm proposing.
05:23:12 <yamahata> For spec review, we can follow xxx-specs way
05:23:25 <yamahata> with gerrit
05:23:46 <s3wong> yes, so far, in Neutron, it proves to be much more efficient (gerrit for spec review)
05:23:58 <bmelande> yamahata: Yes, exactly. As a gap filler and then we can transition to use flavor framework, any new modular l3 routing plugin and the framework of the new stackforge project
05:25:23 <s3wong> service context will also likely go away (well, it was never accepted anyway)
05:25:50 <yamahata> bmelande: those are the gaps.  the framework of the new stackforge would be the biggest issue.
05:26:31 <yamahata> bmelande: your blueprint tries to introduce new REST API in Neutron. So people would ask the transition plan.
05:27:10 <yamahata> Maybe it will be discussed at the summit, we should prepare for the answer
05:28:10 <bmelande> yamahata: yes, it does right now.
05:29:14 <yamahata> it's too big topic, we can continue to discuss on mailing list or else
05:29:19 <bmelande> yamahata: it would be possible to replace that in a gap fill by config files
05:29:54 <yamahata> bmelande: sounds great. It could be in blueprint
05:31:15 <hareeshpc> The config agent and its associated components are still in neutron, right?
05:31:43 <balajip> hi
05:32:19 <balajip> anybody on servicevm discussion here
05:32:44 <yamahata> For short term, yes I think. In long term, it will be split into common library and device specific code in Neutron, I think.
05:32:45 <s3wong> Yes, yamahata, hareeshpc, bmelande, and s3wong
05:32:57 <s3wong> that was for balajip
05:33:02 <yamahata> balajip: yes.
05:33:11 <balajip> ok cool
05:33:32 <yamahata> We agreed unconference on Monday 5pm-.
05:33:39 <yamahata> balajip: will you come to Atlanta?
05:34:01 <yamahata> #topic session agenda
05:34:13 <yamahata> We are discussing agenda of the session
05:34:14 <balajip> yamahata:no, we have freeze on travel right now.
05:34:21 <balajip> ok
05:34:35 <yamahata> balajip: that's pitty.
05:35:21 <balajip> yamahata:so every body in the group agreed to make servicevm as another project?
05:35:56 <yamahata> balajip: From the discussion of openstack-dev, I understand it's the consensus.
05:36:03 <yamahata> No one opposed
05:36:07 <balajip> ok..good.
05:36:34 <yamahata> Back to the agenda.
05:36:35 <bmelande> But there needs to be a smooth way to transition to that
05:36:53 <balajip> yamahata:so is it like servicevm will be in incubation stage?
05:37:30 <yamahata> balajip: That's the plan. I'll create the repo on stackforge after the summit
05:37:45 <balajip> ok..thanks..
05:37:49 <yamahata> I added the section at the etherpad.
05:38:01 <balajip> sorry to drag you from discussion agenda..
05:38:02 <bmelande> Are the folks engage in other services that have expressed interest? Or are they perhaps not aware of this?
05:38:23 <yamahata> bmelande: hareeshpc  what else topic do you want to add?
05:38:47 <s3wong> bmelande: I am part of the advanced service subgroup, and we are interested in the progress of serviceVM
05:39:19 <yamahata> bmelande: So far only unified agent people expressed interest in the context of oslo.messaging
05:39:31 <bmelande> s3wong: Yes, though I was more thinking of other openstack projects. Are they awware/interested?
05:40:07 <yamahata> Nothing else from Neutron project as long as I know.
05:40:25 <yamahata> * other than
05:40:41 <s3wong> bmelande: I vaguely remember someone from Nova has ask yamahata to put the serviceVM project to Nova on the ML
05:41:30 <yamahata> s3wong: I could have missed it. I'll check it later.
05:41:55 <bmelande> s3wong: aha, ok.
05:42:41 <gduan> Hi, this is Gary, I'm mostly working on FWaaS
05:42:51 <yamahata> gduan: hi
05:42:51 <gduan> I am interested in serviceVM too
05:43:19 <gduan> yamahata: hi
05:43:52 <bmelande> gduan: Hi Gary bob melander@cisco here too.
05:44:00 <gduan> Hi, Bob
05:44:00 <balajip> s3wong:I remember Kyle proposed to make it as independent project based on the discussion like adding to the Nova etc.
05:44:34 <balajip> gudan:Hi Gary balajip@freescale here
05:44:35 <bmelande> I'd say it belongs more in Neutron given current use cases
05:44:48 <s3wong> balajip: yes, when I saw mestery 's email - I thought it was based on interests from other OpenStack projects outside of Neutron
05:45:59 <bmelande> s3wong: but now it sounds like the extent of that interest is unclear
05:46:34 <s3wong> bmelande: right. I have not seen any follow-up from Nova on this
05:47:00 <s3wong> bmelande: so I don't doubt the initial interests would likely be from Neutron community only
05:47:01 <balajip> s3wong:IMHO it would be better to have it as OpenStack Project as servicevm needs to have VM and Network information
05:47:26 <bmelande> In general, I think it is important to keep a close tie to Neutron since that is where the use cases are which are best understood
05:47:55 <hareeshpc> bmelande: thats my view too.
05:48:23 <s3wong> bmelande: as long as serviceVM module doesn't make Nova calls directly :-)
05:48:36 <balajip> bmelande:it needs work closely with Nova and Neturon services.
05:48:49 <bmelande> Yes, that is true. At the moment we don't use more than novaclient
05:49:07 <yamahata> bmelande: right.
05:49:30 <bmelande> Though it would be nice to be able to influence the scheduling of VMs used for Neutron service. We do some experimental work on that.
05:49:38 <yamahata> bmelande: Do you have any discussion against moving out of Neutron?
05:49:56 <balajip> bmelande:agreed.
05:50:09 <s3wong> bmelande: that's policy based scheduling - there are at least several Nova projects on this
05:50:18 <yamahata> bmelande: I think, the scheduling would be converged into Gantt project. It would take a while though.
05:51:58 <bmelande> yamahata: in our implementation we have reasoned like this: there are several essentially independently running service plugins that want to implement devices/backends that are multi-service capabe
05:52:10 <bmelande> s/capabe/capable
05:52:51 <bmelande> There then needs to be some way of keeping track of those devices, in particular VMs, and their lifecycle.
05:53:16 <yamahata> bmelande: Agree with closely tieing servicevm/device manager with Neutron
05:53:56 <bmelande> Then there is the "plugging" aspects which I think creates strong ties to neutron
05:54:20 <s3wong> yamahata: also serviceVM needs to conform to service insertion model to enable traffic steering and service chaining to operate on serviceVMs
05:55:05 <bmelande> I have a easier time to see how things relate and can interwork when inside Neutron, implications when they are further "apart" is less clear to me at this point.
05:55:15 <gduan> bmelande: is your concern that different plugins, for example, VPN, FW, have to sync calls to the device?
05:55:25 <yamahata> I agree with those discussion.
05:55:37 <bmelande> That is why I think we should have a short-term perspective and longer-one and transition in a good way (whatever that is).
05:55:39 <yamahata> But the issue is to convince other developers. Not here
05:55:41 <balajip> bmelande:is it like the servicevm will be used for both devices/backends and as well virtual forms [network services in VM]
05:56:29 <bmelande> balaji: what I mean is that service VM can host Neutron routers, Neutron FW, etc.
05:56:30 <yamahata> Otherwise we wouldn't get review and it would be difficult to make progress
05:56:47 <bmelande> yamahata: Yes, I realize that too.
05:57:25 <balajip> bmelande:so we are proposing to move neutron routers, neutron fw etc to servicevm?
05:57:48 <bmelande> gduan: yes, all those plugins are rather independent.
05:58:13 <yamahata> If we want to stay in Neutron in long term, we have to fight in openstack-dev openly.
05:58:43 <bmelande> balaji: No, servicevm is just one type of "host" for such service instances.
05:58:58 <bmelande> I
05:59:08 <balajip> bmelande:ok
05:59:26 <gduan> bmelande: in our implementation, we sync FW calls and Router calls to one process
05:59:27 <hareeshpc> I think bmelande is suggesting that we stay in neutron enough to catch all the finer details and requirements from neutron
05:59:29 <s3wong> yamahata: did mestery give a concrete reason to move serviceVM out of Neutron?
06:00:15 <yamahata> s3wong: The reasoning is that it's generic enough to serve project other than Neutron.
06:00:37 <gduan> bmelande: this question is if this logic can be generalized and should it be in Neutron or serviceVM?
06:00:40 <yamahata> And some backed it. I felt It's quite difficult to fight against it.
06:00:48 <balajip> bmelande:i think if we want to increase the scope for servicevm project, some thing like overlapping with Neutron as well , then we need to have broader consensus on this
06:01:45 <yamahata> Anyway we are running out of time. We could continue.
06:02:05 <yamahata> The action item is
06:02:26 <bmelande> wait, so I don't confuse things here. I'm not argueing a serviceVM project should handle/implement network service. That belongs in Neutron
06:02:56 <yamahata> fix agenda for the session in etherpad. We'll continue off line. I'll send a mail.
06:02:56 <hareeshpc> One quick question. Does configuring a VM for a particular network service still part of Neutron or part of service VM?
06:02:58 <s3wong> bmelande: certainly
06:04:13 <balajip> bmelande:thanks for clarification
06:04:29 <gduan> hareeshpc: "configuring" means rest calls to the backend device?
06:04:36 <hareeshpc> yes.
06:04:55 <gduan> IMO, it should be in Neutron
06:04:58 <hareeshpc> the driver component and also  an agent to fetch data from plugin
06:05:20 <s3wong> hareeshpc: that's definitely Neutron
06:05:33 <gduan> right
06:05:34 <hareeshpc> ok
06:06:02 <s3wong> hareeshpc: driver and agent are service specific, actually - even vendor specific
06:06:23 <hareeshpc> s3wong: indeed
06:06:42 <gduan> What I think about ServiceVM is to maintain VM's lifecycle based on service requests
06:06:44 <hareeshpc> but they are closely tied to the VM being configured, which seems out of Neutron
06:06:57 <s3wong> hareeshpc: now, what I can see is if tenants are bringing in their own service, which isn't supported by Neutron
06:07:21 <bmelande> gduan: Yes, that is definitely a core task for serviceVM
06:08:14 <gduan> s3wong: I think service insertion BP considers the external services, right?
06:08:56 <gduan> s3wong: by using service port, that's one of proposals?
06:09:01 <s3wong> gduan: it does, that's when the VM needs to register to have a ServiceBase object to identify its connection points
06:10:06 <yamahata> s3wong: great. Pointer of it?
06:11:01 <s3wong> yamahata: you mean the document?
06:11:16 <yamahata> s3wong: service insertion BP
06:11:35 <bmelande> s3wong: I've looked at that service port doc. I was unsure how I would model a VM with a set of VIFs that carry VLAN tagged packets so that a service instance port maps to a logical interface for one of the VLANs
06:12:08 <s3wong> yamahata: SumitNaiksatam has the high level doc in gerrit reivew, the service insertion doc is here: #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit
06:12:20 <gduan> bmelande s3wong: I don't think that's covered
06:12:22 <s3wong> will put it in gerrit prior to the summit
06:13:00 <yamahata> Anyway I close the meeting once. we could continue.
06:13:04 <yamahata> #endmeeting