17:00:15 <sridhar_ram> #startmeeting tacker
17:00:16 <openstack> Meeting started Tue Jan 26 17:00:15 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:21 <openstack> The meeting name has been set to 'tacker'
17:00:28 <sridhar_ram> #topic Roll Call
17:00:33 <sridhar_ram> Hi Tackers !
17:00:35 <bobh> o/
17:00:36 <tbh> o/
17:00:39 <sripriya> o/
17:01:05 <vishwanathj> o/
17:01:05 <sridhar_ram> all heavy hitters here ;-)
17:01:11 <santoshk> Hi
17:01:25 <sridhar_ram> lets starts...
17:01:31 <sridhar_ram> #topic Agenda
17:01:42 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Jan_26.2C_2016
17:02:05 <sridhar_ram> #topic Announcement
17:02:22 <sridhar_ram> Midcycle is just few days away ...
17:02:40 <sridhar_ram> #link https://etherpad.openstack.org/p/tacker-mitaka-midcycle
17:02:56 <sridhar_ram> Looking forward for some good discussions...
17:03:32 <sridhar_ram> I propose to skip next week's weekly irc mtg ...
17:03:40 <sridhar_ram> what do you all think ?
17:03:51 <bobh> ok with me
17:03:55 <sripriya> fine with me
17:04:11 <tbh> okay with me
17:04:11 <vishwanathj_> fine by me as well
17:04:38 <santoshk> +1
17:04:39 <sridhar_ram> .. canceled then!
17:04:52 <sridhar_ram> #topic Midcycle Meetup Agenda
17:05:06 <sridhar_ram> I've like to firm up the Agenda ..
17:05:49 <sridhar_ram> Bob you will be remote, we will start with your TOSCA related subject...
17:06:01 <bobh> ok
17:06:28 <sridhar_ram> bobh: so, do you have some material - diagrams or slides to set some context ?
17:06:51 <bobh> sridhar_ram: I'll put something together and post a link
17:07:25 <sridhar_ram> bobh: sounds good, google doc is better as it is shareable ...
17:07:34 <bobh> sridhar_ram: ok
17:07:53 <sridhar_ram> tbh: I saw your email ..
17:08:29 <zeih_> hi Tackers
17:08:34 <sridhar_ram> tbh: is timing the issue ? if needed we can let you go first thing in the morning ...
17:08:41 <sridhar_ram> zeih_: howdy!
17:09:01 <tbh> I am unable to attend meetup sridhar_ram,
17:09:22 <tbh> sridhar_ram, no we have night shifts for this week
17:09:45 <sridhar_ram> tbh: understood..no worries
17:10:19 <sridhar_ram> we will still run though auto-creation in the agenda for any general discussion...
17:10:37 <tbh> sridhar_ram, so I just put whatever in my mind in the mail
17:10:40 <tbh> sridhar_ram, sure
17:10:45 <sridhar_ram> zeih_: are you planning to attend (virtually) midcycle meeting ?
17:11:06 <zeih_> sridhar_ram: yes, part time
17:11:07 <sridhar_ram> tbh: lets briefly discuss that later in this mtg
17:11:24 <tbh> sridhar_ram, okay
17:11:26 <zeih_> sridhar_ram: due to time zones
17:12:15 <sridhar_ram> zeih_: understood... that something we need to sample / get data in this meeting .. our developer community's availability..
17:12:27 <sridhar_ram> zeih_: you in european tz ?
17:12:44 <zeih_> sridhar_ram: yes
17:13:09 <sridhar_ram> alright... any other midcycle related thoughts / questions ?
17:13:23 <prashantD> hi sridhar, prashant
17:13:31 <prashantD> is there still interest in scaling?
17:13:34 <sridhar_ram> prashantD: hi there.. long time!
17:13:42 <sridhar_ram> prashantD: in fact, we do..
17:14:07 <sridhar_ram> prashantD: there is some renewed interest in auto-scalling..
17:14:20 <sridhar_ram> prashantD: we might need to put that back into our active roadmap...
17:14:39 <sridhar_ram> prashantD: are you planning to attend the midcycle later this week ?
17:14:54 <prashantD> oh okay, yes I will stopby
17:14:56 <zeih_> sridhar_ram: prashantD: from my operator perspective very interesting ;)
17:15:06 <s3wong> hello
17:15:11 <sridhar_ram> s3wong: hi there...
17:15:12 <s3wong> sorry, joining late
17:16:06 <prashantD> zeih any use case on auto-scaling would help us
17:16:14 <sridhar_ram> prashantD: all: if you are planning to attend midcycle part-time (i.e a portion of the two day) - please let me know the time slots..
17:16:35 * sridhar_ram will retype as brucet just joinied...
17:16:41 <sridhar_ram> all: if you are planning to attend midcycle part-time (i.e a portion of the two day) - please let me know the time slots..
17:17:20 <zeih_> prashantD: sure
17:17:22 <sridhar_ram> s3wong: it will be great if are present F2F for the service-chaining discussion
17:17:56 <sridhar_ram> s3wong: we can adjsut the agenda items accordingly...
17:18:12 <s3wong> sridhar_ram: it is currently scheduled to be Thurs afternoon?
17:18:17 <sridhar_ram> yep
17:18:27 <brucet> Sorry I'm late
17:18:52 <s3wong> sridhar_ram: I should be able to accommodate
17:19:01 <s3wong> sridhar_ram: I will come by
17:19:04 <sridhar_ram> s3wong: great..
17:19:49 <sridhar_ram> again.. the theme is Day1 for current things in flight..
17:19:54 <brucet> Was there a discussion on remote attendance?
17:20:07 <sridhar_ram> Day2 for evolution of tacker beyond Mitaka
17:20:29 <sridhar_ram> brucet: yes, I've a webex link now in the etherpad..
17:20:36 <brucet> OK. Perfect
17:20:48 <s3wong> sridhar_ram: great --- the rest of the time I will be remotely dialed in
17:21:00 <sridhar_ram> it seems we have an even split between physical and virtual
17:21:03 <sridhar_ram> s3wong: sounds good
17:21:24 <sridhar_ram> anything else related to midcycle ?
17:21:50 <sridhar_ram> moving on...
17:21:59 <sridhar_ram> #topic Auto Image Creation
17:22:27 <sridhar_ram> tbh just sent an email on this .. #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/084979.html
17:23:36 <sridhar_ram> I'm wondering if we need to split out image handling into a separate RFE / spec
17:24:42 <sridhar_ram> as part of the multi-site spec review, we were thinking about how image handling would work...
17:24:43 <vishwanathj_> tbh, just read your email, good suggestion and approach
17:25:11 <tbh> sridhar_ram, not sure, but if we move image creation to vnf deployment, then we can follow the same steps for all resources
17:26:18 <tbh> vishwanathj_, :)
17:26:36 <sridhar_ram> tbh: sripriya: how would that work w/ multisite ?
17:26:38 <sripriya> tbh: basically the same workflow as before as you do not need to maintain any state now for all 3 resources
17:27:02 * sridhar_ram thinks it would work just fine :)
17:27:32 <vishwanathj_> the VNFD will have to association of what resources have been created on each of the VIMs
17:27:41 <sripriya> sridhar_ram: in multisite case, the common implementation would be to share a centralized image repository but we need to think through it
17:28:17 <sridhar_ram> sripriya: true, that's a bigger set of capability - for another time :)
17:28:24 <tbh> sridhar_ram, sridhar_ram yes, we don't need to maintain state for templates
17:28:25 <sripriya> sridhar_ram: but as per tbh's spec, it would create glance images on each of these VIMs
17:29:10 <sripriya> assuming glance image create is deferred to VNF create time ( 3rd apporach)
17:29:41 <sripriya> if the glance image needs to be resolved at VNFD create time, we will have to decide how to resolve
17:29:47 <sridhar_ram> vnf-create pseudocode -- if vnfd already has glance image uuid, all is well.. if not download / upload to glance and stick the glance uuid to VNFD and proceed to instantiate ?
17:30:10 <tbh> sridhar_ram, yes
17:30:13 <sripriya> yes
17:30:19 <sridhar_ram> we need a dictionary of glance uuid for all VDUs in a VNFD
17:30:48 <tbh> sridhar_ram, yes we have to maintain a dict for all resources
17:30:52 <sridhar_ram> we also need a new VNF state "DOWNLOADING_IMAGE"
17:31:13 <bobh> can we use a unique image name that is the same across all VIMs?
17:31:17 <sridhar_ram> ..... are perhaps "PREPARING_IMAGE"
17:31:54 <sridhar_ram> bobh: good point, if we store uuid that doesn't gel well for multi-site
17:32:02 <vishwanathj_> sridhar_ram, tbh, is the plan to use glance for downloading the image or use Heat Flavor rsource?
17:32:05 <tbh> sridhar_ram, why don't we continue with same states, but if fails, we will store error reason like "image upload failed" ?
17:32:37 <vishwanathj_> tbh, +1
17:32:40 <sridhar_ram> tbh: that could work for near term
17:33:12 <sridhar_ram> vishwanathj_: I'd suggest to use glance direct...
17:33:39 <sridhar_ram> vishwanathj_: Tacker would need more image-management capabilities down the line..
17:33:57 <tbh> sridhar_ram, vishwanathj_ I think we use native clients and use respective uuid in heat
17:34:03 <sridhar_ram> ... with ETSI Image mgmt / upgrade in mind
17:34:09 <vishwanathj_> I see
17:34:20 <tbh> sridhar_ram, oh  okay
17:34:57 <tbh> sridhar_ram, but that states exists if the VNF is deployed for the first time?
17:35:00 <sridhar_ram> tbh: sripriya: have you thought about how this solution would work for multisite ?
17:35:02 <brucet> I believe I mentioned this in last meeting. Tricircle supports multi site image management.
17:35:46 <tbh> sridhar_ram, .. because for the next VNF deployment for same VNFD, the states may not be valid, as images are already uploaded
17:36:01 <sridhar_ram> brucet: okay.. that could help when we need to do more in this area. we need to restrict to something simple for now
17:36:40 <brucet> My point is simply to find out how Tricircle is doing this and either borrow code or implement somethingcompatible
17:36:45 <sripriya> tbh: bear in mind, we will use the same VNFD for multiple sites, if that image is not yet uploaded on that particular VIM it should still show that satte
17:36:48 <sripriya> state*
17:36:53 <sridhar_ram> tbh: true, some states are not applicable for the 2nd time around
17:37:28 <sridhar_ram> brucet: sure..
17:37:55 <tbh> sripriya, got it
17:38:27 <sridhar_ram> tbh: overall I like the approach you are suggested, lot simpler than mucking around to make VNFD creation stateful...
17:38:28 <sripriya> sridhar_ram: probably we should maintain the state as PENDING_CREATE but along with that display at what stage of CREATE it is like a simple log info
17:38:44 <sripriya> similar to HEAT api
17:39:11 <tbh> sripriya, yeah that would be better
17:39:13 <sridhar_ram> tbh: just think through how that solution would gel into multisite... perhaps use "image name" based index as bobh alluded ..
17:39:21 <tbh> sripriya, some thing like stack_status_reason
17:39:25 <sripriya> tbh: yes
17:39:46 <sripriya> that way we dont need to bother about maintaining states at diff. times
17:39:50 <tbh> sridhar_ram, sure
17:40:30 <tbh> sridhar_ram, I think going with name will be helpful, as we reffering from VNFD directly
17:40:33 <sridhar_ram> sripriya: tbh: sounds good to me .. for near term. we might need to come back to enhance states at a later time..
17:40:56 <brucet> Is the plan that multi site controller will be stateless??
17:41:08 <sridhar_ram> tbh: sripriya: meanwhile please look at tricircle if there are any solutions / code to borrow  (I'll do the same)
17:41:26 <tbh> sridhar_ram, sure
17:41:37 <sripriya> brucet: it is stateless for now,
17:41:52 <brucet> Exactly. An important lesson l;earned from first implementation of Tricircle is that multi site controller should be stateless as far as underlyign OpenStack instances are concerned.
17:41:52 <sripriya> sridhar_ram: will look into it
17:42:21 <brucet> <sripriya> Great
17:42:54 <sridhar_ram> brucet: good input!
17:43:05 <brucet> Thx
17:43:15 <sridhar_ram> tbh: anything to discuss on this subject ?
17:43:25 <sridhar_ram> *anything else
17:43:48 <tbh> sridhar_ram, I think we can do the same for all resources?
17:43:58 <sridhar_ram> tbh: what you mean ?
17:44:01 <tbh> sridhar_ram,  I mean same procedure, as mentioned in mail
17:44:09 <tbh> sridhar_ram, for example...
17:44:41 <sridhar_ram> tbh: for flavor and network I thought mapping to Heat resource is the natural way to do it...
17:44:47 <tbh> for networks, we create the networks at vnf creation time and store those UUIDs as dict and reuse
17:44:49 * sridhar_ram reminds that is the next agenda item
17:45:16 <sridhar_ram> tbh: hold that thought for a sec .. we will circle back after TOSCA parser discussion
17:45:26 <sridhar_ram> #topic TOSCA parser integration
17:45:31 <tbh> sridhar_ram, sure
17:46:05 <sridhar_ram> bobh: congrats on landing TOSCA NFV profile into tosca-parser !
17:46:10 <sridhar_ram> W00T!!
17:46:16 <vishwanathj_> +1
17:46:17 <bobh> sridhar_ram: thanks!
17:46:26 <sripriya> bobh: congrats
17:46:38 <tbh> bobh, congrats
17:46:59 <sridhar_ram> this is significant, IMO.. we are now course correctly at the right direction..
17:47:03 <sridhar_ram> *correcting
17:47:21 <sridhar_ram> bobh: now, how do you see the wiring going to happen into tacker
17:47:57 <bobh> sridhar_ram: I'm working to fix a couple of issues we found in tosca-parser and heat-translator - should be available soon
17:48:33 <sridhar_ram> bobh: I see..
17:48:33 <bobh> sridhar_ram: I'm working on an "overlay" of the Tacker attributes onto the VDU definition
17:48:53 <brucet> <bobh> Is the thinking that the Heat template generated by the translator will be directly usable to instantiate a VNF?
17:48:54 <vishwanathj_> bobh, would this change any of the attributes in the tacker VNFD template?
17:49:56 <bobh> brucet: That's the hope.  Tacker will need to "prune" some attributes out of the ToscaTemplate object before passing it to heat-translator but the results of the translator should be usable in Heat
17:50:15 <brucet> <bobh> That makes sense to me
17:50:42 <bobh> vishwanathj_: The TOSCA templates will have a different version and format but I'm trying to maintain all of the functionality between the two formats
17:50:53 <brucet> <vishwanathj> How is a Tacker VNFD template related to a Tocsa NFV template?
17:51:26 <bobh> Tacker will use the "version" attribute of the template (which doesn't exist in the template today) to determine that it needs to run through the tosca-parser and heat-translator
17:51:58 <bobh> there will be a Tacker imports file that will add the additional properties needed by tacker onto the existing VDU/CP/etc ibjects
17:52:43 <bobh> after tosca-parser generates a ToscaTemplate object, Tacker will need to retrieve all of it's custom information, for monitoring, etc, and prune it out of the object before passing it to the Translator to create the Heat template
17:53:13 <vishwanathj_> bobh, I see, sort of makes sense, thanks for the explanation
17:53:30 <sridhar_ram> bobh: cool, in this case it should prune image related stuff out as well, that something tbh's code need to kick in to handle
17:53:32 <bobh> I found an issue where heat-translator does not allow you to specify a flavor or image directly today - that's a problem, but I have a patchset submitted to allow it and Sahdev has agreed to the change
17:53:55 <brucet> <bobh> So Tosca NFV template will drive Heat and other Tack subsystems?
17:54:06 <bobh> brucet: yes, that's the plan
17:54:15 <brucet> Then how is Tacker VNFD template related? What does it do?
17:54:52 <bobh> The Tacker VNFD template will now contain the TOSCA NFV yaml instead of the custom-Tacker-yaml format that we use today
17:55:05 <brucet> Ah..........
17:55:23 <bobh> we'll maintain backward compatibility for at least one release, but I think we should move completely to TOSCA ASAP
17:55:38 <sridhar_ram> bobh: totally agree!
17:55:39 <zeih_> +1
17:55:41 <brucet> OK. So there is an existing Tacker template format that will be subsumed by Tosca NFV Template
17:55:42 <bobh> we can do POlicies, Artifacts, lifecycle, etc
17:55:48 <bobh> brucet: yes
17:55:54 <brucet> Got it. Thx
17:56:00 <sridhar_ram> bobh: please code in a "deprecated" warning right away :)
17:56:09 <bobh> brucet: and we will drive some of the things that Tacker needs for implementation northbound into the spec
17:56:09 * sridhar_ram 4 mins left in the clock
17:56:18 <prashantD> bobh : scaling will require additional changes?
17:56:34 <bobh> brucet: since the NFV spec as it sits today is not very implementable
17:56:38 <brucet> Now I am seeing the forest through the trees. Thx greatly bobh
17:57:03 <brucet> OK
17:57:09 <bobh> prashantD: scaling will require policy defintions,  and server implementation, but should be possible
17:57:23 <bobh> brucet: np
17:57:36 <sridhar_ram> "overlay" that bobh mentions would be our playground for new features...
17:57:48 <bobh> i'll try to have something "sort of" working or at least documented by Thursday
17:57:56 <sridhar_ram> .. we should plan to push them back into TOSCA NFV profile as a follow on
17:57:57 <bobh> working might be a stretch
17:58:18 <sridhar_ram> bobh: that would be great..
17:58:37 <sridhar_ram> bobh: .. an helloworld always helps
17:58:49 <bobh> sridhar_ram: exactly what I'm working on :-)
17:58:58 <sridhar_ram> lets wrap it up for today...
17:59:05 <sridhar_ram> #topic Open Discussion
17:59:17 <zeih_> sridhar_ram: could we try to push them in TOSCA NFV profile in parallel?
17:59:23 <sridhar_ram> again, no irc meeting next Tuesday...
17:59:32 <sridhar_ram> zeih_: absolutely...
17:59:38 <sridhar_ram> zeih_: .. that's the plan
17:59:51 <zeih_> #link https://www.openstack.org/telecoms-and-nfv/
18:00:22 <sridhar_ram> zeih_: that's a good whitepaper.. Tacker is heavily mentioned
18:00:26 <sridhar_ram> times up
18:00:28 <zeih_> nice report
18:00:43 <sridhar_ram> see you most of you in midcycle
18:00:46 <sridhar_ram> #endmeeting