16:01:49 <sridhar_ram> #startmeeting tacker
16:01:50 <openstack> Meeting started Tue Aug 23 16:01:49 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:53 <openstack> The meeting name has been set to 'tacker'
16:01:59 <sridhar_ram> #topic Roll Call
16:02:06 <vishwanathj> o/
16:02:07 <bobh> o/
16:02:08 <sripriya> o/
16:02:12 <sridhar_ram> Hi folks, who is here?
16:02:12 <neel> o/
16:02:33 <tbh> o/
16:02:44 <n-harada> o/
16:02:44 <diga> o/
16:02:59 <sridhar_ram> Greetings everyone!
16:03:06 <sridhar_ram> let's start...
16:03:25 <sridhar_ram> #topic Agenda
16:03:29 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Aug_23rd.2C_2016
16:03:46 <sridhar_ram> there are many items.. we will cover as much as possible today
16:04:05 <sridhar_ram> obviously Newton release related things are higher priority
16:04:18 <sridhar_ram> #topic Annoucements
16:04:32 <janki> o/
16:04:37 <sridhar_ram> janki: hi
16:04:43 <janki> sridhar_ram, hey
16:05:06 <sridhar_ram> I'm proposing to expand Tacker Core team with Yong Sheng Gong
16:05:09 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/102126.html
16:05:31 <janki> sridhar_ram, was just reading that of yours
16:05:36 <janki> sridhar_ram, +1 from me
16:05:47 <sridhar_ram> Please provide your inputs to the thread in the ML
16:05:58 <s3wong> hello
16:06:13 <sridhar_ram> s3wong: ^^^ gongysh is proposed to joined to tacker-core
16:06:27 <s3wong> sridhar_ram: that is great!
16:06:44 <s3wong> sridhar_ram: he certainly has made the contributions and done a lot of reviews
16:06:56 <sridhar_ram> he is not in the channel due to the tz, which we need to fix the mtg timing - hopefully post newton release..
16:07:20 <sridhar_ram> anything else to announce?
16:07:44 <sripriya> sridhar_ram: tackerclient release?
16:08:05 <sridhar_ram> sripriya: yes, thanks for reminding..
16:08:19 <sripriya> sridhar_ram: np
16:09:01 <sridhar_ram> a checkpoint tackerclient 0.6.0 is released now
16:09:03 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-announce/2016-August/001461.html
16:09:19 <sridhar_ram> This includes auto-scaling and event-logging api changes..
16:10:04 <sridhar_ram> we still need to wait for https://review.openstack.org/#/c/358612/ to merge for this to show in your nearest devstack :)
16:10:24 <sridhar_ram> Note, this is not the final new tackerclient release.. we will get to it shortly
16:10:33 <sridhar_ram> #topic Newton Release Status
16:11:00 <sridhar_ram> We just have 3 days left to make your final tackerclient changes for Newton..
16:11:03 <sridhar_ram> #link http://www.timeanddate.com/countdown/to?iso=20160826T11&p0=283&msg=Tacker+Client+Release&font=slab
16:11:25 <diga> sridhar_ram: https://bugs.launchpad.net/python-tackerclient/+bug/1524243 - pending on me, will push the patch in sometime
16:11:25 <openstack> Launchpad bug 1524243 in python-tackerclient "infra driver is fixed by python tacker client" [High,New] - Assigned to Digambar (digambarpatil15)
16:11:44 <sridhar_ram> diga: looking up
16:12:28 <diga> sridhar_ram: was on vacation in the last week so got late, sorry for that
16:12:33 <sridhar_ram> diga: that is a biggee, we need that deprecation warning to merge .. this is a MUST do
16:13:10 <diga> sridhar_ram: yes, I am pushing in next half an hour
16:13:15 <sridhar_ram> diga: thanks, again .. the scope is just to throw deprecation warnings for mgmt_driver and infra_driver in the API
16:13:34 <sripriya> diga: will you be handling mgmt_driver deprecation as well?
16:13:37 <diga> okay
16:13:41 <diga> yes
16:13:50 <sripriya> diga: thanks
16:13:54 <sridhar_ram> sripriya: it make sense to do this in one shot..
16:14:05 <sripriya> sridhar_ram: regarding https://bugs.launchpad.net/tacker/+bug/1591361
16:14:05 <openstack> Launchpad bug 1591361 in tacker "Fix data handling for vnfd, config and param yaml templates" [Medium,New] - Assigned to Janki Chhatbar (jankihchhatbar)
16:14:09 <diga> sripriya: np
16:14:11 <sripriya> sridhar_ram: yes
16:14:31 <sripriya> sridhar_ram: are we only looking for deprecation warning to go into newton?
16:14:56 <janki> sripriya, as of yesterday's discussion with sridhar_ram, we decided to move it to Ocata
16:15:04 <diga> No, we have decided to remove those
16:15:35 <janki> sridhar_ram, sripriya, the above mentioned bug
16:16:03 <sridhar_ram> sripriya: let's quickly recap as there is some confusion here...
16:16:10 <diga> janki: wait wait, lets finish on one thing
16:16:51 <janki> diga, I replied to the sripriya's comment on bug 1591361
16:16:51 <openstack> bug 1591361 in tacker "Fix data handling for vnfd, config and param yaml templates" [Medium,New] https://launchpad.net/bugs/1591361 - Assigned to Janki Chhatbar (jankihchhatbar)
16:16:51 <sridhar_ram> sripriya: janki: we *cannot* deprecate the current attributes: carrying raw-string vnfd until we introduce the vnfd: <json>
16:17:24 <sripriya> sridhar_ram: okay got it
16:17:43 <sridhar_ram> diga: the deprecation related to the one you are handling .. mgmt_driver and infra_driver .. are orthogonal to this discussion
16:18:27 <diga> okay
16:18:35 <sridhar_ram> sripriya: janki: my current sense is we are cutting too close to make this API change this late, until you folks can convince me this is a fairly a trivial change that can be handled in next couple of days
16:18:42 <sridhar_ram> sripriya: janki: thoughts ?
16:19:15 <janki> sridhar_ram, lets move it to ocata
16:20:01 <sripriya> sridhar_ram: let me evaluate the changes today and get back?
16:20:13 <sridhar_ram> sripriya: sure..
16:20:16 <janki> from what Isee, there is no deprecation involved. completing removing "string" and adding "json" should be done
16:21:12 <sridhar_ram> janki: we *cannot* remove string attributes:vnfd .. that is by API policy, we never remove .. we can only deprecate in release X and remove it in release X+1
16:21:54 <sridhar_ram> janki: there are users who are using Tacker directly using its API.. not just the tackerclient CLIs
16:22:03 <sridhar_ram> janki: we cannot break them
16:22:42 <janki> sridhar_ram, ohh, ohk. So adding just the dperecation warning should'nt take much time.
16:22:59 <janki> sridhar_ram, it would be just a line in client.py right?
16:23:18 <sridhar_ram> janki: let sripriya take a swag at this .. and we can go from there
16:23:32 <janki> sridhar_ram, sure :)
16:23:32 <sridhar_ram> we need to get to other things in this mtg
16:24:08 <sridhar_ram> Folks - if you see anything in https://review.openstack.org/#/q/project:openstack/python-tackerclient .. that needs to go into Newton.. please flag it to the core team ASAP
16:24:23 <sridhar_ram> otherwise, it will miss Newton!
16:25:02 <sridhar_ram> From my scan, https://review.openstack.org/341389 (VNFFG client) is the significant pending this..
16:25:26 <sridhar_ram> and the two issues we discussed today - diga's deprecation fix and json vnfd
16:25:37 <sridhar_ram> anything else with client impacting change?
16:25:57 <sridhar_ram> #link https://etherpad.openstack.org/p/tacker-newton-release-priority
16:26:17 <sridhar_ram> Looking at ^^^
16:27:26 <sridhar_ram> sripriya: https://review.openstack.org/#/c/344592/ - is this a must do for Newton ?
16:28:18 <sripriya> sridhar_ram: i’m not sure when exactly will the keystoneclient lib will be removed in favor of keystoneauth1
16:28:43 <sridhar_ram> sripriya: then i would punt this to Ocata.. we have enough in the plate now
16:29:21 <sripriya> sridhar_ram: there is no specific release mentioned in the deprecation bp
16:29:31 <sripriya> sridhar_ram: so yes, we can move this to Ocata
16:29:35 <sripriya> sridhar_ram: https://blueprints.launchpad.net/python-keystoneclient/+spec/deprecate-to-ksa
16:29:40 <sridhar_ram> sripriya: okay, lets punt!
16:29:58 <sridhar_ram> Moving to areas beyond client, auto-scaling and event-log has merged..
16:29:59 <sridhar_ram> VNFFG and alarm-monitoring are pending
16:30:13 <sridhar_ram> they have few weeks to wrap it up..
16:30:45 <sridhar_ram> Team - please continue to help out picking https://etherpad.openstack.org/p/tacker-newton-release-priority
16:31:02 <janki> VNFFG horizon support patch in review https://review.openstack.org/#/c/347779/
16:31:04 <sridhar_ram> bobh: any heads from the tosca-parser / heat-translator world for Newton ?
16:31:16 <sridhar_ram> *heads up
16:31:40 <sridhar_ram> janki: again, we have 2 - 3 week window to wrap it up
16:31:44 <bobh> sridhar_ram: nothing major that I know of - substitution_mapping is in the works I believe, otherwise just minir features
16:31:56 <sridhar_ram> bobh: thanks..
16:31:57 <bobh> s/minoir/minor/
16:32:15 <janki> sridhar_ram, yes. Just pointed it. No other intentions :)
16:32:31 <tbh> sridhar_ram, bobh substituion_mappings initial patch got merged
16:32:34 <sridhar_ram> janki: sure, no worries :)
16:33:10 <sridhar_ram> bobh: I know KanagarajM is looking for a heat-translator change to fix a bug in auto-scaling .. this fix is needed for selective VDU scaling, which is a must do Newton
16:33:54 <sridhar_ram> tbh: bobh: if you folks can help to guide that fix in heat-trans side, that would greatly help
16:34:35 <sridhar_ram> anything else on Newton ?
16:34:52 <tbh> sridhar_ram, sure
16:35:58 <sridhar_ram> topic Barcelona Design Summit space
16:36:06 * sridhar_ram expects this to be a quick one
16:36:17 <sridhar_ram> Currently we are allocated "Tacker: 1fb, 3wr, cm:half"
16:36:47 <sridhar_ram> which translates to 1 big Fishbowl slots, 3 Working Session and 1 Contributor meetup
16:36:58 <sridhar_ram> I think this is more than enough..
16:37:07 <sridhar_ram> anyone thinks we need more?
16:37:48 <sridhar_ram> I'm going w/ no.. unless i hear any specific ask
16:37:51 <sridhar_ram> moving on..
16:38:00 <sridhar_ram> #topic Late Newton BPs
16:38:24 <sridhar_ram> #info VNF create with direct TOSCA template input
16:38:41 <sridhar_ram> #link https://blueprints.launchpad.net/tacker/+spec/vnf-inline-template
16:39:05 <sridhar_ram> This has been a blocked for some NFVOs to start using Tacker as the VNFM
16:39:15 <sridhar_ram> *blocker
16:39:38 <sridhar_ram> currently they need to push a VNFD first, followed by a vnf-create..
16:39:54 <sridhar_ram> this BP is asking to support a vnf-create where VNFD template is passed in ..
16:40:07 <sridhar_ram> .. no VNFD template is pre-populated..
16:40:11 <sridhar_ram> thoughts ?
16:40:17 <sridhar_ram> bobh: <poke>
16:40:55 <bobh> sridhar_ram: sorry, got pulled away - let me catch
16:41:02 <sridhar_ram> bobh: np
16:41:29 <s3wong> sorry, guys. Need to drop off; will read the log later
16:41:35 <sripriya> sridhar_ram: will this tomorrow be applicable for vnffg too?
16:41:49 <bobh> sridhar_ram: seems like a reasonable request - could always put it into the catalog and deploy it all in one motion
16:41:52 <sridhar_ram> sripriya: hmm, good question..
16:42:24 <vishwanathj> if the VNFD is not stored in the catalog, will there be a column in VNF that will capture the VNFD info?
16:42:26 <sridhar_ram> bobh: .. it would be nice, if the template doesn't even gets into the catalog
16:43:02 <sridhar_ram> vishwanathj: yes, it need to be
16:43:18 <vishwanathj> ok, then it makes sense
16:43:42 <sridhar_ram> anyone see a major risk to approve it this late.. ?
16:43:44 <sripriya> sridhar_ram: so this is a separate workflow other than catalog management
16:43:57 <sridhar_ram> sripriya: yes..
16:44:31 <sridhar_ram> sripriya: a one short usage of tacker - to directly get to vnf-create..
16:44:45 <mike_m> Hi, isn't this more of an optimization of api calling?
16:44:49 <sridhar_ram> the assumption is the required mgmt-drivers and mon-drivers are already in place
16:44:53 <vishwanathj> would this also support providing a params file along with VNFD template?
16:44:57 <sripriya> sridhar_ram: ok, but we will not save this to catalog db. just to understand this clearly
16:45:33 <sridhar_ram> mike_m: agree, you can look at this that way.. basically use one API to get both info but in the backend do the two operation that we do today
16:45:51 <bobh> sridhar_ram: this could be done via shell script wrapper
16:45:54 <mike_m> true, or get the NVFO to do the 2 calls
16:46:37 <mike_m> (NFVO)
16:47:14 <sridhar_ram> mike_m: that doesn't gel well for the NFVO workflow, where we can expect *every* vnf-create to turn into {vnfd-create + vnf-create} .. there will be *ton* of VNFD catalog entries in the Tacker.. which will be ugly
16:47:38 <mike_m> ok I understand the use case better
16:47:46 <bobh> sridhar_ram: they want custom VNFDs for every VNF deployment?
16:48:37 <sridhar_ram> bobh: not necessarily, they don't want Tacker to host a Catalog. these are maintained in either in NFVO or at times even a component adjacent to NFVO
16:49:21 <bobh> sridhar_ram: ok - interesting use case
16:49:51 <tbh> sridhar_ram, but is it not deviating from the standard?
16:49:55 <sridhar_ram> this goes into the realm of delivering a "version" of Tacker that is purely a "VNFM" .. no NFVO-ish creep
16:50:46 <sridhar_ram> tbh: not necessarily, we have smudged the layering a bit already.. infact, remember we discussed a bit more pure NFVO-VNFM separation in the midcycle ?
16:51:11 <sripriya> sridhar_ram: + catalog separation
16:51:12 <bobh> sridhar_ram: so are there standard APIs that decouple the two, so VNFM/vnf-create would always accept a VNFD from the NFVO side?
16:51:22 <sridhar_ram> sripriya: yep
16:51:55 <sridhar_ram> bobh: there is no API standardization, AFAIK.. there is an effort in OPNFV to do that though..
16:52:10 <sridhar_ram> bobh: we should present Tacker's API as one of the seeds for that effort
16:52:48 * sridhar_ram notes 8mins left in the mtg
16:53:15 <sridhar_ram> overall, looks we might need more time to discuss this .. perhaps a tacker-specs is warranted to discuss this through ?
16:53:28 <mike_m> yes I agree
16:53:44 <sridhar_ram> mike_m: okay..
16:54:44 <sridhar_ram> back to nfvo-vnfm separation, again from the midcycle, we envisioned a possible subproject within official Tacker umbrella to move all NFVO-ish feature out of the VNFM portions
16:54:56 <sridhar_ram> something for you all to think about :)
16:55:12 <sridhar_ram> github.com/openstack/tacker-nfvo :)
16:55:16 <tbh> sridhar_ram, are we ignoring client sides changes or we also include as apart of this BP?
16:55:31 <tbh> *as part
16:55:42 <sridhar_ram> tbh: thats where the bind is.. as there will be API / client changes..
16:56:01 <sridhar_ram> tbh: i think this is practically impossible for Newton..
16:56:19 <tbh> sridhar_ram, yup I think so
16:57:00 <sridhar_ram> I know we touched a bit of Ocata.. which is natural consider where we are and the right thing to do
16:57:11 <sridhar_ram> let's take up Ocata grooming next week
16:57:50 <sridhar_ram> one major thing I'd like to bring up for Ocata track .. is decomposed vim-drivers (infra_driver)..
16:58:10 <sridhar_ram> .. so that we can start supporting many of them
16:58:52 <sridhar_ram> Quickly on VNFC ..
16:58:54 <sridhar_ram> #link https://review.openstack.org/#/c/339798/
16:59:23 <sridhar_ram> anyone have issues to approve this with a scope only to support Heat SoftwareComponent ?
16:59:26 <tbh> and also implementation https://review.openstack.org/#/c/358321/
16:59:39 <sridhar_ram> well, we are out of time for today..
16:59:45 <sridhar_ram> lets take it up in gerrit
16:59:58 <sridhar_ram> there is no client changes for VNFC.. so there is room
17:00:11 <sridhar_ram> bobh: mike_m: please review above vnfc spec
17:00:14 <sridhar_ram> thanks everyone
17:00:19 <sridhar_ram> #endmeeting