16:02:58 #startmeeting tacker 16:02:58 Meeting started Thu Sep 10 16:02:58 2015 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:02 The meeting name has been set to 'tacker' 16:03:14 #chair bobh sripriya 16:03:15 Current chairs: bobh sridhar_ram sripriya 16:03:40 Agenda - #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Sep_10.2C_2015 16:04:13 #topic Announcements 16:04:59 Tacker Liberty Deadline is Sept 25th - #link https://wiki.openstack.org/wiki/Tacker/Releases 16:05:13 just two weeks away 16:05:57 New Tacker development process is now merged and official - #link https://review.openstack.org/#/c/219012/ 16:06:37 please follow the process in your contribution efforts, for any clarifications please reachout to the core team 16:07:06 Experimental features proposal for Tacker is announced in the ML - #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074015.html 16:07:25 comments / suggestion are welcome ... 16:08:07 as part of this I'll open mitaka dir in tacker-specs repo to start working in post-Liberty specs (like sfc, nvfo, ...) 16:08:41 any other general heads up / thoughts ? 16:09:40 #topic Liberty Release Status 16:09:57 if you've noticed we have a lose agenda today :) 16:10:23 lets go around the table to see where we are w.r.t Liberty release - the deadline is approaching fast 16:10:55 sripriya: few words about MANO API ? 16:11:47 sridhar_ram: update on API, it is ready for review, it had some issues with jenkins not picking it up, i'm resolving that and it should be good to go 16:12:09 sridhar_ram: plugin unit tests are added, so we have something to quick start for py27 16:12:47 sridhar_ram: however tox would pick up all test cases that are under unit and error out crazily as none of them are functional 16:12:47 sripriya: this is awesome, we finally have py27 unit-tests for tacker 16:13:38 sridhar_ram: we need to take up cleaning task of unit tests dir. and retail only whatever is relevant 16:13:41 sripriya: we can remove / move old test out of the way so that tox doesn't pick up 16:14:07 sridhar_ram: yes, i plan to do that as a seperate activity 16:14:48 sridhar_ram: okay, let me know if you need help. I've few other things to cleanup as part of my Part-2 of my original cleanup patchsets 16:15:13 just tested the tox against the new dir. 'vm' I introduced and it worked fine 16:15:27 since my unit tests does not have any dependencies 16:15:42 sripriya: for now, can't you set the OS_TEST_PATH to your specific dir ? 16:15:52 i can do 16:16:07 but that is not what i want to push upstream 16:16:37 it is basically updating the .testr.conf file, if you want me to push that change to point it to the dir., i will include that change 16:17:43 hmm... that might trip what Santosh is introducing for scenario tests ? 16:17:59 sridhar_ram: no 16:18:18 sridhar_ram: functionla tests has its path setup in tox.ini itself 16:18:23 *functional 16:18:29 okay .. so we can keep -e py27 and -e functional points to separate paths. 16:18:37 sridhar_ram: yes 16:19:11 btw - we also need the doc.openstack.org enabled for Tacker and have it point to MANO API.. 16:19:49 please plan that for Liberty Release 16:19:57 that will mean working with the docs team right? 16:20:36 sridhar_ram: i dont know if they allow for stackforge projects on docs.openstack.org 16:20:44 no, I can help to get the project-config to do doc-pubs... from your part you need to write up the doc 16:20:53 ah.. that's a good point.. 16:21:12 sridhar_ram: they allow only governance projects 16:21:22 either case we will fold into openstack/ soon .. I'll follow up w/ infra team on that 16:21:44 sridhar_Ram: alright, meanwhile i will add the doc-ref in tacker dir. 16:21:56 cool.. 16:22:10 sripriya: anything else on MANO API ? 16:23:08 sridhar_ram: that is it, i request everyone to do some testing of patchsets and provide any feedback including unit tests 16:23:39 sounds good.. I'll give it a spin for sure 16:24:07 bobh: any update on the health-monitoring spec and its progress ? 16:24:38 sridhar_ram, bobh: Is this to take us beyond just ping? 16:24:41 sridhar_ram: Looking for feedback on the latest spec - a couple of outstanding questions 16:25:03 sridhar_ram: Where is that spec? 16:25:05 lsp42: Yes - it is going to be modular so you can supply your own monitor 16:25:33 bobh: Sorry, me being impatient! I would like to read this spec 16:25:45 #link https://review.openstack.org/#/c/202126/ 16:26:20 At this point I think it will mostly be copied from the mgmt_driver design with the appropriate changes for monitoring 16:26:35 bobh: towards lsp42's point - are you planning to keep http-ping in scope for this effort ? 16:26:50 sridhar_ram: Yes - that is going to be the reference implementation 16:27:25 sridhar_ram: The basic design is a copy of the existing mgmt_driver 16:28:06 bobh: sure, but are you planning to introduce http-alive as one of the pre-supplied mon-driver ? 16:28:31 sridhar_ram: I'm hoping to - ping and http-ping should both be pretty simple to implement 16:28:43 bobh: that's cool.. 16:28:57 sridhar_ram: The challenge is getting the whole driver mechanism plumbed into the server 16:29:14 so at the end of this effort - we will have icmp-ping, http-ping and an ability to introduce a custom driver 16:29:19 sridhar_ram: which is why I'm going to copy mgmt_driver as much as possible 16:29:26 bobh: totally agree, this will be a non-trivial effort 16:29:43 bobh: sure, that would be good start.. 16:30:07 sridhar_ram: So if anyone has feedback on the spec please let me know ASAP - coding has started :-) 16:30:22 sure, here is one :) 16:30:40 we also need to bring boot-wait that is currently in tacker.conf into something being VNF / VDU specific 16:30:53 sorry, way late --- still need time to get used to the new commute 16:30:57 will leave these thoughts in the review.. 16:31:09 that may apply to both mgmt and monitor 16:31:32 s3wong: morning, we are just going around the table to get liberty status ... 16:31:37 bobh: agree 16:32:02 bobh: regarding driver mechanism plumbing in server i can help you there, invested some time in that 16:32:14 sripriya: Thanks! 16:32:50 bobh: btw, on the bigger context, there is renewed interest in Tacker's health-monitoring 16:33:46 few potential tacker user / operators reached out .. and their immediate needs are all around health-mon 16:33:49 sridhar_ram: This should provide a generic framework for monitoring and health and scaling can take advantage of that 16:34:24 bobh: sounds good 16:34:34 anything else on health-mon ? 16:34:43 sridhar_ram: Ideally I would like to allow the VNF to provide it's own monitoring plugin without needing to install on the server. Future... 16:35:31 well... currently we are hampered by the need to have an entry-point in setup.cfg for every "driver" 16:36:09 maybe we need to add the ability to upload a monitoring driver via the API like we do with VDUs? Let it auto-configure 16:36:14 we can loosen this in the next iteration.. it seems you already have quite a bit in your plate for next few weeks 16:36:20 sridhar_ram: Definitely 16:37:26 lsp42: interesting - this exact suggestion came in our recent mid-cycle discussion (Xin who suggested this ? )... 16:38:41 lsp42: introducing "code" during runtime is a privileged action and it has many security implication as well... 16:38:59 ok 16:39:11 so maybe we need abstract drivers which then get fed directives 16:39:20 typically - any code is introduced by a conscious action of the deployer 16:39:33 lsp42: A well-defined monitoring interface would help a lot 16:39:46 lsp42: exactly, that is what we are shooting for.. 16:39:54 between the VNFM and VNF 16:40:04 sure 16:41:12 anything else on health-mon ? 16:41:59 I don't see prashant online .. 16:42:07 for an update on auto-scaling .. 16:43:04 I can give a quick update on SFC .. though it is not a liberty target.. 16:43:40 As described in the experimental feature .. we would like to bring in Tim's SFC efforts into Tacker 16:44:23 some of us attended last couple of opnfv-sfc meeting to answer any Tacker related question.. 16:44:48 sridhar_ram: may be you want to invite trozet in the next tacker meeting? 16:45:04 here is a slide deck that shows our thoughts on how we plan to introduce SFC #link https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit#slide=id.p4 16:45:58 sripriya: sure, I plan to .. Tim is busy with some OPNFV deliverables this week and he is planning to get back to SFC next week. 16:46:13 sridhar_ram: cool 16:47:31 any comments on the interested in Tacker + SFC slide above is welcome! 16:47:56 * sridhar_ram bad edit, argh 16:48:22 any questions on SFC ? 16:49:27 sridhar_ram: I missed the OPNFV SFC meeting yesterday morning --- was there any Tacker related discussion there? 16:50:12 s3wong: yes, I prepared the above slide deck for that meeting, but didn't get time to present it... 16:51:15 but Tacker was discussed quite a bit to full fill their need VNFM needs ... 16:52:00 was there any mention of Tacker being the VNFO once SFC is in place? 16:52:01 I suggested them to use Tacker as the api-server / wsgi server (along the lines Tim.R explored) for SFC API instead of inventing something adhoc 16:52:32 lsp42: absolutely, that's where we are heading ... 16:52:45 if you read the ML email on experimental features - #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074015.html 16:52:46 sorry - still trying to play catchup as well as reading code! 16:53:21 ... we are building all the puzzle pieces towards an NFVO ! 16:53:26 lsp42: no problem 16:54:03 sridhar_ram: Thanks. What was their response to using Tacker as the api-server for SFC? 16:54:41 They are quite supportive but they also need something really quick.. their B-release testing is not too far 16:54:58 that's why we need to fast-track Tacker SFC efforts! 16:55:24 sridhar_ram: yes, I attended last week's meeting --- and it seems like fitting us into their B-release timeframe is going to be difficult 16:56:02 despite trozet's great effort on the coding front 16:57:25 s3wong: I think are are other bigger road-blocks in openstack - ODL-SFC interaction - on how nova / neutron created the vnics in the ovs bridge and around vxlan tunnel terminations... 16:58:29 sridhar_ram: yes, there was some discussion on that also last week 16:58:32 what I mean is we will have a window to get this done while other things (around OVS-NSH support, vnice / bridge inters) are still falling in place 16:58:52 quick time checkk - 2min mark! 16:59:06 we need to wrap up soon... 16:59:06 sridhar_ram: OVS support of NSH would be masked from us anyway, it is more ODL's problem 16:59:28 s3wong: but it is required for meaningful B-release 16:59:30 this could be a huge win 17:00:04 sridhar_ram: technically it is required for ODL Lithium for SFC, but the SFC team decided to maintain their own fork... 17:00:22 hrmm 17:00:25 lsp42: It sure will, but we need to keep an open mind on sfc and execute well to enable them (opnfc-sfc) to succeed :) 17:00:39 times up folks... 17:00:47 talk to all next week 17:00:52 bye 17:00:53 thanks for attending! 17:00:57 bye 17:00:58 #endmeeting