05:04:48 <yamahata> #startmeeting servicevm-device-manager
05:04:49 <openstack> Meeting started Tue Jun  3 05:04:48 2014 UTC and is due to finish in 60 minutes.  The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:04:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:04:52 <openstack> The meeting name has been set to 'servicevm_device_manager'
05:05:08 <yamahata> thank you for attending servicevm meeting
05:05:18 <yamahata> #link https://etherpad.openstack.org/p/servicevm
05:05:32 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM
05:05:43 <ChristianM_> Could you remind the discussion and conclusion if any of the Atlanta session in Neutron ?
05:05:46 <yamahata> #link https://wiki.openstack.org/wiki/Meetings/ServiceVM
05:06:07 <s3wong> bmelande: Hi
05:06:08 <yamahata> #topic design summit followup
05:06:20 <bmelande> All: Hi
05:06:34 <yamahata> bmelande: hi. The meeting has just started.
05:07:00 <bmelande> yamahata: ok
05:07:06 <yamahata> The conclusion at Atlanta is that servicevm/device-manager project should be out of Neutron
05:07:37 <yamahata> So we will start a new project for separated service
05:08:09 <ChristianM_> ok
05:08:34 <balajip> yamahata: Is it like, ServiceVM should not use Neutron resources?
05:08:36 <yamahata> unite for starting incubation process and gather/attract contributer.
05:08:56 <yamahata> balajip: Yes, serviceVM will use Neutron.
05:09:05 <s3wong> and Nova
05:09:28 <yamahata> life cycle management of services, VMs should be separated out.
05:09:35 <balajip> yamahata: ok
05:09:39 <yamahata> Network related part will remain in Neutron.
05:09:42 <bmelande> And all(?) initial use cases will be for neutron (advanced) services
05:10:12 <ChristianM_> Currently is there any service which is not neutron related ?
05:10:49 <yamahata> ChristianM_: I'm not aware of such services so far.
05:11:33 <gongysh> We need to identify as we go.
05:11:53 <ChristianM_> OK. Networking aspect stays in Neutron and life cycle moves out to Nova ?
05:12:36 <yamahata> life cycle management of services/VM is part of servicevm service.
05:12:38 <yamahata> Not nova.
05:12:42 <malini1> Is lifecycle -- starting/pausing/stoping VMs not already covred by nova? what is specific to lifecycle management for NFV VMs?
05:12:57 <balajip> ChristianM_:ServiceVM needs both Nova and Neutron as it has to deploy Network services
05:13:00 <yamahata> Nova will be used just to spin up/down VMs
05:13:31 <yamahata> As follow-up, I create a draft of incubation-applicatin page
05:13:40 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/Incugbation
05:13:58 <ChristianM_> It looks like there is nova for spin up/down the VM, serviceVM for life cycle mgmt but what is it exactly and then neutron for network connectivity
05:14:23 <yamahata> I also summarized request for Neutron/other page.
05:14:27 <malini1> yamahata: using nova to spin up/down VMs -- what is left for life cycle management?
05:14:32 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items
05:15:05 <gongysh> Incugbation -> Incubation?
05:15:09 <yamahata> malini1: life cycle management of services. e.g. pooling VMs/services
05:15:17 <bmelande> malini1: if, say, you want a pool of standby VMs that are idle by already booted, then maintaining that pool could be part of life cycle managnentm
05:15:21 <yamahata> gongysh: ouch. will fix
05:15:54 <balajip> yamahata:Also, we have to define the relation between NFV sub team and ServiceVM team
05:16:38 <s3wong> balajip: agreed. The NFV subteam currently is handing out requirements, and they would have to give us requirements for serviceVM
05:16:42 <yamahata> balajip: Yes, tomorrow, there is NFV irc meeting.
05:16:47 <ChristianM_> balajip: Should the serviceVM be the VM services used for NFV ?
05:16:58 <malini1> yamahata: ah, pooling. do we anticipate a lot of pooled VMs waiting be deployed?  would it make sense to defer "life cycle management" to a later phase, that is not support pooling initially?
05:17:06 <balajip> yamahata: Am little concerned that these two sub-groups may do the same tasks.
05:17:08 <yamahata> So far I have been challenged if servicevm is not needed.
05:17:37 <ChristianM_> yamahata: Is needed or is not needed ?
05:17:41 <s3wong> ChristianM_: serviceVM is considered one of the projects needed by NFV: https://wiki.openstack.org/wiki/Meetings/NFV
05:17:43 <balajip> ChristianM_:Iam assuming
05:17:51 <yamahata> #link https://wiki.openstack.org/wiki/Meetings/NFV
05:18:20 <yamahata> ChristianM_: some said servicevm is NOT needed for NFV
05:18:50 <yamahata> But I think serviceVM corresponds to VNF manager
05:18:56 <balajip> ChristianM_:IMHO,it is needed and both of them will be very tightly coupled.
05:19:21 <ChristianM_> This is my assumption also but we need to show how they're complementary
05:19:44 <gongysh> VM based NFV is naturally distributed and software defined.
05:20:09 <yamahata> gongysh: fixed link
05:20:15 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/Incubation
05:20:25 <ChristianM_> Pool of VM might be important for fault-tolerance in the NFV context
05:20:52 <yamahata> Before detailed discussion, can I raise logistics staff?
05:21:07 <yamahata> Can you please add your names to incubation page and your bio.
05:21:07 <ChristianM_> sure
05:21:27 <s3wong> yamahata: what needs to be included in bio?
05:21:37 <yamahata> #action everyone add your name/bio to contributor of incubation page
05:21:39 <malini1> yamahata: sure
05:22:08 <yamahata> s3wong: section "Project developers qualifications" needs it. very simple bio would be ok.
05:22:13 <bmelande> It looks to me like what is listed so on NFV page is fixes needed in Nova and Neutron.
05:22:57 <bmelande> yamahata:Ok will add
05:23:00 <s3wong> bmelande: needed development (not yet started)
05:23:55 <yamahata> Regarding to neutron side, I summarized requirement for neutron in etherpad into matrix.
05:24:01 <malini1> ChristiamM_: what do you mean by fault tolerance? Like HA for load balancing? That I would consider as single distributor VM passing on the work to the actual handlers
05:24:09 <balajip> yamahata:sure, Also i think we should make some quick decisions on ETSI - NFV also like should we follow similar nomenclature and as well architecture etc
05:24:13 <yamahata> I think we can address those items parally.
05:24:27 <ChristianM_> Malini1: yes
05:24:50 <yamahata> balajip: you mean terminology and so on? yes.
05:25:09 <balajip> yamahata: yes
05:25:12 <yamahata> I created terminology wiki page. But gerrit would be better.
05:25:23 <s3wong> balajip: that sounds like the NFV subgroup issue, right? Should the serviceVM subteam to conform to NFV terminologies, or is it more NFV subteam's problem?
05:25:29 <malini1> balajip: does rest of neutron adopt ETSI nomenclature? what about OpenDayLight?
05:25:29 <yamahata> #action yamahata create tacker-specs page
05:25:39 <yamahata> #undo
05:25:40 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x250a4d0>
05:26:01 <yamahata> #action yamahata create tacker-specs repo in stackforge for further discussion on terminology
05:26:01 <s3wong> malin1: not us in advanced services, we don't care much about NFV terminology
05:26:28 <yamahata> #link https://wiki.openstack.org/wiki/ServiceVM/terminology
05:26:38 <s3wong> malin1: and so far, there is a project filed by Contextstream and Ericsson on service chaining on ODL, but not sure if they follow NFV terminology
05:26:41 <balajip> s3wong:IMHO, ServiceVM is superset of NFV sub-team
05:27:50 <balajip> malini1:Neutron may not need to adopt ETSI nomenclature, but Service VM must follow ETSI for adoption of NFV based deployments using OpenStack
05:28:22 <s3wong> balajip: well, we will see on Wednesday. So far, the NFV subgroup mission statement seems to point to requirement generation
05:28:29 <gongysh> sorry, what does  ETSI stand for?
05:28:54 <yamahata> gongysh: http://www.etsi.org/technologies-clusters/technologies/nfv
05:29:01 <yamahata> #link http://www.etsi.org/technologies-clusters/technologies/nfv
05:29:02 <ChristianM_> gongysh: Europen Telecom Standars Institute
05:29:12 <gongysh> got it, thanks
05:29:14 <balajip> gongysh:European Telecom Standards Institute whose is leading the NFV architecture for deployments
05:29:44 <malini1> balajip: ok ETSI nomenclature -- :-) unless the Americas have another nomenclature +1
05:30:38 <balajip> malini1:agreed, but if you see for NFV all other projects like ONF, ODL are following ETSI!!
05:30:41 <s3wong> malini1: actually Verizon is one of the leaders of this effort in ETSI, so us Americans are contributing there too :-)
05:30:47 <yamahata> anyway we need to converge terminology between two implementation.
05:31:03 <yamahata> though that, we also see NFV terminology
05:31:26 <yamahata> s/though/through/
05:31:35 <balajip> yamahata:agreed, lets define the scope and goal for service VM.
05:31:41 <malini1> Cool. ETSI +1 stands then. From a requirements standpoint .. what would each of you want and need to plugin your special NFV. what would be minimal useful milestones
05:32:10 <yamahata> balajip: agree with defining scope.
05:32:12 <gongysh> first, I need a routerVM implemneted.
05:32:21 <yamahata> I wrote a draft in incubation page.
05:33:07 <balajip> yamahata:lets work on consensus for the draft in incubation page and any other updates to it,
05:33:13 <yamahata> I think, it's consensus that service for life cycle management is included
05:33:25 <balajip> yamahata:ok
05:33:41 <gongysh> yamahata: the vm pool is a good one
05:33:44 <yamahata> it is being discussed whether NFV is in its scope or not
05:34:32 <yamahata> What's the issues to include NFV to its scope?
05:34:50 <balajip> yamahata:IMHO, it must be there. Comments from the team will be good.
05:35:11 <s3wong> yamahata: if we want a vm pool, then we need to several changes to Nova / Neutron: (a) should be able to create VM without having a Neutron port, and (b) able to unplug a VM's Neutron port from a Neutron network
05:36:29 <yamahata> s3wong: My point is not technical detail. My question is, is there any reason to exclude NFV out of servicevm project?
05:36:29 <gongysh> s3wong; I guess by a pool of vm, these vm should be spun up already, they just are not in position.
05:36:46 <yamahata> Or NFV should be included in its scope?
05:36:55 <malini1> s3wong: today nova lets us launch multiple VMs with the same glance image .. how is VM pool different for NFVs?
05:37:14 <bmelande> yamahata: I think serviceVM should support NFV use cases - if not we'll be obsolete
05:37:52 <gongysh> bmelande: agreed,  what are left to us if we don't support NFV?
05:37:55 <s3wong> yamahata: will need to see how NFV subteam is structured on Wednesday meeting. Whether serviceVM should do general purpose work or conforming to be part of NFV task
05:38:15 <bmelande> malini1: pool mgmt = deciding when that spin up/down of VM should happen.
05:38:28 <ChristianM_> Agree with bmelande, If we don't support NFV usage models it will be useless very quickly
05:38:36 <s3wong> gongysh: Nova with Neutron requires a VM to be spawnwith at least one Neutron port, and it has to be plugged into a Network
05:38:53 <malini1> bmelande: thank you.
05:38:59 <s3wong> gongysh: worse still, the network you plugged in initially can never be changed during the lifttime of the VM
05:39:23 <bmelande> s3wong: But until that is supported "dummy" Neutron networks could be used to plugg the VM to
05:39:40 <yamahata> s3wong: I see. general purose or NFV conformance is big question for our direction
05:39:57 <s3wong> bmelande: yeah, that's what we talked about during the J-Summit, We would love to avoid this :-)
05:40:07 <yamahata> I think servicevm project should be super set of NFV use case
05:40:23 <gongysh> s3wong: that is  a technique issue, with little change , we can create VM without port or something
05:40:26 <balajip> yamahata:we should adopt ETSI NFV conformance for the success and adoption of our service.
05:40:48 <bmelande> balaji: I tend to agree with that.
05:40:49 <malini1> serviceVMs born for NFV. Assuming other services will be less demanding!
05:41:17 <balajip> malini1:I completely agree with you
05:41:19 <yamahata> balajip: lean for NFV conformance
05:41:20 <s3wong> gongysh: you know, I haven't looked into nova (or probably more specifically, ovs driver) to know for sure. But I just want to reflect on some requirements given by other Neutron services team
05:41:22 <ChristianM_> balaji: I agree also
05:41:46 <yamahata> Okay, I'll update draft to include NFV conformance
05:41:57 <yamahata> #action yamahata update draft to include NFV conformance
05:42:48 <yamahata> Regarding to separating vif creation and network connection, is there anyone to volunteer to write neutron spec?
05:42:48 <s3wong> yamahata: I haven't looked into ETSI NFV specs, so they have requirements for lifecycle management of VMs?
05:42:57 <balajip> All: good that we are all on the same page w.r.t NFV conformance
05:43:18 <s3wong> yamahata: I will take a look at that, since I brought it up :-)
05:43:48 <yamahata> #action s3wong look into vif creation/network connection
05:44:05 <yamahata> s3wong: can you also update the page https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items ?
05:44:16 <yamahata> to show that you're working on it
05:44:17 <bmelande> yamahata, s3wong: change is probably in Nova rather than Neutron
05:44:22 <s3wong> yamahata: yes, of course
05:44:43 <s3wong> bmelande: that's what I expect also
05:44:48 <yamahata> bmelande: probably.
05:45:33 <malini1> bmelande: what do you mean by change in Nova? You mean for life vm cycle support?
05:46:11 <bmelande> malini1: I was referring to the vif issue, spinning up VM without any networks
05:46:35 <malini1> bmelande: thanks
05:47:08 <yamahata> s3wong: ETSI NFV spec, http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf and http://www.ietf.org/proceedings/89/slides/slides-89-opsawg-7.pdf would help
05:47:17 <yamahata> #link http://www.ietf.org/proceedings/89/slides/slides-89-opsawg-7.pdf
05:47:23 <malini1> question: can a single NFV instance be used for one tenant and then later repurposed for another tenant without any scrubbing? or does that depend on the NFV type?
05:47:24 <yamahata> #link http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf
05:49:07 <balajip> malini1:It depends on the deployment type.
05:49:07 <yamahata> malini1: it depends on VM image. I haven't looked at NFV spec closely yet, though.
05:50:33 <gongysh> I think we should return the NFV instance back to pool until it can be repurposed to anther tenant.
05:50:50 <gongysh> So we must clear tenant related stuff during the returning.
05:51:07 <bmelande> malini1: perhaps this is a new requirement, i.e. ability to specify that VM instance can be "reused" or not (after having being used for some tenant)
05:51:58 <yamahata> okay ten minutes left.
05:52:47 <yamahata> any other issues?
05:53:00 <malini1> bmelande: looks like a parameter. if latency to create an NFV instance is large, then we would always have 1 or two spares created a fresh with just configuration to be applied. this approach if scrubbing or proving scrubbed for security is difficult
05:53:37 <balajip> yamahata:what are the action items we have for this week?
05:53:46 <malini1> i would like vry much to know what next concrete steps are and what we want to implement, architect and get started
05:54:05 <malini1> :-)
05:54:06 <yamahata> #action everyone review incubation page
05:54:07 <bmelande> Regarding ETSI NVF: So we strive to be compliant with their terminology? But perhaps not necessarily implement their architecture?
05:55:10 <yamahata> bmelande: yes. So we can do design/implementation and terminology discussion in parallel.
05:55:13 <s3wong> bmelande: we (at least I) have to look into what special use cases are required by NFV specifically on VM (both network connectivity and lifecycle)
05:55:19 <balajip> bmelande:agree, lets go throught the given links and discuss in the next week meeting
05:55:25 <malini1> bmelande: +1. i am thinking of minimal implementation, then a phase-2, phase-3. but phase-1 should meet the needs of the vrouter mentioned
05:55:33 <ChristianM_> bmelande: I think we should align terminology then the appropriate Openstack implementation
05:55:58 <s3wong> bmelande: at least initially, seems like we will focus more on NFV use cases (as agreed by the community here)
05:56:47 <malini1> i heard that cisco had a solution and perhaps something needs to be merged or extended. are we starting with cisco implementation?
05:57:29 <bmelande> malini1: Yes, we have one implementation, and Isaku has one, and others do too. :-)
05:57:44 <bmelande> malini1: with more or less overlaps
05:57:46 <yamahata> bmelande: can you provide the link to github?
05:57:47 <malini1> i was also thinking that a phase-1 would be developing a serviceVM catalog that the neutron nfv flavor guys could query
05:57:49 <balajip> malini1: we do have one ...:-)
05:58:12 <malini1> :-) :-) do we really need to build another?
05:58:52 <bmelande> No, let's merge them :-)
05:58:56 <malini1> does it make sense to have each of the implementations dicussed and adopt the richest or the minimal set or ..?
05:58:57 <balajip> malini1: we have to bring all the good feature together and make it more appropriate for adoption.
05:58:59 <s3wong> malin1: we would like to consolidate
05:59:11 <yamahata> +1 for merge
05:59:23 <malini1> +1 merge
05:59:23 <ChristianM_> I think merging all features would be great and provide some momentum
05:59:31 <ChristianM_> +1 merge
05:59:34 <balajip> +1 for merge
05:59:48 <gongysh> just like the opendaylight,  the core will help lots.
06:00:07 <gongysh> +1 for merge and then develop more
06:00:19 <yamahata> Great. time is running out.
06:00:26 <malini1> gongysh: assume you will not get much help from neutron core, they are swamped
06:00:50 <yamahata> tomorrow, there is NFV irc meeting and let's advocate our project.
06:00:50 <malini1> would it be possible to send out links to each impl and a presentation
06:01:11 <bmelande> yamahata: +1
06:01:13 <malini1> i would suggest startign with one as base and slowly merging in the others, feature by feature
06:01:19 <yamahata> https://wiki.openstack.org/wiki/ServiceVM has many links
06:01:26 <malini1> but need to choose the first impl
06:01:27 <balajip> yamahata:sure, we should do that
06:01:31 <gongysh> malini1:  we can do it ourselves.
06:01:59 <malini1> yamahata: thank you, i have hme work :-)
06:01:59 <yamahata> okay any other last word?
06:02:04 <ChristianM_> what time is the NFV irc meeting tomorrow ?
06:02:16 <malini1> gongysh: +1
06:02:22 <s3wong> ChristianM_: Wed 14:00 UTC
06:02:36 <s3wong> same channel as here
06:02:44 <balajip> thanks..had a very good discussion..today
06:02:45 <ChristianM_> thanks
06:02:51 <yamahata> thank you.
06:02:59 <malini1> thanks and bye
06:03:03 <gongysh> bye
06:03:04 <bmelande> Thanks. Bye!
06:03:04 <yamahata> We'll have irc meeting next week.
06:03:07 <yamahata> thank, bye
06:03:10 <s3wong> thank you guys for your enthusisam for the project!
06:03:20 <ChristianM_> thanks, bye
06:03:22 <yamahata> #endmeeting