16:05:42 #startmeeting tacker 16:05:43 Meeting started Thu Jul 23 16:05:42 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:05:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:47 The meeting name has been set to 'tacker' 16:06:07 #chairs bobh sripriya 16:06:18 #topic Announcements 16:06:37 Agenda - #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_July_23.2C_2015 16:07:27 Tacker Liberty Mid-cycle being planned for 3rd week of Auguest 16:07:42 Tentatively Aug 21st 16:08:16 please unicast if you've specific preference on the date / time 16:08:34 once decided, we can announce in the ML 16:09:22 Tacker got presented in the opensource track of IETF #93 that is currently ongoing in Prague 16:09:39 this was presented to NFVRG group 16:09:44 sridhar_ram: cool! 16:09:57 #link https://www.ietf.org/proceedings/93/slides/slides-93-nfvrg-25.pdf 16:10:30 It was quite well received - at east IMO :) 16:11:26 well done! 16:11:51 We now have communication channel with following key folks: ETSI NFV chair, OpenMANO team and OPNFV !! 16:11:52 sridhar_ram: very nice. Thanks for doing it! 16:12:25 sripriya: I was just representing the awesome team we have here 16:13:11 hopefully we will have follow-on interactions with many SDOs 16:13:17 dgollub: thanks! 16:13:41 looks Stephen is not here 16:13:52 anything else to announce ? 16:14:10 sridhar_ram: did you want to announce tacker installation on ML? 16:14:42 Hmm.. I thought I already sent one 16:15:34 #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069639.html 16:16:05 ok cool. Sorry I missed that. 16:16:13 s3wong: hi 16:16:18 sorry, late again, traffic has been bad 16:16:24 sridhar_ram: hello 16:16:27 s3wong: np 16:16:32 I notice there is no topic yet :-) 16:16:42 we are in announcements 16:17:08 just gave an update on ietf prezo and our mid-cycle meetup plans 16:17:32 s3wong: I need to drop off in another 15mins (doing a demo in ietf here) 16:17:35 the IETF presentation came in through internal HP channels as well 16:17:54 aruncewind: glad to hear that 16:17:55 is it marie-paul odini that you had talked to? 16:17:58 sridhar_ram: a Tacker demo? 16:18:18 s3wong: no, ODL controller... which might be relevant for Tacker at some point 16:18:36 * s3wong wasn't even aware that IETF meetings have demo... 16:18:58 aruncewind: no, that name doesn't ring a bell 16:19:08 sridhar_ram: I see... demo on ODL SFC? 16:19:32 s3wong: no, on multipoint vpn 16:19:47 sridhar_ram: OK 16:20:14 lets move to the next topic, we can have a longer open discussion towards the end 16:20:22 #topic MANO API update 16:20:31 sripriya: take over 16:20:44 sridhar_ram: sure 16:20:58 the spec tracking the new API is at: https://review.openstack.org/#/c/204926/4 16:21:35 Quick summary: We will add new extension under v1 itself and there will be no v2. 16:22:06 and for now, servicevm endpoint will be retained for backward compatibility 16:22:07 sripriya: glad to see specs landing in our tacker-specs repo! 16:22:08 Oh... OK... 16:22:38 eventually we want to move to Pecan framework when move to master similar to other OpenStack projects 16:22:39 sridhar_ram: in fact, you and I have a heavy backlog to clear w.r.t. review and merge 16:23:10 sridhar_ram: I submitted a separate patchset to the tacker-specs repo to allow it to work with liberty specs, so new specs don't need to make the inde.rst change 16:23:11 s3wong: I'm happy to have that problem :) 16:23:22 for now, this spec will capture only changes related to adding new entry points and defining them 16:23:30 bobh: thanks 16:23:48 as first phase 16:23:48 will merge that first while the other two iterates 16:23:57 sridhar_ram: thx 16:24:58 there will also be changes done to tacker-client to reflect the new api changes in requests 16:26:07 for further info, please read through the spec and provide your feedvack/comments, it is still a WIP and it may take few iterations 16:26:16 feedback* 16:26:42 regarding the doc error, bobh and sridhar_ram: ack 16:27:13 sripriya: thanks for getting the spec so quickly! 16:27:21 sripriya: anything else ? 16:28:12 sridhar_ram: if you want to discuss further or have any questions we can discuss here, 16:28:24 sridhar_ram: else that is it, 16:28:46 sripriya: I think we shd use the gerritt for the initial round 16:29:20 sridhar_ram: cool 16:29:27 folks please comment on the and if you are fine approve w/ +1s 16:29:31 lets move on 16:29:41 sridhar_ram: another quick thing before we move on 16:29:46 sure 16:30:12 * comment on the spec 16:30:16 the attributes part of the REST api is where I'm specifically looking to discuss in the spec 16:31:12 sripriya: make sense, that portion needs a fine comb 16:31:28 i realize few attributes have been introduced such as service_context and services which do not get used 16:31:29 #topic Health monitor update 16:31:41 so we can discuss further on gerrit regarding same 16:31:52 sripriya: sounds good 16:31:58 bobh: take it away 16:32:39 Knowing nothing about the driver architecture I looked at the existing mgmt_driver and infra drivers to see how they work 16:33:10 I think we can copy the existing architecture/design of the mgmt_drivers to use for monitoring, obviously implementing different drivers, fo rping, etc 16:33:14 for ping 16:33:37 I updated the spec to reflect these changes, so please look it over and provide feedback 16:33:45 bobh: that's a sound approach 16:34:08 bobh: sounds good 16:34:10 I'm not entirely sure how the new monitoring driver module will be plumbed into the server, so if anyone has specifics on that it would be helpful 16:34:10 bobh : spec I read looks good, few things 16:34:19 bobh: one overall comment .. I think we should split that spec into one for framework change and another for new monitoring types 16:34:28 sridhar_ram: ok - no problem 16:34:48 sridhar_ram: I was going to do that and then laziness took over... 16:35:00 bobh: thanks, np... 16:35:21 bobh: from the PSs and commits coming from you - what laziness are you talking abt ;-) 16:35:42 the "I hate documenting things just let me write code" laziness 16:36:18 we will adding implementation details to the spec? 16:36:35 bobh: understood, my intention is have nice debates on new monitoring types and not to have that block the framework change 16:36:53 sridhar_ram: absolutely - its the right thing to do 16:37:18 bobh, sridhar_ram, newbie question from me - are these specs in addition to what monasca can offer from monitoring perspective? 16:37:27 #chairs s3wong bobh sripriya 16:37:48 vishwanathj: The framework will allow integration with monasca to be pluggable/odular 16:37:55 vishwanathj: good question, I think we need do some deep dives on monasca 16:38:04 prashantD: that is an open question --- most of the time, implementation detail doesn't go into the spec 16:38:04 vishwanathj: and the additional monitoring types will be in addition to what monasca can provide 16:38:44 prashantD: however, if you have to specify API/interface, then that interface needs to be in detail 16:38:53 folks - sorry, I got to leave.. btw I've one off-topic question to ask if you don't mind 16:39:23 bobh: new monitoring types will include ceilometer other than monasca? 16:39:24 aruncewind: just want to check w/ you if your extended team is considering to join tacker 16:39:40 bobh, sridhar_ram, the reason I ask is I attended an Openstack meetup in Austin related to Monasca (presented by HP) and I walked away with the impression that Monasca would be the solution for tacker VNF monitoring needs as it can allow to monitor hosts and also process running in a host....however, I could be wrong 16:39:42 sripriya: Sure if you want to write the module :-) 16:40:45 vishwanathj: It's certainly possible but Monasca also comes with a low of overhead so it will be necessary to support some basic monitoring types for situations where Monasca is not availabe 16:41:09 bobh: lol, I will be happy to do that only once I know more about the project itself :-) 16:41:10 s/low/lot/ 16:41:30 sripriya: That's what I said and now look where I'm at.... 16:41:46 my initial read shows Monasca has lots of downstream dependencies 16:42:04 vishwanathj: I think integration with Monasca is an M* release candidate, or later 16:42:22 sridhar_ram: Yes, and the development environment is challenging 16:43:03 it needs InfluxDB and Kafka... 16:43:27 sridhar_ram: bobh also mention you need Ansible? 16:43:31 I think we have higher priorities than Monasca at this point 16:43:35 bobh, ok. 16:43:51 s3wong: The devstack for Monasca needs ansible to do the setup 16:43:58 s3wong, ansible would be the preferred to deploy the monasca agents 16:44:03 s3wong: and it doesn't work in cygwin/Windows 16:44:33 however .. we shd consider (imagine ??) a tacker monasca monitoring driver and see what it is required in the framework 16:44:45 hopefully integrating Monasca doesn't make Tacker installation overly complicated 16:44:46 sridhar_ram: +1 16:45:03 s3wong: The driver should just consume the Monasca API 16:45:19 same with sripriya's ceilometer driver 16:45:32 split here ... talk to you all next week. will catch up in the meeting minutes 16:45:33 bye 16:45:34 bobh: sure --- but to use that driver, one still needs to install all the things Monasca needs 16:45:51 i'd be glad to help with the monasca deep dive if required. i am trying to get the current tacker code work in a monasca environment to see if i can find some obvious connection points 16:45:53 s3wong: Yes, that's the fun part 16:46:58 so anything else on the monitoring driver front? (please review bobh 's spec)? 16:47:09 aruncewind: I think the easiest connection point would be a new health monitor driver 16:47:29 s3wong: nothing from me 16:47:48 OK. Moving on... 16:48:03 #topic Testing Update 16:48:30 hmm... I thought I am one of the chairs now... 16:48:35 #chair 16:48:51 s3wong: you should be 16:48:56 #chair 16:49:03 bobh: you want to try #topic? 16:49:11 #topic Testing Update 16:49:21 apparently it doesn't work well :-) 16:49:24 it is OK :-) 16:49:41 so I am working on unit test 16:50:00 but my day job got in the way this week, and had made no progress 16:50:29 I know sridhar_ram is working on functional tests, and since he stepped out, I don't expect much updates 16:50:43 sripriya: do you have any update on the testing front? 16:51:37 s3wong: we may contribute some functional tests in the long run, but nothing yet for this week 16:52:29 OK Moving on... 16:52:51 #topic Bugs 16:53:11 (I think anyone can #endmeeting after an hour, so hopefully we don't impede the next meeting after us) 16:53:21 s3wong: people are still getting ramped up to Tacker, so it may take some time before we start seeing functiona testss PS 16:53:32 sripriya: sure 16:53:53 #chair s3wong 16:53:53 Current chairs: s3wong sridhar_ram 16:53:57 normally al bug fixes and features should accompany by unit tests 16:54:04 #topic Bugs 16:54:14 sridhar_ram: now it works :-) 16:54:20 do we want to discuss here for allowing unique names. 16:54:28 I think there are few bugs on the same 16:54:37 I think we got agreement that is it needed 16:54:53 I am looking at launchpad, and all the high priority bugs have fix committed 16:54:58 The best implementation will require database changes to enforce uniquemess 16:54:59 bobh: do you want to provide an update? 16:54:59 so good job, guys!!! :-) 16:55:24 s3wong: sorry, I used "chairs" earlier... 16:55:27 ... FIVE moinutes 16:55:30 The VNF name uniqueness can be enforced by using the VNF Name as the Stack Name, and Heat will enforce the uniqueness 16:55:48 sridhar_ram: apparently the demo room has Internet connectivity :-) 16:56:13 However that could be a problem because the Heat interface is using a single project/tenant/whatever, so it would mean that users in different tenants could not use the same VNF name 16:56:19 s3wong: I'm cheating ;-) 16:56:38 So the question is - can we make database changes to enforce name uniqueness in VNF and VNFD? 16:56:55 bobh: across tenants? 16:57:25 s3wong - I think it should be unique within the tenant, so that adds another key field - name and tenant_id 16:58:04 We can discuss in the bugs - there is one each for VNF and VNFD 16:58:11 bobh: I agree with this change, as we shouldn't rely on Heat to tell us the name isn't unique 16:58:14 plus some other name-related bugs that should be submitted soon 16:58:18 it should be managed by Tacker directly 16:58:37 s3wong: Agreed, just wanted to make sure the database config change is permitted 16:59:05 also could be an API change if we want to enforce it at that level, but I think DB change is sufficient for now 16:59:12 bobh: all you need is db migration script (easier said than done :-) ) 16:59:18 s3wong: exactly 16:59:52 bobh: but it is fairly common in OpenStack projects (though most of the rebase problems do come from db migration scripts :-) ) 17:00:27 ok - I'll work on it this week 17:00:44 bobh: at this point, we only have two users (UnitedStack and Comcast), that I know of, and my understanding is those are under deployment 17:00:55 bobh: thanks 17:01:14 so perhaps we can get away from having DB changes even without migration; perhaps we should consult with UnitedStack folks to make sure 17:01:25 Time's up. sorry guys 17:01:30 we can add UnitedStack as a reviewer to the patch 17:01:39 if there is anything else, let's move to #tacker to discuss 17:01:48 thanks, guys! 17:01:51 #endmeeting