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