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