17:03:16 <sridhar_ram> #startmeeting tacker
17:03:17 <openstack> Meeting started Tue Jan 12 17:03:16 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:03:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:20 <openstack> The meeting name has been set to 'tacker'
17:03:26 <sridhar_ram> #topic Roll Call
17:03:30 <vishwana_> o/
17:03:34 <sripriya_> o/
17:03:34 <sridhar_ram> who is here for tacker mtg ?
17:03:35 <tbh> o/
17:03:36 <bobh> o/
17:04:02 <sridhar_ram> vishwana_: sripriya_: tbh: bobh: hi all !!
17:04:09 <sridhar_ram> s3wong: you there ?
17:04:10 <vishwana_> hi all
17:04:37 <sridhar_ram> #topic Agenda
17:04:56 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Jan_12.2C_2016
17:05:41 <sridhar_ram> #topic Big Tent
17:06:21 <sridhar_ram> We had always had plans to apply for big tent for Tacker sometime in mid-Mitaka...
17:06:51 <sridhar_ram> we planned many activities over last many months .. like unit test, functional gate, etc with an eye on this
17:07:06 <sridhar_ram> I think we are at a point to go ahead and do it..
17:07:25 <sridhar_ram> I'd like to quickly poll the folks in this room here ..
17:07:28 <sripriya_> sridhar_ram: cool
17:07:43 <sridhar_ram> (1) Long overdue, lets proceed to apply for Big Tent 2) This is not the right time to apply for Big Tent, we should wait (3) Tacker should not apply for Big Tent
17:07:52 <bobh> 1
17:07:54 <natarajk> 1
17:07:55 <vishwana_> 1
17:08:02 <tbh> 1
17:08:07 <sripriya_> 1
17:08:46 <sridhar_ram> alright.. thats  unanimous !
17:09:37 <sridhar_ram> I started writing up the application for patchset to openstack/governance repo here ... #link https://etherpad.openstack.org/p/tacker-big-tent-writeup
17:10:02 <vishwana_> sridhar_ram, thanks for doing this
17:10:07 <sridhar_ram> please feel free to add / edit / comment (on the side bar)
17:10:13 <sridhar_ram> vishwana_: sure !
17:11:34 <sridhar_ram> I truly believe we have come a long way.. and quite happy we are in a position to do this
17:11:41 <sridhar_ram> thanks to this amazing team..
17:11:49 <vishwana_> how long will it take to get added to the back tent from the time you apply?
17:11:50 <sripriya_> +1
17:12:03 <tbh> +1
17:12:52 <sridhar_ram> vishwana_: AFAIK there is predetermined time, after we apply TC will schedule it for a discussion..
17:13:12 <vishwana_> ok
17:13:19 <ahelkhou> which channel to join the room?
17:13:48 <sridhar_ram> vishwana_: .. it all depends how clean the scope and how contentious the review comments are..
17:14:08 <sridhar_ram> ahelkhou: sorry, I didn't get your question.. can you elaborate ?
17:15:13 <bobh> I think it was typed in the wrong window
17:15:28 <ahelkhou> Sorry my mistake:)
17:15:35 <sridhar_ram> ahelkhou: np !
17:15:52 <sridhar_ram> any other questions on governance and big tent ?
17:16:31 <sridhar_ram> I hope we can push the big-tent patchset by early next week...
17:16:36 <sridhar_ram> lets move on..
17:16:43 <sridhar_ram> #topic Mitaka blueprints
17:17:00 <sridhar_ram> #topic TOSCA parser update
17:17:12 <sridhar_ram> bobh: where do we stand at this point ?
17:17:44 <bobh> The change to allow tosca-parser to work inside the tacker server was merged and should be in the next point release, which I think is 1/25
17:18:21 <brucet> <bobh> I saw you have an etherpad for Tosca / Heat translation
17:18:23 <bobh> The NFV changes to tosca-parser are under review - there is a discussion about the best approach to take, and once that is resolved it should merge fairly quickly - hoping to get that in the same point release
17:18:57 <sridhar_ram> bobh: that's good news .. particularly if it makes 1/25
17:19:00 <bobh> brucet: Yes - the next step is to make sure Heat Translator can process all of the objects appropriately
17:19:33 <brucet> I was looking for a similar document for the original Tosca / Heat translator
17:19:41 <bobh> in parallel I am working on a spec to document the tacker changes - we should be able to support both template types for a period of time, then deprecate the old and continue with TOSCA only
17:20:34 <bobh> brucet: If you find one let me know :-)  I have only been able to walk through the code at this point
17:20:58 <brucet> <bobh> Same with me
17:21:16 <sridhar_ram> bobh: that's sounds like a plan... I know it quite tricky waddling across these projects!
17:21:21 <bobh> I need to put together some test templates for TOSCA NFV that can be used for code testing
17:21:22 <brucet> <bobh> Is that how you got the mappings in the Etherpad?
17:21:51 <bobh> brucet: The mappings in the Etherpad came from my reading of the OASIS NFV document and my basic understanding of Heat and OpenStack
17:22:00 <brucet> OK. Got it
17:22:20 <brucet> <bobh> I will review it
17:22:29 <bobh> brucet: There is some discussion about whether a VDU should map to Compute or SoftwareComponent - hopefully sridhar_ram will make some progress on that this week
17:23:00 <brucet> OK
17:23:22 <bobh> We may also need to define our own objects to add the additional properties we need for mgmt_ip and monitoring_policy - they will derive from the NFV objects
17:23:33 <bobh> or from the base profile objects
17:24:10 <bobh> So Tacker templates may need to import some tacker definitions in addition to using the version specification for TOSCA NFV
17:24:16 <brucet> <bobh> Do you mean add new Heat resources or something on the side of Heat?
17:24:36 <sridhar_ram> bobh: yes, heading to ETSI Information Model meetup this week (as a member of TOSCA group)... will try to get some clarification on Compute vs SofwareComponent. Templates based on Compute looks cleaner.
17:24:59 <bobh> brucet: No - Tacker needs information in the template that will not map to Heat, so we will probably need to "prune" that information out of the template before it gets sent to heat-translator
17:25:36 <brucet> <bobh> OK. Will these items drive a separate Tacker API then?
17:26:39 <bobh> brucet: No - same API - the template will determine which parser is used - if there is a version tag in the template it will use the TOSCA parser, otherwise it will use the native YAML parser
17:26:53 <brucet> <bobh> For example, I believe you will have objects defined in the templatethat would end up driving the Tacker SFC API
17:27:18 <bobh> brucet: That could be
17:27:38 <sridhar_ram> brucet: eventually, yes.. when we start supporting VNFFGD descriptors
17:27:46 <bobh> brucet: It would require an architecture change (which is overdue anyway)
17:28:02 <sridhar_ram> brucet: .. initial TOSCA parser integration will not have Forwarding Graph support
17:28:11 <brucet> <sridar_ram> exactly
17:29:02 <sridhar_ram> brucet: our hope there, Heat resources will we created for the networking-sfc effort and this is something we can eventually consume.
17:29:35 <brucet> <sridar_ram> Right. Makes sense.
17:29:52 <brucet> Same for multi-site?
17:30:43 <sridhar_ram> brucet: we will take up discussing multi-site soon.. hold your thoughts
17:30:48 <brucet> OK
17:31:02 <sridhar_ram> bobh: using Tacker types to overlay over tosca-nfv is reasonable ..
17:31:22 <sridhar_ram> bobh: .. the main Tacker overlays would be for monitoring and mgmt_driver, correct ?
17:31:42 <bobh> sridhar_ram: I think so - also config is not supported by TOSCA so need to overlay that too
17:32:03 <bobh> sridhar_ram: or put it into the lifecycle - which might not be a bad idea
17:32:50 <sridhar_ram> bobh: lifecycle could be an option.. I'm unclear if tosca-parser or heat-translator will play a role there
17:33:14 <sridhar_ram> bobh: .. it is something that tacker need to drive
17:33:22 <bobh> sridhar_ram: needs more investigation
17:33:58 <sridhar_ram> anything else from your side?
17:34:09 <bobh> sridhar_ram: I think that covers it
17:34:28 <sridhar_ram> now, lets jump of discussing the auto-resource which depends on tosca parser changes...
17:34:35 <sridhar_ram> #topic Auto Resource Creation
17:34:48 <sridhar_ram> tbh: can you give an update ?
17:35:23 <sridhar_ram> BP link is #link https://review.openstack.org/#/c/250291/
17:35:51 <tbh> sridhar_ram, sure, as we decided in last meeting, we have to create flavor/network at vnf creation time and image in onboarding VNFD
17:36:22 <tbh> sridhar_ram, but the issue is maintaing the state of VNFD in the parametrized case
17:37:57 <sridhar_ram> tbh: I'm looking for the wider team's input here.. my personal opinion / way forward is we don't allow image URL parameterizable in VNFD
17:38:22 <sripriya_> agree
17:38:27 <bobh> sridhar_ram: I agree - that would be a one-time action
17:39:12 <bobh> sridhar_ram: although there is an argument for allowing different images for the same VNFD, where you might change versions of the base image without changing the VNFD
17:39:37 <vishwana_> what would be the issue with image URL parameterization in VNFD? .... Is the issue that multiple duplicate images would be created in glance
17:40:23 <bobh> vishwana_: if there was logic to look for the image in glance first and then only go get it from the URL if it's not there, that might work
17:40:55 <sridhar_ram> bobh:  agree, that scenario goes into VNF image management realm called out in ETSI MANO ...
17:41:00 <vishwana_> bobh, ok
17:41:01 <bobh> vishwana_: but I think the question is when to do image processing - if it only happens at VNFD-create, then no need to paramaterize
17:41:16 <bobh> if image processing is done at VNF-create, then the parameter makes sense
17:41:52 <vishwana_> bobh, thanks, now I understand the issue
17:42:22 <sridhar_ram> bobh: that's an interesting option.. to look for the image in glance during vnf create .. .. if not download
17:42:46 <sridhar_ram> another thought, we might need to support VNFD in CSAR zip bundle format down the line .. where the zip might have the qcow2 image
17:42:46 <vishwana_> we have to start using nova-api
17:42:55 <bobh> sridhar_ram: not sure you could count on the name - might need MD5sum
17:43:31 <bobh> sridhar_ram: +1 - tosca-parser already supports CSAR files, so we might want to consider it
17:43:41 <sridhar_ram> bobh: for md5sum we still need to download and that will increase vnf creation time..
17:43:45 <tbh> sridhar_ram, bobh  how will we check for the same image in glance?
17:44:10 <sridhar_ram> tbh: bobh: we got to use name or uuid.. md5sum is not practical
17:44:12 <tbh> sridhar_ram, bobh  I mean we can have conflicts with image details  with other images
17:44:26 <bobh> tbh: I think it would need to be md5sum values
17:45:23 <sridhar_ram> let me summarize the options ...
17:45:36 <tbh> sridhar_ram, here using uuid or name, we cannot check the valid image
17:45:42 <sridhar_ram> 1) VNFD image uri without parameterization
17:46:00 <sridhar_ram> 2) VNFD in CSAR zip with qcow2 bundled in
17:46:25 <sridhar_ram> 3) VNFD has parameterized URI, download and glance upload happens in VNF creation time
17:46:48 <sridhar_ram> (1) and (2) will have image in place in glance for vnf-creation ...
17:47:04 <sridhar_ram> we could potentially support one or more of these options...
17:47:36 <sridhar_ram> any votes / preferences ?
17:47:50 <vishwana_> I would vote for 3) for the initial version of the implementation even though it would create duplicate images during subsequent VNF creation.
17:48:15 <bobh> vishwana_: So would you also delete the image when the VNF is deleted?
17:48:21 <tbh> for option 3, I am not sure, how perfectly we can check that image and I prefer option 1 for now
17:48:25 <vishwana_> bobh yes
17:48:40 <sripriya_> 3) would be take a really long time to complete, including download, upload and actual vnf creation
17:49:00 <tbh> vishwana_,  but we are storing a huge same images again and again
17:49:17 <tbh> sripriya_, agree
17:49:38 <sridhar_ram> If we do (3) we need to figure out a way to avoid duplicate glance images .. we might resort to download, compute md5sum and upload only if needed
17:50:04 <vishwana_> if we are OK with introducing nova_api then we can still have a modified version of (3
17:50:17 <sridhar_ram> tbh: +1, we will run out of glance image space !
17:50:54 * sridhar_ram 10 min mark
17:51:38 <sridhar_ram> I'm fine going with (1) for now with a plan to support (2) down the line...
17:51:49 <vishwana_> if image space is an issue and which it will be and we do not want to introduce nova-api, then 1 is the option
17:51:59 <ahelkhou> Sridhar_ram: +1
17:52:11 <sridhar_ram> we can introduce an explicit vnfd-image-update operation to take care of VNFD image mgmt
17:52:37 <sridhar_ram> bottomline my vote would be reconcile image at VNFD creation time.. one way or the other
17:52:38 <vishwana_> however, if 1) starts making VNFD a stateful object, I have a tough time understanding the value proposition of making VNFD a stateful object
17:53:01 <sridhar_ram> small correction, I mean at VNFD object level
17:53:30 <bobh> a VNFD could also reference multiple images
17:53:33 <sridhar_ram> vishwana_: I'm also keeping an eye on csar bundle support
17:53:54 <sridhar_ram> bobh: for multi VDUs ?
17:54:34 <sridhar_ram> we are running out of time folks..
17:54:35 <tbh> sridhar_ram, I need to know more about csar support after mtg
17:54:38 <bobh> sridhar_ram: yes
17:54:52 <sridhar_ram> lets continue in the tacker spec.... good discussion though
17:55:18 <sridhar_ram> tbh: can you please capture the options discussed here in the spec and have folks weigh in and pick a winner
17:55:29 <tbh> sridhar_ram, sure
17:55:51 <vishwana_> I would be interested in the csar bundle support ... will watch out for that discussion in the tacker channel or the gerrit review
17:55:57 <sridhar_ram> tbh: quickly for flavor and network .. you might need to check if heat-translator supports flavor creation and network creation
17:56:17 <vishwana_> sridhar_ram, are you restricting the options to the discussed 3 or you are OK with other options
17:56:32 <sridhar_ram> tbh: please reach out to spzala & bobh
17:56:57 <tbh> sridhar_ram, they are not supporting flavor creation
17:57:01 <vishwana_> sridhar_ram, tbh, FYI:I have verfied that flavor and network creation is supported by heat
17:57:02 <sridhar_ram> vishwana_: we should be open other options as well .. as long as they are viable..
17:57:17 <tbh> sridhar_ram, heat-translator will provide a matched flavor otherwise null
17:57:39 <sridhar_ram> tbh: that's a bummer.. can that be enhanced to do flavor creation ?
17:58:08 <ahelkhou> sridhar_ram: will Tacker allow to specify extra-spec in the flavor definition?
17:58:25 <tbh> sridhar_ram, they don't want to create any openstack resources, just to translate the templates which is  purpose heat-translator
17:58:35 <sridhar_ram> ahelkhou: that's the plan for efficient VNF placement
17:58:49 <tbh> *purpose of
17:58:57 <sridhar_ram> tbh: okay... lets take it offline..
17:59:13 <tbh> sridhar_ram, sure
17:59:15 <sridhar_ram> lets continue in gerrit.
17:59:21 <sridhar_ram> #topic Open Discussion
17:59:40 <brucet> Is there an overall Tacker spec?
17:59:41 <sridhar_ram> brucet: sorry, we didn't had time for multi-site discussion..
17:59:47 <brucet> No problem
17:59:57 <sridhar_ram> brucet: ..lets plan to take it first thing next week..
18:00:02 <brucet> I am having a hard time seeing the forest through the trees.
18:00:12 <sridhar_ram> brucet: unfortunately no!
18:00:19 <sridhar_ram> out of time..
18:00:32 <brucet> OK
18:00:46 <sridhar_ram> quick reminder .. Tacker midcycle is on Jan 28th, 29th in San Jose, CA.. please plan to attend if you can
18:01:08 <sridhar_ram> #link https://etherpad.openstack.org/p/tacker-mitaka-midcycle
18:01:10 <sridhar_ram> #endmeeting