16:08:14 <sridhar_ram> #startmeeting tacker
16:08:16 <openstack> Meeting started Thu Jul 16 16:08:14 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:08:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:08:19 <openstack> The meeting name has been set to 'tacker'
16:08:33 <sridhar_ram> #topic Announcements
16:09:09 <sridhar_ram> Agenda - #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_July_16.2C_2015
16:09:59 <sridhar_ram> #info Devstack patch has merged. The latest Tacker installation instruction available here - https://wiki.openstack.org/wiki/Tacker/Installation
16:10:19 <s3wong> sorry, late again
16:10:32 <sridhar_ram> #topic API transition
16:10:38 <sridhar_ram> s3wong: hi
16:11:57 <sridhar_ram> sripriya: and me - looked into the how existing APIs are hooked
16:12:25 <sridhar_ram> as you might have noticed .. current Tacker code base uses neutron extension like mechanism
16:13:00 <sridhar_ram> the 'servicevm' component is implemented as extension and all the APIs are implemented in there
16:13:26 <sridhar_ram> Tacker doesn't have any "core" APIs (like neutron's basic network APIs)
16:14:25 <sridhar_ram> sripriya: is planning to come up w/ a tacker-spec soon on this for us to review & comment
16:14:38 <sridhar_ram> sripriya: anything else on this topic ?
16:15:00 <sripriya> sridhar_ram: i think you covered it
16:15:14 <sripriya> and just to add, we confired it is going to be v2
16:15:21 <sripriya> *confirmed
16:15:44 <s3wong> basically need to do something like servicevm/v2/...?
16:15:51 <sridhar_ram> sripriya: oh yes ..
16:15:55 <sripriya> right now, the service_vm is based on v1 entry point
16:16:15 <sripriya> s3wong: it is something like v1/device_template and etc.
16:16:52 <sridhar_ram> this will change to v2/vnfd
16:16:55 <s3wong> sripriya: is that OK with the UnitedStack folks? They are already using servicevm/device_templat...etc
16:17:26 <sripriya> we are going to retain the v1 support as a backward compatibility
16:18:11 <sridhar_ram> s3wong: existing v1 APIs won't change and it would continue to work
16:18:27 <sridhar_ram> lets move on to health mon
16:18:35 <sridhar_ram> #topic Health Monitoring
16:18:51 <sridhar_ram> bobh_: prashantD: take it away
16:19:16 <bobh_> I submitted a spec for review which contains some very basic enhancements to the existing ping monitor
16:19:58 <bobh_> I think we need to have a discussion regarding how much Tacker wants to be in the monitoring business, given other projects like Monasca and Ceilometer
16:20:15 <tsalagi> Agreed, Monasca is looking promising
16:20:20 <bobh_> The outcome of that discussion will determine future direction for monitoring enhancements
16:20:30 <sridhar_ram> bobh_: sure, but before that we need to get our framework in place
16:21:00 <sridhar_ram> bobh_: we first need a loadable monitoring driver ..
16:21:06 <tsalagi> Does Tacker have a framework for receiving notifications from things like Monasca or from the infrastructure?
16:21:24 <sridhar_ram> tsalagi: that's exactly I'm getting at
16:21:28 <s3wong> bobh_: that is actually a good question... we do anticipate some VNF to have its own monitoring driver
16:21:47 <bobh_> Are we expecting each VNF to provide their own driver?  I'm not sure that's a reasonable requirement
16:22:11 <s3wong> bobh_: that being the case, is it OK for Tacker to expect that VNF vendor to write a driver for Monasca before it can work with Tacker?
16:22:16 <bobh_> As a user I want to bring my TOSCA csar file with an image etc and rely on infrastructure
16:22:24 <s3wong> bobh_: we certainly don't want to preclude it
16:22:25 <tsalagi> I would hope for a common framework for delivery of this information to VNFs.  But agree Tacker needs something in the interim
16:22:25 <bobh_> s3wong:  good question
16:22:35 <bobh_> s3wong: I agree
16:22:46 <sridhar_ram> bobh_: agreed, that would be when we go to a agent-based model
16:23:07 <bobh_> I think part of the problem is the huge variety of VNFs
16:23:17 <bobh_> Some are very basic and some are very complex
16:23:29 <bobh_> trying to get any commonality at all will be a challenge
16:23:34 <sridhar_ram> lets starts w/ some basic :)
16:23:51 <tsalagi> I had hoped OPNFV would have taken the lead on this notification specification for VNFs
16:24:09 <s3wong> bobh_: certainly, so we won't be expecting a monitoring API/framework that will work forever moving forward
16:24:29 <sridhar_ram> to me the biggest part of the puzzle .. the interface between Tacker state machine and monitoring framework
16:24:37 <s3wong> bobh_: we only want to get things started, and iterate as we move forward with (hopefully) more users and vendors feedbacks
16:24:48 <sridhar_ram> what would generic interface look like ?
16:24:56 <bobh_> I'd like to have a discussion about expectations for the framework - as well as expectations about what Tacker is going to provide versus what it will delegate to other projects
16:25:50 <bobh_> sridhar_ram: Good question - is it a callback/API interface, or a message bus?  or something else?
16:25:51 <s3wong> bobh_: and that would require having knowledge of what is available on the other projects (Ceilometer and Monasca in this case)
16:25:51 <sridhar_ram> to me ping, monasca, bfd, http-ping, etc are various monitoring mech ..
16:25:58 <tsalagi> That would be a very useful discussion, and perhaps helpful for the community in general
16:26:08 <sridhar_ram> bobh_: exactly ...
16:26:23 <bobh_> sridhar_ram: I think we need a midcycle :-)
16:26:39 <sridhar_ram> bobh_: agree, particularly for this subject
16:26:46 <s3wong> bobh_: that said, our current monitoring is definitely virtually non-existent; so I am sure whatever is supported by Ceilometer and Monasca would be far superior than ours
16:27:18 <bobh_> s3wong: I agree - and Heat includes Ceilometer hooks already, so we need to decide how to leverage
16:27:49 <s3wong> bobh_, sridhar_ram: the question is --- if we are to do Monasca, is this something we can realistically integrate with Tacker within the Liberty cycle?
16:27:55 <tsalagi> Agree on the heat / Ceilomter hooks, need to leverage...
16:28:09 <bobh_> s3wong: I don't think so personally, but I'm a newbie
16:28:30 <sridhar_ram> s3wong: once the framework part is done.. the next realistic thing we can shoot for in Heat-Cielometer
16:28:30 <aruncewind_> bobh_ , on the same note, monasca is bringing in it's own alarm spec for Heat. in other words, as Monasca becomes monitoring and Ceilometer becomes metering, there would still be a way to use an OpenStack service for monitoring (Monasca) and have heat hooks for it
16:28:44 <sridhar_ram> beyond that might be too much to munch...
16:28:47 <s3wong> bobh_: then my take would be --- continue to study it, but punt on that until the next cycle
16:29:10 <sridhar_ram> but we should put Monasca in the plate and discuss so that the framework pieces are baked well
16:29:23 <s3wong> bobh_: the framework would therefore only have ICMP and some TCP connectivity check for now
16:29:28 <bobh_> s3wong: I agree - we'll move forward with the minor enhancements and come up with a plan for integrating Monasca
16:29:56 <sridhar_ram> aruncewind_: that's good information..
16:30:08 <tsalagi> agree - minor enhancements, watch community..
16:30:16 <aruncewind_> agree with sridhar_ram, if OpenStack is grativating towards Monasca for monitoring and Ceilometer for metering, Tacker would have Monasca on it's plate as well for scaling needs
16:30:43 <s3wong> bobh_: without knowing much about the detail (or even flimsy knowledge) of Monasca, I think studying it would give us a lot of ideas on monitoring; but let's not try to boil the ocean in one cycle
16:30:46 <bobh_> I think we should look for Monasca integration in the Mitaka cycle
16:31:12 <sridhar_ram> bobh_: I think we need a spec for health-monitoring framework first
16:31:30 <sridhar_ram> bobh_: are you and prashantD planning to write one ?
16:31:43 <bobh_> sridhar_ram: So is that a higher-level spec than what is in the health-monitor.rst spec that is in gerrit?
16:31:54 <s3wong> bobh_: that would be great, hopefully enough time for us to understand Monasca well
16:32:01 <sridhar_ram> bobh_: exactly
16:32:27 <sridhar_ram> in fact, I do like the current health-mon spec.. particularly the http part
16:32:36 <sridhar_ram> we to be it is out of sequence ..
16:32:51 <sridhar_ram> *but to me it is out of sequence
16:33:33 <sripriya> bobh_: can you share the link for the spec
16:33:54 <sridhar_ram> in fact you look at existing mgmt_driver framework and bring it to health-mon
16:34:32 <bobh_> #link https://review.openstack.org/#/c/202126/
16:34:46 <sripriya> bobh_: Thanks
16:34:48 <bobh_> sridhar_ram: Is that in tacker-specs?
16:35:05 <sridhar_ram> no, we need to write one
16:35:08 <sridhar_ram> :)
16:35:34 <sridhar_ram> you mean the mgmt_driver ?
16:35:39 <bobh_> sridhar_ram: OK, I'll take a look at the design of mgmt_driver and reverse-engineer it
16:36:11 <sridhar_ram> bobh_: cool, thanks!
16:36:16 <bobh_> sridhar_ram: If you know of any framework specs that we could use as a template that would be helpful - I hate reinventing the wheel
16:36:31 <s3wong> bobh_: well, first step is play around with the code is indeed factoring out the ping code and put it as a driver (and implement the driver interface)
16:36:52 <s3wong> so I agree with sridhar_ram here that it would be a good one code sprint milestone
16:37:23 <bobh_> s3wong: Assuming I can use the mgmt_driver as a model?
16:37:38 <s3wong> bobh_: yes
16:37:57 <bobh_> s3wong:  Great.  I'm flying this weekend so now I have something to do....
16:38:25 <s3wong> bobh_: good thing to do on the plane, especially if the flight movies are terrible  :-)
16:38:43 <bobh_> It's a United 737 - what movies?
16:38:55 <s3wong> :-)
16:38:57 <sridhar_ram> bobh_: not sure if we can find a template to framework specs..
16:39:00 <s3wong> short flight then :-)
16:39:21 <bobh_> sridhar_ram: OK, I'll google and see what I can find
16:39:56 <sridhar_ram> #action bobh_ to write a tacker-spec for health-monitor framework
16:40:21 <sridhar_ram> anything else on health-mon ?
16:40:24 <bobh_> sridhar_ram: I'll open a new Blueprint for that too
16:40:38 <sridhar_ram> bobh_: sounds good
16:41:01 <sridhar_ram> #topic VNF boot attributes
16:41:57 <sridhar_ram> we had a sync up with TCS grp working on this area on behalf of a tacker user (comcast)
16:42:31 <sridhar_ram> one thing that repeatedly came in there is the ability to support "args" in the VNFD template
16:42:43 <sridhar_ram> this had come up earlier as well
16:43:43 <sridhar_ram> we need templating support where many of the attributes are undecided at template definition time and gets as arguments
16:43:56 <sridhar_ram> they will be "filled in" during instantiation time
16:44:20 <bobh_> sridhar_ram: The attributes are not defined or the values of the attributes are undefined?
16:44:25 <s3wong> sridhar_ram: yeah, just which network we should plug the VM in is already a non-template item
16:44:51 <sridhar_ram> bobh_: hmm.. I believe both
16:45:25 <bobh_> sridhar_ram: I can understand the values being unknown, but not knowing what the attributes themselves are sounds odd...
16:45:34 <tsalagi> Metadata type argument where VNF vendors could supply proprietary values?
16:45:44 <sridhar_ram> s3wong: yeah, for example the network to plug a vnic might be decided at instantiation time and it would be different for different tenants
16:45:44 <bobh_> How does this different from TOSCA/Heat parameters?
16:45:48 <s3wong> bobh_: the items requested by Comcast/TCS is here: https://etherpad.openstack.org/p/liberty-tacker
16:46:13 <sridhar_ram> bobh_: It should indeed be TOSCA params
16:46:29 <sridhar_ram> bobh_: that is requirement / gap to be filled
16:46:37 <s3wong> look for "User Input" -> "Comcast / TCS", and particularly things that have "Response" on them
16:46:46 <bobh_> sridhar_ram: So it is the ability to supply an env file when we create the VNF
16:47:08 <bobh_> or supply command line values for parameters like heat stack-create
16:47:11 <sridhar_ram> tsalagi: Instance metadata is another ask as well
16:47:37 <sridhar_ram> bobh_: the former ..
16:47:50 <sridhar_ram> our commands already take vnf-config.yaml
16:47:52 <bobh_> sridhar_ram: I have been wondering how some of my more complicated Heat templates will map into TOSCA templates
16:48:40 <sridhar_ram> bobh_: some of this can be punted to our upcoming integration with heat-translator
16:48:45 <bobh_> sridhar_ram: supplying the parameter values should be pretty straightforward in an ENV file
16:48:59 <bobh_> sridhar_ram: ok - I've been interested in looking at that too
16:49:06 <bobh_> too many things to do....
16:49:14 <sridhar_ram> bobh_: yes, it should fairly straight forward..
16:49:24 <sridhar_ram> bobh_: yeah, we got to pace ourselve
16:49:30 <sripriya> the other important thing that came up was to dynamically select the tenant where VNF should be launched
16:49:43 <s3wong> sridhar_ram: dynamic vNIC creation doesn't sound like something we can do via env file
16:49:51 <sripriya> right now, the VNFs get launched in the service tenant
16:49:57 <bobh_> sridhar_ram: Agree - it should be possible to map the user's credentials into the VNF deployment
16:50:02 <sridhar_ram> any new volunteers to help in this vnf-config area ?
16:50:07 <bobh_> sridhar_ram: / sripriya
16:50:08 <s3wong> sridhar_ram, bobh_: so the user requirements would require more than supplying an env file, I believe
16:50:36 <bobh_> s3wong: So this is changing the number of Ports defined in the template on the fly?
16:50:37 <sridhar_ram> this is a slightly gentler area to come and contribute to Tacker !!
16:50:54 <s3wong> bobh_: yes, I wonder if we can even do that via Heat...
16:51:14 <bobh_> s3wong: Stack update can do it, but that assumes the stack is deployed already
16:51:37 <bobh_> s3wong: This sounds like an update to an existing template which would just mean a new template?
16:51:48 <sridhar_ram> s3wong: no, the ask is very simple .. no stack-update
16:52:05 <sridhar_ram> which would map to vnf-update and that is not the ask
16:52:16 <bobh_> sridhar_ram: So a vnfd-update?
16:52:30 <bobh_> Why not just create a new vnfd?
16:52:47 <s3wong> sridhar_ram: I thought they want to dynamically add vNIC to something deployed? or just dynamically add to an existing template that isn't stack-create yet?
16:53:33 <sridhar_ram> IMO that is something we should take after integrating w/ heat-translator.. they are already taking a crack at updating a individual resource with a Heat template
16:53:55 <sridhar_ram> s3wong: dynamic vNIC add is not a request.. we clarified that
16:54:08 <bobh_> sridhar_ram: It sounds like we need specific scenarios
16:54:53 <sridhar_ram> the scenario is very very simple .. pass an env file during vnf-create and have the values fill in some params in the VNFD template
16:55:07 <sridhar_ram> time check - 5mins left
16:55:12 <bobh_> sridhar_ram: Ah - that is easy
16:55:29 <sridhar_ram> easy things first .. that is the motto for L :)
16:55:57 <bobh_> I'll add that to the things to look at on the plane.  Might be easy to do
16:56:12 <sridhar_ram> idea is we chip away the asks with slightlly less effort !
16:56:19 <sridhar_ram> bobh_: thanks!
16:56:36 <sridhar_ram> #topic Open Discussion
16:57:18 <sridhar_ram> there is a thought to do a Tacker mid-cycle in August
16:57:32 <sridhar_ram> to a face-2-face meeting in Bay Area
16:57:47 <sridhar_ram> how many of you will be interested ?
16:57:51 <bobh_> o/
16:57:52 <sripriya> There is an answers forum on the tacker launchpad page where people who want to try tacker post questions
16:58:03 <sripriya> https://answers.launchpad.net/tacker
16:58:07 <s3wong> sridhar_ram: as long as I don't have to fly :-)
16:58:21 <sripriya> sridhar_ram: o/
16:58:33 <vishwanathj> +1
16:58:55 <sridhar_ram> cool.. we can give a shout out in the ML as well
16:59:42 <sridhar_ram> So far I'm really happy w/ the progress we made .. just look at the DONEs in our etherpad!
16:59:51 <sridhar_ram> and the IN-PROGRESS ..
17:00:07 <s3wong> sridhar_ram: pretty much all the DONEs were done by sripriya :-)
17:00:27 <sridhar_ram> W00t for sripriya!
17:00:29 <sripriya> s3wong: the todo list is big :-)
17:00:45 <sripriya> thanks guys
17:00:48 <vishwanathj> +1 for sripriya
17:00:55 <sridhar_ram> and bobh_ for knocking off whatever it comes his way
17:01:03 <vishwanathj> +1
17:01:03 <sripriya> +1 on that!
17:01:13 <sridhar_ram> lets close on that high note!
17:01:15 <sridhar_ram> sorry for starting late..
17:01:21 <sridhar_ram> #endmeeting