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