17:01:40 #startmeeting servicevm-device-manager 17:01:41 Meeting started Wed Feb 25 17:01:40 2015 UTC and is due to finish in 60 minutes. The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:45 The meeting name has been set to 'servicevm_device_manager' 17:02:04 * yamahata giving people several minutes... 17:05:28 now 5 min, let's start... 17:05:37 #topic Announcement 17:05:50 Now voting for openstack summit was closed 17:05:57 #link https://www.openstack.org/summit/vancouver-2015/speakers/ 17:06:05 thanks for your votes 17:06:38 that's it from me. anything else? 17:06:42 hello 17:06:47 sorry, a bit late 17:06:51 yamahata: hope it makes thru, but i see lots of good proposals 17:07:00 s3wong: hi 17:07:03 s3wong: hi 17:07:08 yamahata: didn't see what you wrote above, what did you say? 17:07:17 SridharRamaswamy: Yeah. the accept rate would be low. 17:07:28 yamahata: :) 17:07:29 The voting for summit was closed. 17:07:35 https://www.openstack.org/summit/vancouver-2015/speakers/summit 17:07:37 yes 17:07:59 generally I agree with yamahata, the possibility of the talk getting in is low 17:09:01 but we are happy that during this exercise, we got a somewhat clear direction for Tacker 17:09:35 that we are trying to build a VNF Manager 17:09:40 s3wong: yeah, can we list the high level functions of tacker as it stands .. 17:09:44 definitively 17:10:00 SridharRamaswamy: good question 17:10:01 health-monitoring, automatic-restart, automatic-reconfig on failure, etc 17:10:29 so as VNF Manager, at the minimum, we need to do "lifecycle and config management" 17:10:47 threw out few that was floating in my head 17:11:04 i'm thinking beyond spin up ServiceVM 17:11:37 in the MANO diagram, VNF Manager also lives on top of VIM (virtual infrastructure manager), so we have to avoid making direct Nova/Glance/Neutron calls 17:11:41 make them a plug in 17:12:24 SridharRamaswamy: agreed. setting up a management channel from get-go is a must 17:12:30 s3wong: hmm, why are you making that assumption ? 17:12:48 as we talked about last week with auto configuration of provider-net 17:13:01 #chair SridharRamaswamy s3wong 17:13:02 Current chairs: SridharRamaswamy s3wong yamahata 17:13:12 #topic Open Discussion 17:13:34 Yea. 17:13:54 SridharRamaswamy: it is in http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf 17:14:03 pg 6 17:14:25 s3wong: coincidence, i was looking at the same :) 17:14:31 VNFM and VIM have a common interface (Vnfm-Vi) 17:14:35 SridharRamaswamy: :-) 17:15:10 given that MANO mentions VIM can be vmware, or OpenStack, or CloudStack, my guess is we need to abstract out pure OpenStack calls 17:15:30 s3wong: yeah, that make sense 17:15:39 I don't work for a company that is a member of ETSI, so I don't know if Vnfm-Vi is being standardized 17:15:50 if so, we should actually follow what ETSI NFV proposes 17:16:12 the draft of ETSI is publicly available. 17:16:18 I'm not sure how new they are. 17:16:20 though 17:16:38 yamahata: I know about the four high-level drafts 17:17:00 yamahata: but not sure if the API proposals (if there are any) are publicly available 17:17:21 the guidance i got from ppl who are active in these standards body .. we shouldn't take every box and line to the exact definition to the implementation 17:17:57 SridharRamaswamy: sounds fair, Tacker can have a first crack at what plugin interface we should use 17:18:03 as long as we are providing the functions described in MANO in a way that can map back, it should be fine 17:18:13 SridharRamaswamy, yamahata: then if there are standard APIs coming up, we can try to map them 17:18:46 SridharRamaswamy, yamahata: TBH, I would be surprise at the end of the day, the APIs would look drastically different from Nova/Glance/Neutron anyway :-) 17:19:31 there are normalize toolkits like Apache Jclouds that can help to map to wherever VIM in the back 17:19:58 SridharRamaswamy: OK 17:20:22 jclouds, for eg, can do openstack, vmware or even ec2 :) 17:20:36 SridharRamaswamy: nice 17:20:48 yamahata: I would like to know the state of the Tacker codebase 17:21:20 s3wong: it's stable for a while 17:21:24 yamahata: is the keystone endpoint for Tacker setup yet? 17:21:34 yamahata: is devstack integration in place? 17:21:48 It works with keystone as neutron does. 17:22:04 devstack patch is not available yet. 17:22:41 If necessary, I can put half-baked patch for devstack somewhere. 17:22:45 maybe github 17:22:56 I'll upload it to github 17:23:02 yamahata: sure, that would be great 17:23:30 yamahata: what we need is Tacker being in some form where we can set up and start doing some test 17:23:38 #action upload devstack patch to github 17:23:38 yamahata: admittedly we can do unit tests 17:24:02 yamahata: but if we are to abstract out Neutron/Nova/Glance --- then it seems like the testing ought to be done with devstack 17:24:03 #action yamahata upload devstack patch to github 17:24:49 Sure. makes sense. 17:24:52 yamahata: also, when bobmel was still involved, he mentioned going with Pecan --- but I guess that isn't needed to bring up the API server per se, right? 17:24:56 Unfortunately UT is missing 17:25:31 At this moment, tacker is independent API server 17:25:58 yamahata: do we need to set up some framework for UT? or you were saying UT in general is missing (i.e., no UT was written)? 17:26:11 the latter. 17:26:17 yamahata: to should just work when we have the UTs, right? 17:26:18 tests direction is almost empty for now. 17:26:24 directory 17:26:33 Right 17:26:43 yamahata: that's OK, as we develop the APIs/DB model, we will write the UTs 17:27:06 yamahata: currently you haven't really completed the APIs/DB model anyway, right? 17:27:32 Not fully completed. but mostly. 17:27:59 yamahata: sure, we can start with that 17:29:19 s3wong: yamahata: folks - i got leave for another mtg in a min 17:29:31 SridharRamaswamy: sure. Have a good day 17:29:37 SridharRamaswamy: sure. np 17:29:41 i'll catchup w/ the meeting minutes 17:29:46 ttyl 17:30:43 yamahata: I may start to look into abstract out Nova/Neutron/Glance as plugin (i.e., plugin model) --- though since I only work on this ~20% time, the progress may be slow 17:31:09 s3wong: That's quite fine. 17:31:22 It seems everyone has time constraint. 17:31:31 yamahata: certainly :-) 17:32:09 Feel free to contact me when necessary. 17:32:25 yamahata: hopefully if we lay the groundwork nicely, it will attract more people from the community to join the project 17:32:52 Yea, hopefully :-) 17:33:00 yamahata: and that you and SridharRamaswamy's employers will allow you guys to dedicate more time into the project also :-) 17:33:17 (if and when the project becomes popular) 17:34:18 I do think VNF Manager is attractive, but we need to build something to show people this is a serious project first to get to be recognized as the OpenStack OSS VNF Manager 17:34:22 long way to go :-) 17:34:38 Definitively long way 17:34:41 and hard way 17:34:59 yamahata: one step at a time 17:35:07 anyway, that's it for me 17:35:15 anything else to discuss. 17:35:21 TBH I'm also running out of time... 17:35:28 yamahata: sure. Have a good week 17:35:37 s3wong: you too! 17:35:43 thank you. bye 17:36:00 #endmeeting