17:00:49 <sridhar_ram> #startmeeting tacker
17:00:50 <openstack> Meeting started Tue Feb 16 17:00: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.
17:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:53 <openstack> The meeting name has been set to 'tacker'
17:00:58 <sridhar_ram> #topic Roll Call
17:01:02 <prashantD> hi
17:01:07 <s3wong> hello
17:01:07 <tbh> o/
17:01:10 <dkushwaha_> o/
17:01:11 <sripriya> o/
17:01:14 <brucet> hello
17:01:39 <sridhar_ram> hi everybody!
17:01:50 <sridhar_ram> lets get started..
17:01:56 <sridhar_ram> #topic Agenda
17:02:09 <sridhar_ram> #link  https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Feb_16.2C_2016
17:02:23 <sridhar_ram> #topic Announcements
17:02:27 <vishwanathj> o/
17:02:40 <sridhar_ram> vishwanathj: hi
17:02:54 <vishwanathj> Hi sridhar_ram, Hello All
17:03:14 <sridhar_ram> Tacker big tent application is ongoing in gerritt - #link https://review.openstack.org/#/c/276417
17:03:34 <sridhar_ram> lots of healthy discussions and debates... include a short NFV primer as well :)
17:04:18 <sridhar_ram> OpenStack Summit Talks Voting is in progress..
17:04:25 <sridhar_ram> #link https://www.openstack.org/summit/austin-2016/vote-for-speakers
17:04:37 <sridhar_ram> Deadline to vote is tomorrow February 17 at 11:59pm PST / February 18 at 7:59am UTC).
17:05:00 <sridhar_ram> Here are some talks related to Tacker, if you like these proposals please help to vote them in!
17:05:10 <vishwanathj> sridhar_ram thanks for sharing the link
17:05:25 <sridhar_ram> #link  https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/7476
17:05:32 <sridhar_ram> #link  https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/7480
17:05:38 <sridhar_ram> #link  https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7001
17:05:45 <sridhar_ram> #link  https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7804
17:05:59 <sridhar_ram> the last one was cool, an Hands on Lab on Tacker :)
17:06:30 <sripriya> great idea
17:06:33 <sridhar_ram> If you have anything related to NFV orchestration please feel free to share here!
17:07:51 <sridhar_ram> We are in R-7 weeks in the release towards Mitaka .. #link http://releases.openstack.org/mitaka/schedule.html
17:08:09 <sridhar_ram> and just 5 weeks away from code completion target...
17:08:25 <sridhar_ram> please work towards wrapping your specs / code reviews
17:08:48 <sridhar_ram> anything else from anyone here to announce / heads up ?
17:09:45 <sridhar_ram> moving on..
17:09:55 <sridhar_ram> #topic Auto Resource Creation
17:10:02 <sridhar_ram> #link https://review.openstack.org/#/c/250291/
17:10:14 <sridhar_ram> tbh: give you provide some updates
17:11:08 <tbh> sridhar_ram, I have updated the patch to satisfy jenkins. And I am not sure, why do we need an extra table, to store image details alone
17:12:18 <sridhar_ram> tbh: just a suggestion .. but what I had in mind was, if tacker is uploading an image in glance it shd have a record of that
17:13:00 <sridhar_ram> tbh: imagine a Horizon UI in the future that will show all images "referenced" in VNFs
17:13:51 <tbh> sridhar_ram, agree, that's why we are storing the created_resources dict in "devicetemplates" table
17:15:27 <sridhar_ram> tbh: I was wondering if it would be cleaner to have it in a separate table..
17:15:52 <sridhar_ram> .. and have devicetemplate refer to that entry
17:17:08 <tbh> sridhar_ram, sure, in that case ..
17:17:37 <sridhar_ram> the reason for this suggestion is I'm thinking if nfv operator would need to get involved in image management business
17:18:07 <tbh> oh okay sridhar_ram
17:18:30 <tbh> sridhar_ram, I think we need to store only image details
17:18:46 <sridhar_ram> tbh: yes, just metadata...
17:19:04 <sridhar_ram> tbh: image itself will be glance
17:19:10 <sridhar_ram> *in glance
17:19:22 <tbh> sridhar_ram, yes, I will update the spec then
17:19:59 <sridhar_ram> tbh: sounds good.. again, given the timeline, my intention is not to complicate the implementation..
17:20:29 <sridhar_ram> tbh: do you think it will be reasonable to implement in this cycle ?
17:21:08 <sripriya> sridhar_ram: tbh: i had a question on image download using url for multisite case
17:21:34 <tbh> sridhar_ram, what is the deadline for this cycle 5 weeks?
17:21:45 <jokke_> sorry to jump in without proper background information but is there some specific metadata you cannot store directly in glance ref that image? What I mean is that glance has pretty extensive details of the image so is there reason for you to store anything else than the image ID in your own database?
17:21:56 <sripriya> will tacker download the images on remote sites during vnf creation, or will it be downloaded locally on tacker server and then upload to glance on the remote site?
17:22:22 <tbh> sripriya, no we directly provide the url to glance ..
17:22:30 <tbh> while creating the image
17:22:49 <sripriya> tbh: ok. everythign is offloaded on the remote glance client
17:23:00 <sridhar_ram> tbh: as part of the big tent guideline, we are going to use "release-with-intermediary" tag.. will will force us to do a release by Apr 1st, hence code completion is two weeks before that.. mid-March
17:24:17 <sripriya> so each site will have different image ids for the same image url and if tacker is going to store the metadata info in a seperate table, we will need to maintain per vim id
17:24:27 <sripriya> tbh: ^
17:24:36 <tbh> sripriya, but not yet tried
17:25:38 <sridhar_ram> jokke_: it could be just image ID itself, that much beyond that at this point (AFAIK). Agree it would make sense to store if there are "other" metadata .. we could leverage glance's capabilities..
17:26:08 <sridhar_ram> s/that much beyond/not much beyond/
17:26:25 <tbh> sripriya,  how can we get VIM id?
17:26:45 <jokke_> sridhar_ram: Just thinking as glance properties and tags are quite flexible, that would clean your database from tracking the metadata, just do query to glance with the image id to populate what you need from the image record
17:26:48 <sripriya> tbh: vim-id will be provided during vnf-create time
17:27:14 <sridhar_ram> jokke_: I was thinking about that ...
17:27:18 <tbh> sripriya, we thought of having some unique name to image across VIMs
17:27:59 <tbh> sripriya, so that we can enquire glance about that image existence
17:28:00 <sridhar_ram> jokke_: ... sort of a reverse reference
17:29:24 <jokke_> sridhar_ram: indeed ... only problem at the moment is that because we do not have image export from glance moving the images between different clouds will need you to populate that metadata to each glance (Hopefully we get to that once the image import rework is done in Newton)
17:29:26 <sridhar_ram> jokke_: the complexity would be code VNF::VDU id in the glance for a reverse look up..
17:29:51 <sripriya> tbh: yes, but you will still need to store the image name for each vim if not the image id int he table
17:30:00 <sripriya> * in the
17:30:14 <jokke_> please, do not use image name
17:30:34 <jokke_> that is not unique value, so just reference always by id
17:30:43 <jokke_> makes your life so much easier in the future
17:31:09 <tbh> jokke_, sripriya  okay, better we store the image ID per vim
17:31:15 <sridhar_ram> make sense
17:32:03 <sridhar_ram> tbh: that's what I was asking you in the spec.. what is the "lifecycle" of this "created_resource" dictionary in VNFD
17:32:23 <sridhar_ram> how does it expand and shrink as different VNFs gets created off it
17:32:52 <tbh> sridhar_ram, but it depends on VNFD
17:33:24 <tbh> sridhar_ram, if we create first VNF, we store image ids for that specific VNFD
17:33:56 <sridhar_ram> again, lets not complicate too much /  forwarrd design too much.. do something that is extendable in future
17:34:02 <tbh> sridhar_ram,  and if we delete the VNFD, we can remove the entry of image IDs for that particular VIM
17:34:12 <sridhar_ram> we need to make some assumption for this intiail foray into image handling !
17:34:42 <tbh> sure
17:34:55 <sridhar_ram> okay.. just make sure it has vim-id taken care..
17:35:54 <tbh> sridhar_ram, yes
17:36:07 <sridhar_ram> roughty per VNF instantiation -->{  { vim-id, { vdu1: glance uuid1, vdu2: glance uuid2, .. } }, { vim-id2, ... } }
17:36:30 <sridhar_ram> this dict will expand as VNFs gets created and
17:36:37 <sridhar_ram> shrink as VNFs get deleted
17:36:46 <tbh> VNFDs sridhar_ram
17:36:48 <sridhar_ram> sounds about right?
17:37:40 <sridhar_ram> tbh: but with parameterization different image URLs could be passed ?
17:38:05 <tbh> sridhar_ram, ah I missed this point
17:38:31 <tbh> sridhar_ram, understood your point
17:38:48 <sridhar_ram> sounds good...
17:39:00 <sridhar_ram> lets continue further in the gerrit review..
17:39:10 <sridhar_ram> jokke_: thanks for the heads up..!
17:39:23 <sridhar_ram> tbh: thanks for the update..
17:39:30 <sridhar_ram> lets move on to the next topic..
17:39:35 <sridhar_ram> #topic SFC updates
17:39:41 <sridhar_ram> s3wong: you there ?
17:40:03 <s3wong> sridhar_ram: here
17:40:24 <sridhar_ram> s3wong: hi!
17:41:07 <sridhar_ram> as you might have seen in the big-tent discussions...
17:41:30 <s3wong> so the biggest change is that Tacker is not interested in hooking up directly with any "low level" networking driver, including SDN controllers
17:42:01 <sridhar_ram> yep... we are reconsidering our attempts to introduce a ODL driver backend directly
17:42:29 <sridhar_ram> however there is enough interest in using Tacker with ODL-SFC ..
17:42:49 <sridhar_ram> .. so we should enable those folks.. who were the initial champions of SFC in Tacker
17:43:25 <sridhar_ram> our original plan was something like this...
17:43:40 <sridhar_ram> a) Tacker SFC plugin (Tim)
17:43:52 <sridhar_ram> b) Tacker SFC --> ODL/netvirtsfc driver backend (Tim)
17:44:01 <sridhar_ram> c) Tacker SFC --> neutron-sfc driver backend (Stephen)
17:44:05 <sridhar_ram> d) Neutron-sfc --> ODL/netvirtsfc driver backend (TBD)
17:44:33 <sridhar_ram> Based on big tent discussion, we shd avoid doing (b) instead help to get (d) done
17:44:40 <sridhar_ram> s3wong: sounds about right ?
17:44:57 <s3wong> sridhar_ram: absolutely
17:45:52 <sridhar_ram> s3wong: can you share your plans on (c) which we should accelerate to get it done by Mitaka
17:46:11 <s3wong> I can help bring folks onboard to networking-sfc also for whoever is interested to do ODL driver for networking-sfc
17:46:36 <s3wong> sridhar_ram: it certainly depends on (a)
17:47:17 <sridhar_ram> s3wong: trozet already has a WIP for (a), can we get started with that as the base for (c) ?
17:47:43 <s3wong> sridhar_ram: for the driver itself, we need (a) getting the Neutron ports from VNF once it is deployed
17:48:18 <s3wong> and (b) mapping high-level service types to VNFs
17:48:35 <sridhar_ram> s3wong: do you mind starting a spec for neutron-sfc driver backend, so that you can define your expectation of that interface ?
17:48:49 <s3wong> for phase 1, we can push back on the symmetrical stuff
17:49:45 <sridhar_ram> s3wong: why ? I though the driver can create two neutron-sfc chains to handle symmetry ?
17:49:51 <s3wong> sridhar_ram: sure --- sorry, was thinking of working on it over the long weekend, but day job also has demand over this long weekend
17:50:43 <sridhar_ram> I know it will cut close.. please try your best!
17:51:07 <s3wong> sridhar_ram: conceptually it is; there are things to worry about (as we talked about during the mid cycle)
17:51:23 <s3wong> sridhar_ram: like reverse flow classifier
17:51:38 <sridhar_ram> s3wong: okay, it sure is your call.. we can skip it for the initial release
17:52:05 <s3wong> sridhar_ram: sure
17:52:31 <sridhar_ram> I'll send an ML email to recap our decision so the we can communicate to TC and other interested parties..
17:52:44 <sridhar_ram> s3wong: anything else from your side ?
17:53:09 <s3wong> sridhar_ram: that's it. I think it is a good plan
17:53:31 <sridhar_ram> s3wong: sounds good.. we need to move to implementation soon!
17:53:42 <sridhar_ram> #topic VNF Scaling
17:54:18 <sridhar_ram> of late we have been getting some steady request to introduce this feature soon in Tacker
17:55:22 <brucet> How is scaling reflecting in Tosca NFV??
17:55:27 <brucet> reflected
17:56:00 <sridhar_ram> we have been debating between introducing Manual Scaling vs simple Auto Scaling .. which do you think will make sense to introduce first ?
17:56:43 <sridhar_ram> brucet: TOSCA is introducing some constructs in Simple YAML profile for event-trigger-action sequence .. which will map nicely for VNF Scaling definitions
17:57:02 <prashantD> sridhar_ram : we want something for Mitaka ?
17:57:17 <sripriya> sridhar_ram: is this wrt scale out/scale in ?
17:57:38 <sridhar_ram> prashantD: I'm assessing if something simple can be done for Mitaka
17:57:48 <sridhar_ram> sripriya: yep
17:58:00 <brucet> So can we map Simple YAML definitions to Heat autoscaling?
17:58:23 <brucet> If so, then this should be easy.
17:58:54 <sridhar_ram> brucet: yeah, that's my hope
17:59:09 <brucet> You want me to look into this?
17:59:21 <sridhar_ram> brucet: sure...!
17:59:25 <brucet> OK
17:59:41 <sridhar_ram> prashantD: meanwhile you where looking into manual scaling ..
17:59:48 <sridhar_ram> please continue that research
17:59:53 <sridhar_ram> we are out of time for today!
18:00:05 <prashantD> sridhar_ram : yes, did you get a chance to look at the diffs I sent you?
18:00:23 <sridhar_ram> prashantD: can you please post a WIP to gerrit !
18:00:33 <sridhar_ram> #topic Open Discussion
18:00:41 <sridhar_ram> please remember to vote for the talks!
18:00:44 <sridhar_ram> #endmeeting