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