17:00:38 <sridhar_ram> #startmeeting tacker
17:00:38 <openstack> Meeting started Tue Nov 24 17:00:38 2015 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:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:43 <openstack> The meeting name has been set to 'tacker'
17:00:49 <sridhar_ram> #topic Roll Call
17:00:59 <sridhar_ram> who is here for tacker mtg ?
17:01:00 <sripriya> o/
17:01:15 <sridhar_ram> #chair sripriya
17:01:16 <openstack> Current chairs: sridhar_ram sripriya
17:01:26 <natarajk> hi
17:01:37 <sridhar_ram> sripriya: natarajk: hi!
17:01:45 <vishwanathj> 0/
17:01:50 <sridhar_ram> lets give a min or two...
17:01:54 <sridhar_ram> vishwanathj: hi there
17:02:10 <vishwanathj> hi
17:02:17 <prashantD> hi sridhar, I am here though I may step away
17:02:54 <sridhar_ram> prashantD: Hi there, good to see you!
17:04:09 <sridhar_ram> lets get started...
17:04:22 <sridhar_ram> #topic Agenda
17:04:40 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Nov_23.2C_2015
17:04:56 <s3wong> hello
17:05:04 <brucet> hello
17:05:05 <sridhar_ram> anything beyond what listed to discuss ?
17:05:13 <sridhar_ram> s3wong: brucet: hi there
17:05:43 <sridhar_ram> lets move on...
17:05:55 <sridhar_ram> #topic Mitaka Blueprin / RFE updates
17:06:05 <brucet> I have a question I would like to ask
17:06:11 <brucet> Can be later
17:06:16 <sridhar_ram> lets just go around to see where we are..
17:06:19 <brucet> K
17:06:23 <sridhar_ram> brucet: sure thing, we will get to it...
17:06:49 <sridhar_ram> bobh: is off today... so updates on TOSCA parser this week
17:06:59 <sridhar_ram> *no updates
17:07:11 <brucet> My question was on Tosca parser
17:07:28 <sridhar_ram> brucet: ah...
17:07:55 <sridhar_ram> brucet: what is the question ? so that we can record here.. I can answer if I can
17:07:57 <brucet> Is anyone drawing up an object mapping from NFV Tosca to Heat?
17:08:41 <sridhar_ram> brucet: that is the cruz of the effort bobh is marching on...
17:09:05 <brucet> OK. Is there anything documented yet or no?
17:09:31 <sridhar_ram> brucet: we are implementation tosca-nfv profile and tosca-parser library is being enhanced to map "relevant" objects to Heat
17:09:54 <sridhar_ram> brucet: not yet, a blueprint (actually more than 1) will come from bobh
17:10:07 <brucet> OK
17:10:39 <sridhar_ram> brucet: keep in mind, not all objects will map to Heat.. some will be absorbed by Tacker
17:10:48 <brucet> Hmmmmm
17:11:18 <brucet> I would like to see which ones don't map
17:11:55 <sridhar_ram> brucet: the features we have in tacker like mgmt driver, monitoring and such..
17:12:18 <sridhar_ram> brucet: we have discuss further once we have the spec(s) out
17:13:17 <brucet> OK
17:13:18 * sridhar_ram forgot his dyslexic med today
17:13:36 <sridhar_ram> lets move on..
17:14:01 <sridhar_ram> sripriya: do you mind share where you are w.r.t multi-vim ?
17:14:13 <sripriya> sridhar_ram: sure
17:14:58 <sripriya> sridhar_ram: i posted an initial WIP for multi-vim at https://review.openstack.org/#/c/249085/3/specs/mitaka/multi-vim-feature.rst. This is a very initial draft i put based on discussions we had during the design summit
17:15:21 <sridhar_ram> sripriya: great..!
17:15:26 <vishwanathj> +1
17:15:44 <natarajk> Nice
17:15:56 <sridhar_ram> sripriya: looks like a good initial version...
17:15:58 <sripriya> sridhar_Ram: it still needs to go through many iterations. but i would like to get folks thoughts on if i'm headed in the right direction or if i need to change any of the points i have put in the spec
17:16:21 <sridhar_ram> sripriya: any *major* sticking points at this moment ?
17:16:26 <sripriya> thanks vishwanathj, natarajk and sridhar_ram
17:17:29 <sripriya> sridhar_ram: i guess the high-level tasks have been captured in the spec but still some thoughts on multi-vim assumptions and attributes for the VIM REST-API are few things i would like to get more feedback
17:17:43 <sridhar_ram> sripriya: sounds good
17:18:15 <sridhar_ram> tacker team - please review this multi-vim spec, it will be one of the major features in Mitaka!
17:18:15 <sripriya> sridhar_ram: at the moment, i could ony think of the basic attributes such as vim_name, description and ip_addr but i may be missing other attributes
17:18:39 <sridhar_ram> sripriya: no worries, we iterate on the spec
17:18:41 <vishwanathj> sridhar_ram, sure will review the spec
17:18:46 <sripriya> thanks!
17:19:01 <sridhar_ram> lets move on...
17:19:20 <brucet> Where should comments be submitted? To mail alias?
17:19:34 <sripriya> brucet: you can post the comments on the spec itself
17:19:38 <brucet> OK
17:20:12 <vishwanathj> brucet, add your self as a reviewer to the patch set....that way you will be notified where there are new patchsets uploaded
17:20:15 <sridhar_ram> brucet: login to gerrit using you are gerrit id and provide "inline" comments directly on the text..
17:20:32 <brucet> GOT IT
17:20:39 <sridhar_ram> moving on..
17:20:53 <sridhar_ram> tbh: I know you picked up couple of RFEs..
17:21:02 <sridhar_ram> tbh: can you share your updates ?
17:21:35 <tbh> sridhar_ram, yeah, I need some inputs from  the implementation point of view.
17:21:46 <sridhar_ram> tbh: sure, lets discuss
17:22:14 <tbh> and I have mentioned some of the details https://bugs.launchpad.net/tacker/+bug/1516193
17:22:14 <openstack> Launchpad bug 1516193 in tacker "Automatic Flavor Creation based on VNFD Template" [Medium,New] - Assigned to bharaththiruveedula (bharath-ves)
17:22:40 <tbh> sridhar_ram, first thing is, we have  host properties at VDU level
17:23:29 <tbh> sridhar_ram, so we can have multiple flavors for same VNF
17:23:35 <sridhar_ram> tbh: yes, that means - potentially - we need a list of flavors
17:24:13 <tbh> sridhar_ram, and the same case for network/image creation
17:24:52 <sridhar_ram> tbh: hmm..
17:25:13 <sridhar_ram> tbh: yes, I believe they all expand into a list of per VDU objects...
17:25:49 <tbh> sridhar_ram, yes and storage of those values in db
17:26:01 <sridhar_ram> tbh: an impl question is .. shd we do all this during VNFD onboard time .. or differ to the first VNF creation (using a VNFD)
17:26:34 <sridhar_ram> VNFD on-board, today is a simple db operation..
17:26:42 <tbh> sridhar_ram, and I thought of doing at onboard of VNF
17:26:58 <sridhar_ram> if we introduce these object creation we need to introduce pending_ states for VNFD as well
17:27:35 <tbh> sridhar_ram, correct
17:27:54 <vishwanathj> sridhar_ram, I like your approach of creating flavor at first VNF creation so that VNFD onboarding can continue to be a simple process
17:28:09 <sridhar_ram> tbh: this is more a thinking-out-aloud .. what if we do basic input validation during VNFD onboard, but differ some of the flavor / network creation to first VNF creation
17:29:11 <sridhar_ram> vishwanathj: thanks, lets see if that holds for other scenario
17:29:27 <tbh> sridhar_ram, you mean flavor details changed by user?
17:29:49 <sridhar_ram> for e.g. for auto-image creation (using a url download), I somehow believe we need to have it done during VNFD creation itself
17:30:30 <sridhar_ram> tbh: these flavors are created but Tacker and user / operator *should not* change it underneath
17:30:37 <sridhar_ram> s/but/by/
17:31:23 <tbh> sridhar_ram, yes, so I thought there is no need to have validation at vnf creation
17:32:22 <sridhar_ram> tbh: VNFD template level validation could happen during VNFD onboarding..
17:32:59 <sridhar_ram> tbh: sripriya: what is your thoughts on making vnfd a bit more "stateful" ?
17:33:16 <vishwanathj> FYI:Unlike glance images where you can set it to be protected, flavors do not have a protect option
17:34:30 <sridhar_ram> vishwanathj: then the only option is to scare the user away by naming the flavor something like "DONOT_EVER_THINK_TO_REMOVE_tacker_vndx-vdu1-s3q343"
17:35:29 <tbh> sridhar_ram, and if we donot want to make vnfd stateful ...
17:36:20 <tbh> we have to make sure that first vnf creation is done and no need to create flavor the second time
17:36:41 <vishwanathj> I just deleted a flavor that was associated with an existing instance and was surprised that it let me delete the flavor..wow
17:36:45 <sridhar_ram> tbh: hmm... that seems just differing the complexity to another point-in-time
17:36:57 <sridhar_ram> vishwanathj: interesting data pint
17:37:01 <sridhar_ram> *pint
17:37:08 <sridhar_ram> **point
17:37:43 * sridhar_ram going to give up correcting my spelling errors.. I think I've a friendly audience here ;-)
17:38:00 <sripriya> sridhar_ram: deferring the flavor creation to VNF creation time and keeping the VNFD create simpler  as current behavior looks ok for me, but i need to look into that RFE in more detail to comment on this
17:38:13 <sridhar_ram> sripriya: np..
17:38:39 <vishwanathj> need to investigate if heat or nova allows creating a  transient flavor that could be helpful during VNF creation
17:39:02 <vishwanathj> is it a requirement that the flavor persist?
17:39:09 <sridhar_ram> tbh: I think, for now, we can keep the original impl thought of having these calls off VNFD create
17:39:26 <sridhar_ram> vishwanathj: yes, flavor shd persist
17:40:15 <sridhar_ram> tbh: I guess you are already on the right track, IMO
17:40:22 <vishwanathj> the reason I ask is that the flavor info will always persist in the VNFD and can be resurrected anytime
17:40:54 <sridhar_ram> vishwanathj: yes, that make sense... reduces the complexity in vnf creation time.
17:41:01 <sridhar_ram> looks it is zero sum game
17:41:03 <tbh> sridhar_ram, okay, we need to have state for vnfd then, am I correct
17:41:09 <sridhar_ram> tbh: yes
17:41:43 <sridhar_ram> tbh: another suggestion, we need to have these object creations off an infra driver
17:41:57 <sridhar_ram> tbh: .. and directly on the plugin itself
17:42:31 <sridhar_ram> tbh: perhaps we can take it offline or in the code review when ready
17:42:36 <tbh> sridhar_ram, but I think the vnfd directly calls to vm_db.py
17:43:05 <sridhar_ram> tbh: I think we need to break that chain.. now that it will have lot more "client" calls
17:43:09 <sripriya> tbh: sridhar_ram: if the flavor creation is unsucessful during VNFD create, it errors out. with the current behavior, tacker does not complain on the VNFD template istefl until it id actually deployed
17:43:15 <tbh> sridhar_ram, I already have version for auto image creation, based on the inputs changing the impl
17:43:24 <sripriya> itself*
17:43:54 <sridhar_ram> sripriya: yes, now VNFD creation could error out - possibly for multiple reasons..
17:44:18 <tbh> sridhar_ram,  sripriya  and we cannot deploy the vnf with errored vnfd
17:44:21 <sridhar_ram> sripriya: ... invalid tosca-syntax, unsupported flavor combination, invalud image url
17:44:29 <sridhar_ram> tbh: exactly!
17:45:16 <sripriya> tbh: that is the current behavior where we dont complain until we deploy VNF, so we will need a validator for the template
17:46:02 <sridhar_ram> sripriya: that will change over Mitaka with tbh and bobh code changes
17:46:19 <tbh> and I have a doubt, why do we need to store errored vnfd in db if we cannot update it?
17:46:23 <sripriya> sridhar_ram: sure
17:47:32 <sridhar_ram> tbh: I think it depends if vnfd create call is sync or async
17:47:39 <vishwanathj> tossing another idea to see if it would make sense...match the inputs from VNFD to the closest matching flavor already available .... maybe it does not make sense since we want to automatically create flavors
17:47:40 <brucet> Got a question on validating Tosca template
17:47:48 <sridhar_ram> tbh: if it is going to be sync, we an error out and not store in db
17:48:38 <tbh> sridhar_ram, got it
17:48:46 <sridhar_ram> vishwanathj: we briefly discussed that in the last call. As bobh put it - flavor is "cheap" in openstack. we don't need to go through the pain of matching
17:48:59 <vishwanathj> ok
17:49:16 * sridhar_ram close to 10 min mark..
17:49:43 <sridhar_ram> tbh: so you are taking up all the auto create RFEs ? auto-flavor/network/glance ?
17:49:55 <tbh> sridhar_ram, yes
17:50:01 <sridhar_ram> tbh: great, thanks!
17:50:20 <sridhar_ram> tbh: anything else ?
17:50:31 <sripriya> tbh: sridhar_ram: that will be a lot of work for the RFE
17:51:10 <sridhar_ram> sripriya: agree. should we consolidate these three into a blueprint ?
17:51:23 <sripriya> sridhar_ram: wondering the same
17:51:42 <tbh> sridhar_ram, need to discuss about db migration, will take it offline
17:51:46 <sripriya> sridhar_ram: if we are heading in making the VNFD more stateful
17:52:00 <sridhar_ram> tbh: I think it is a good idea..tbh what do you think of blueprint idea ?
17:52:11 <sripriya> sridhar_ram: that will require some major changes in current framework
17:52:12 <sridhar_ram> tbh: if it is not too much overhead, we shd consider it
17:52:57 <sripriya> tbh: i can help on the spec if you need some thoughts on the framework
17:53:19 <sridhar_ram> tbh: ack, for db migration .. lets sync up in the #tacker channel
17:53:51 <tbh> sripriya, sridhar_ram sure but I need to have more data in framework changes
17:54:07 <sridhar_ram> tbh: sounds good...
17:54:09 <sripriya> tbh: sure
17:54:12 <tbh> sridhar_ram, sridhar_ram  and for clients created a seperate patch for that
17:54:45 <sridhar_ram> tbh: hmm...there shdn't be any client patch for this auto-creations, am I missing something ?
17:55:49 <sridhar_ram> folks - we are almost out of time...
17:55:51 <tbh> sridhar_ram, otherwise we need to invoke individual clients in the plugin itself
17:56:03 <sridhar_ram> lets wrap up ...
17:56:30 <sridhar_ram> tbh: lets continue the discussion in the blueprint.. I hope you've enough guidance to proceed
17:56:38 <sripriya> tbh: will review that patchset this week, sridhar_ram: tbh: is referring to https://review.openstack.org/#/c/248536/ i guess?
17:56:54 <tbh> sridhar_ram, sure
17:56:56 <tbh> sripriya,  yes
17:57:11 <sridhar_ram> alright ... lets move on
17:57:20 <santoshkumark> sridhar_ram, wanted to bringup the gate jobs some times failing like http://logs.openstack.org/38/246738/6/check/gate-tacker-dsvm-functional/634bd5c/console.html
17:57:20 <santoshkumark> Same testcases passing in localsetup..The issue is intermittent.
17:57:43 <sridhar_ram> prashantD: hi there, how is your VNF scaling work coming ? any quick word ?
17:57:47 <santoshkumark> we can discuss these offline..
17:58:34 <sridhar_ram> santoshkumark: sure
17:58:45 <sridhar_ram> #topic Open Discussion
17:59:42 <sridhar_ram> Folks - we have lot more RFEs (these are mini-blueprints) open for Tacker. See https://bugs.launchpad.net/tacker/+bugs?field.tag=mitaka-rfe
18:00:13 <sridhar_ram> Anyone new to Tacker and want to join / contribute .. this is a good way, to pick up a RFE
18:00:27 <sridhar_ram> times up .. talk to you all next week!
18:00:37 <sridhar_ram> bye folks
18:00:40 <sridhar_ram> #endmeeting