17:00:45 <sridhar_ram> #startmeeting tacker
17:00:51 <openstack> Meeting started Tue Feb  9 17:00:45 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:54 <openstack> The meeting name has been set to 'tacker'
17:01:04 <sridhar_ram> #topic Roll Call
17:01:08 <vishwanathj> o/
17:01:12 <sripriya_> o/
17:01:13 <bobh> o/
17:01:16 <zeih_> o/
17:01:33 <sridhar_ram> howdy all!
17:01:49 <sridhar_ram> lets start...
17:02:00 <sridhar_ram> #topic Annoucements
17:02:38 <sridhar_ram> First meeting after the midcycle...
17:02:54 <sridhar_ram> #info Midcycle notes
17:02:56 <sridhar_ram> #link https://etherpad.openstack.org/p/tacker-mitaka-midcycle-notes
17:03:13 <sridhar_ram> thanks for everyone who attended the 2-day midcycle...
17:03:26 <sridhar_ram> hope you all found it useful..!
17:04:16 <sridhar_ram> feel free to share any general thoughts ? too long ? too short ? contents good ?
17:05:00 <sridhar_ram> next ...
17:05:25 <sridhar_ram> #info Big Tent application in the now in governance repo
17:05:31 <sridhar_ram> #link  https://review.openstack.org/#/c/276417
17:05:38 <zeih_> great :)
17:06:10 <sridhar_ram> TC going to discuss in today's TC weekly call at 2000 UTC
17:06:23 <sridhar_ram> grab some popcorn and watch :)
17:06:43 <sridhar_ram> zeih_: yep, many of us are quite excited...
17:07:25 <dkushwaha_> sridhar_ram, yes
17:07:33 <sridhar_ram> fyi, meeting info for that call is at #link   https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:07:39 <zeih_> sridhar_ram: yes
17:07:45 <sridhar_ram> dkushwaha_: howdy!
17:08:01 <sridhar_ram> next ...
17:08:28 <sridhar_ram> Based on  #link https://github.com/openstack/requirements#for-upper-constraintstxt-changes
17:08:48 <sridhar_ram> I propose  just one +2/+A for requirements patchsets from OpenStack CI Bot
17:09:00 <sripriya_> agree
17:09:03 <bobh> +1
17:09:04 <zeih_> +1
17:09:57 <sridhar_ram> missed this earlier ..
17:10:11 <sridhar_ram> #info Agenda at #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Feb_9.2C_2016
17:10:29 <sridhar_ram> #topic TOSCA Parser Integration
17:10:43 <sridhar_ram> bobh: please take it away..
17:10:55 <bobh> sridhar_ram: Thanks, I think....
17:11:31 <bobh> sridhar_ram: tosca-parser 0.4.0 was released last week which contains the NFV Profile support and a bunch of fixes for bugs/undocumented features
17:12:11 <bobh> so with that available I can push the first patchset into Tacker that will allow TOSCA VNFDs to be loaded using vnfd-create
17:12:39 <bobh> I have that working, so not sure if we want to push it separately and start reviews on it while waiting for the next piece
17:13:02 <bobh> The next piece is dependent on some changes that will be in heat-translator 0.4.0 which should be released in the next 2-3 weeks
17:13:12 <sridhar_ram> bobh: I'd vote for taking things in small pieces...
17:13:24 <bobh> once that is available I can push the second part which will take the parsed TOSCA template and translate it into a HOT template
17:13:30 <sridhar_ram> this could unblock tbh and vishwanathj gongysh ?
17:13:48 <bobh> sridhar_ram: Me too - maybe also put some code in so we don't try to deploy the TOSCA VNFD templates yet
17:14:20 <bobh> sridhar_ram: I think so - at least they can start modeling and make changes to the Tacker VNFD definitions as needed
17:14:27 <sripriya_> bobh: if we are consuming this feature in chunks, will we do the conversion of inmemory graph to HOT spec in Tacker?
17:14:46 <sridhar_ram> bobh: then +2 for that path of integration...
17:15:11 <bobh> sripriya_: I think the first chunck should be load the TOSCA VNFD but don't allow attempts to deploy it
17:15:30 <bobh> sripriya_: then the second part will unblock the deployment when heat-translator 0.4.0 is available
17:16:07 <sridhar_ram> sripriya_: this code path won't be usable until other pieces land ...
17:16:22 <sripriya_> bobh: sridhar_ram: ok
17:16:37 <sripriya_> so they will need to write custom parser until heat-translator lands?
17:16:53 <sripriya_> is my understanding right?
17:17:06 <bobh> sripriya_: The TOSCA VNFD will not be deployable until the heat-translator changes land
17:17:27 <sripriya_> bobh: oh ok
17:17:35 <bobh> sripriya_: but they can start using the TOSCA definitions to model the data they need to add
17:17:46 <sripriya_> bobh: got it
17:18:13 <bobh> I will try to get the first patchset uploaded this week - shooting for tonight, but that's optimistic
17:18:33 <sridhar_ram> bobh: great..
17:18:39 <sripriya_> thanks
17:18:45 <sridhar_ram> bobh: couldn't wait to see this tosca-parser integration..
17:18:45 <bobh> global requirements have already picked up the 0.4.0 tosca-parser change
17:19:01 <sridhar_ram> bobh:  However I like to discuss the our usage and working model with heat-translator code base...
17:19:03 <bobh> sridhar_ram: it's pretty cool, if I do say so myself
17:19:49 <sridhar_ram> bobh: I've been browsing the code in heat-translators tosca -> hot converter .. #link https://github.com/openstack/heat-translator/blob/master/translator/hot/tosca/tosca_compute.py
17:20:24 <sridhar_ram> it is written nicely and fairly straight forward...
17:20:36 <sridhar_ram> here are some concerns I've ...
17:21:03 <sridhar_ram> fyi, I'm a member of tosca nfv profile working group in OASIS..
17:21:19 <sridhar_ram> .. the simple profile for nfv will undergo some changes
17:22:10 <sridhar_ram> instead of churning heat-translator project for tosca-nfv translations, I'd suggest we should so the translations in tacker project itself..
17:22:19 <sridhar_ram> .. for 1 or 2 dev cycles
17:22:39 <sridhar_ram> *do the translations ...
17:23:05 <sridhar_ram> another factor in this equation is MulltiSite..
17:23:19 <sridhar_ram> Tacker going to land VNFs in different OpenStack versions...
17:23:46 <sridhar_ram> .. hence might need to translator to slightly different HOT template syntax based on the target openstack version..
17:24:27 <sridhar_ram> So I propose if we can do the toscatemplate -> hot in tacker itself and then push into to heat-transltor project once things settle down ?
17:24:43 <sridhar_ram> bobh: team: thoughts ?
17:24:56 <bobh> I think that's a lot of extra work up front and I don't know that there will be much benefit
17:25:12 <dkushwaha_> sridhar_ram, yes, translation in tacker project itself will be a better approach
17:25:22 <sridhar_ram> bobh: can you characterize the extra work ?
17:25:24 <bobh> I would like to see us use the existing heat-translator functionality until we find that there are issues and then deal with the specific issues
17:25:40 <bobh> sridhar_ram: duplication of the existing heat-translator code
17:25:52 <bobh> sridhar_ram: unless you want to fork it and pull it in
17:26:32 <sripriya_> sridhar_ram: even if we extend too far from the existing heat translator proj. and when we finally end up merging code to the project, will that be a problem or go through some churn again?
17:26:37 <bobh> heat-translator provides support for lifecycle interfaces that I think we can take advantage of to get functionality we dont have now
17:26:55 <sridhar_ram> bobh: in the proposed working model I see we first run the ToscaTemplate through heat-translator. We need to any way pre-process and post process HOT template returned by heat-transltor
17:27:13 <bobh> sridhar_ram: Right - that has always been the plan
17:27:50 <sridhar_ram> bobh: so we will be in some HOT template generation business anyway even if we use heat-translator
17:27:51 <bobh> sridhar_ram: we can analyze the post-processing that we do to the HOT template and determine if it needs to be pushed to heat-translator as an enhancement
17:28:18 <bobh> sridhar_ram: manipulation is not the same as generation
17:28:43 <sridhar_ram> bobh: well, looking at the code in https://github.com/openstack/heat-translator/blob/master/translator/hot/tosca/tosca_compute.py ...
17:28:58 <sridhar_ram> bobh: .. we don't need 90% of the code in there around flavors and images
17:29:12 <sridhar_ram> bobh: the question I've ..
17:29:22 <bobh> sridhar_ram: right, but we'll never encounter it anyway
17:29:43 <sridhar_ram> is there a way we can use heat-translator as a "util" library..
17:29:56 <bobh> sridhar_ram: isn't that what we are doing anyway?
17:30:09 <sripriya_> bobh: i thought the same too
17:30:10 <sridhar_ram> .. and maintain say /hot/tosca/tosca_vdu.py in tacker for near team
17:30:46 <bobh> oh - you want to make additional HOT resources available to the existing heat-translator code
17:30:50 <bobh> interesting idea
17:31:02 <sridhar_ram> bobh: my point was .. should be tie urself for such a small HOT template resp back from heat-translator...
17:31:09 <sridhar_ram> bobh: Exactly...
17:31:10 <bobh> provide a search path or inheritance model for the HOT resources
17:31:25 <sridhar_ram> bobh: .. with the plan of merging it back into heat-translator once things settle in..
17:31:46 <sridhar_ram> bobh: there is also an issue of developer / community angle here...
17:31:58 <bobh> I think if you look at some of the more complex TOSCA examples you can see the power of the existing translator
17:32:16 <sridhar_ram> it would be odd to bounce tacker dev resource off to different projects.. it will slow us down
17:32:47 <sridhar_ram> bobh: totally understand the benefit .. particularly the lifecycle interface you pointed out...
17:32:48 <bobh> I guess I need a better idea of what these changes are that are coming and why they would be so disruptive to the existing model/plan
17:33:20 <bobh> With the existing inheritance model I don't think there is much we can't do
17:33:32 <sridhar_ram> bobh: imagine all the things in our pipeline... auto-resource, efficient placement, scaling, service chaining...
17:33:54 <sridhar_ram> we can't keep bouncing the devs bringing in these feature off to heat-translator first
17:34:29 <bobh> not saying we should - but why duplicate the base template processing instead of just adding in the overlay capabilities that we need to the processed template?
17:35:05 <sridhar_ram> bobh: could we leverage the base template processing using a library approach ?
17:35:08 <sripriya_> sridhar_ram: will tosca_vdu be an overlap of tosca_compute in tacker code base?
17:35:25 <sridhar_ram> sripriya_: it is all up in the air in the standards side...
17:35:42 <bobh> I think it will help to see the first patchset for the parser and you will get a better idea of how the TOSCA modeling works
17:35:49 <sridhar_ram> sripriya_: .. that another reason, to have it in tacker
17:36:41 <sridhar_ram> bobh: but the only way to achieve would be using tacker overlays ?
17:37:03 <bobh> sridhar_ram: that's true no matter who does the HOT template parsing
17:38:22 <sridhar_ram> bobh: okay.. I'm willing to wait to see your 2nd patchset .. is it possible to through a WIP ?
17:38:37 <sridhar_ram> s/through/throw/
17:38:56 <bobh> sridhar_ram: yes - I'll push the first one ASAP and then the second one even though it won't be functional without the heat-translator 0.4.0 release
17:39:41 <sridhar_ram> bobh: sure, however can we see some contours of the 2nd half even if it doesn't work ?
17:40:27 <bobh> sridhar_ram: yes - there really isn't all that much to it, mostly pre-processing the template to remove all of the Tacker-specific objects before sending it to heat-translator for processing
17:40:48 <sridhar_ram> bobh: that will help..
17:40:51 <sridhar_ram> bobh: thanks!
17:40:54 <bobh> sridhar_ram: also need to get the outputs working - I was hung up working on monitoring_policy mappings
17:41:11 <bobh> sridhar_ram: np
17:41:33 <sridhar_ram> anything else on this tosca-tacker integration area ?
17:41:46 <bobh> sridhar_ram: I think it's dead....
17:41:59 <sridhar_ram> :) moving on then...
17:42:17 <sridhar_ram> #topic Mitaka Release Deadline
17:42:36 <sridhar_ram> #info #link  http://releases.openstack.org/mitaka/schedule.html
17:43:19 <sridhar_ram> as you might've seen in the tacker big-tent gerrit discussion.. we need to pick a "release" tag for the project
17:43:45 <sridhar_ram> our intent was to release at least once every six months..
17:44:15 <sridhar_ram> we are lagging behind a bit for a liberty release, hopefully we will catch up soon..
17:44:44 <sridhar_ram> now fast forward to Mitaka .. assume the big tent application goes through ..
17:45:19 <sridhar_ram> .. we need to make a release by April 1st
17:45:58 <sridhar_ram> we have many things in flight for Mitaka...
17:46:23 <sridhar_ram> .. what do you folks think on meeting this deadline with the things under progress ?
17:46:53 <bobh> I think its doable, though might be tight
17:47:20 <sridhar_ram> bobh: I was thinking the same..
17:47:38 <sridhar_ram> sripriya_: for MultiSite ?
17:47:44 <sridhar_ram> vishwanathj: for EPA ?
17:47:55 <vishwanathj> will be able to do it
17:48:24 <sripriya_> sridhar_ram: should be fine, the things i fear is func. testing for all the features if we need to enable gate jobs in infra
17:49:05 <vishwanathj> EPA will have dependencies on bobh patch set...need to discuss with him offline what those would be
17:49:06 <santoshk> +1 on that considering we need atleast 2+ devstacks for it...
17:49:08 <sripriya_> sridhar_ram: i'm not sure how soon we can get it integrated in gate jobs?
17:49:26 <sridhar_ram> sripriya_: agree, we need a T-2 weeks for all features to land and then need some time for gate failure and integration failure to be handled
17:49:34 <sripriya_> yup
17:49:56 <bobh> vishwanathj: If we can get the first part landed it should unblock you at least a little bit
17:50:08 <vishwanathj> bobh ok
17:50:21 <sridhar_ram> that effectively bring us to Mar 18 - 21st for code completion
17:51:05 <sridhar_ram> alright .. I hear it is doable, going to be tight so we need to manage / track things better..
17:51:23 <sripriya_> sridhar_ram: i'm looking for somewhere in march midweek time frame to land in all our feature set code
17:51:45 <sridhar_ram> sripriya_: agree..
17:51:56 <sripriya_> and later get some docs going :-)
17:52:01 <sridhar_ram> Please mark your calendars folks !
17:52:16 <sridhar_ram> ofcourse, docs..
17:52:26 <bobh> and tests - my favorite!
17:52:42 <sripriya_> bobh: that was included with code :P
17:52:43 <sridhar_ram> TC members are already asking abt docs .. it needs a spring cleanup..
17:53:16 <bobh> getting some questions submitted too that would be better handled by the docs
17:53:44 <sridhar_ram> bobh: +1
17:54:05 <bobh> we need to specify the dependency on cloud-init enabled images
17:54:22 <bobh> it's not intuitively obvious to everyone
17:54:52 <sridhar_ram> bobh: absolutely.. we have many such useful features.. we docs to take them to the users
17:55:00 <sridhar_ram> *we need docs
17:55:07 <sridhar_ram> alright.. will update our big-tent application to set the tag to "release-with-intermediary" and Mar 18th is the code-completion date !
17:55:27 <sridhar_ram> moving on ...
17:55:30 <bobh> cool - targets are always a good thing
17:55:39 <bobh> deadlines I mean
17:55:50 <sridhar_ram> bobh: true.. devs need deadlines
17:56:11 <sridhar_ram> #topic Bugs and RFEs
17:56:58 <sridhar_ram> Team - apart from these big features, we need volunteers for smaller RFE (imagine these are mini enhancements) and some critical bugs
17:57:24 <sridhar_ram> I'm specifically looking for help on https://bugs.launchpad.net/tacker/+bug/1543393
17:57:26 <openstack> Launchpad bug 1543393 in tacker "Deprecate and remove device API and CLI from Tacker" [Medium,New]
17:57:52 <sridhar_ram> these are typically 1 - 2 weeks efforts
17:57:59 <dkushwaha_> sridhar_ram, can i pick this ?
17:58:08 <sridhar_ram> dkushwaha_: sure..
17:58:22 <sridhar_ram> dkushwaha_: thanks for stepping up!
17:59:05 <dkushwaha_> sridhar_ram, ok, i will look into this. Thank you :-)
17:59:25 <sridhar_ram> Rest of the wish list is marked with 'mitaka-rfe' tag ... #link https://bugs.launchpad.net/tacker/+bugs?field.tag=mitaka-rfe
17:59:27 <sripriya_> dkushwaha_: ping us on #tacker for any help
17:59:42 <sridhar_ram> times up!
17:59:51 <sridhar_ram> #topic Open Discussion
18:00:08 <sridhar_ram> thanks everyone..
18:00:19 <sridhar_ram> #endmeeting