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