05:30:07 <sridhar_ram> #startmeeting tacker
05:30:08 <openstack> Meeting started Wed Dec 21 05:30:07 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:11 <openstack> The meeting name has been set to 'tacker'
05:30:17 <sridhar_ram> #topic Roll Call
05:30:24 <tbh> o/
05:30:25 <sridhar_ram> who is here for tacker meeting?
05:30:32 <xuhaiwei_> o/
05:30:52 <janki> o/
05:31:03 <dkushwaha> o/
05:31:09 <gongysh> hi
05:31:24 <sripriya> o/
05:31:25 <sridhar_ram> howdy all!
05:31:41 <KanagarajM> hi
05:31:48 <sridhar_ram> #chair tbh sripriya gongysh KanagarajM
05:31:49 <openstack> Current chairs: KanagarajM gongysh sridhar_ram sripriya tbh
05:31:59 <sridhar_ram> lets start..
05:32:06 <sridhar_ram> #topic Agenda
05:32:16 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_21st.2C_2016
05:32:22 <sridhar_ram> light agenda ...!
05:32:35 <sridhar_ram> anything else beyond this ?
05:33:08 <sridhar_ram> #topic Annoucements
05:33:40 <sridhar_ram> I'm thinking to cancel next week's meeting due to holiday week
05:33:58 <sridhar_ram> anyone have major issues ?
05:34:10 <gongysh> sridhar_ram, no, not yet.
05:34:31 <sridhar_ram> okay... will cancel
05:34:48 <sripriya> +1 to cancel next week's meeting, since many will be on holidays
05:35:04 <sridhar_ram> #info No Tacker Weekly meeting on Dec 28th due to holiday week
05:35:30 <sridhar_ram> however please continue to post patchsets and do code reviews..
05:36:07 <sridhar_ram> We have just about 4 weeks to do client release
05:36:27 <sridhar_ram> so any blueprints with API changes .. please push your client changes first
05:36:47 <sridhar_ram> #topic Ocata Blueprint Status
05:36:55 <sridhar_ram> #topic NSD update
05:37:05 <sridhar_ram> tbh: dkushwaha: can you guys give an update ?
05:37:31 <dkushwaha> sridhar_ram, tbh already push some patches.
05:37:47 <dkushwaha> sridhar_ram, Currently working in mistral part
05:38:02 <tbh> sridhar_ram, We have outer part like api, db and client changes ready and dkushwaha is working on mistral workflow generator part
05:38:08 <dkushwaha> sridhar_ram, I needed some investigation in mistral side.
05:38:41 <sridhar_ram> tbh: dkushwaha: wonderful.. i like the way you both sequencing your work..
05:39:21 <dkushwaha> sridhar_ram, I have a question, regarding vnf create, should we call mistral for individual vnfs or call mistrall for the set of vnfs? kindly suggest
05:40:08 <sridhar_ram> dkushwaha: i'd lean todays a single mistral workflow for all VNF creations ..
05:40:18 <sridhar_ram> s/todays/towards/
05:40:38 <gongysh> dkushwaha, is the mistral a must for NSD to work?
05:41:06 <sripriya> gongysh: please refer to the NSD spec for the mistral requirement
05:41:24 <sridhar_ram> gongysh: we have taken a conscious decision to embrace a workflow engine
05:41:25 <dkushwaha> gongysh, yes. We are going through mistral workflow
05:42:17 <sridhar_ram> gongysh: this is to future proof and leverage the rich mistral workflows out there in the community
05:42:48 <gongysh> ok
05:43:07 <sridhar_ram> gongysh: to do simple things like send an email / alert after a respawn or auto-scale
05:43:13 <dkushwaha> sridhar_ram, make sence to use single workflow. Thanks. But I am not much sure if mistral do in parallel
05:43:58 <sridhar_ram> dkushwaha: what you mean by "in parallel"
05:43:58 <KanagarajM> +1 on mistral role with tacker.
05:44:07 <dkushwaha> sridhar_ram, I had asked mistral guy, and waiting for response
05:45:04 <sridhar_ram> dkushwaha: it will be ideal if a mistral dev joins us as a co-contributor
05:45:16 <sripriya> dkushwaha: isn't that the default behavior unless you provide a dependency between the steps?
05:45:35 <dkushwaha> sridhar_ram, mistral workflow execute next task after completing of current one IMO
05:47:07 <sridhar_ram> dkushwaha: this can work both ways, parallel should be the default.. but there are times you want the VNFs to come up in specific order .. a dependency will be useful
05:47:52 <sridhar_ram> sripriya: did any mistral devs stop by in the summit to help?
05:48:02 <sripriya> sridhar_ram: looks it is sequential as per the docs http://docs.openstack.org/developer/mistral/terminology/workflows.html#direct-workflow
05:48:12 <sridhar_ram> i thought that would speed up / de-risk this BP
05:49:22 <sridhar_ram> KanagarajM: curious about HOT template, how does Heat handles multiple OS::Node::Server resources ? do they get created in parallel or sequential ?
05:49:33 <dkushwaha> sridhar_ram, I know mistral core member personally, and will ask him.
05:49:48 <sridhar_ram> dkushwaha: sounds good!
05:50:00 <KanagarajM> sridhar_ram, heat would create an dependency graph and travse from leaf nodes
05:50:20 <KanagarajM> sridhar_ram, and all indepdent leaf nodes would executed in parallel
05:50:44 <sridhar_ram> KanagarajM: I see.. that's good to know. thanks!
05:50:57 <sridhar_ram> dkushwaha: tbh: thanks for the update..
05:51:12 <sridhar_ram> one last on NSD, we need some volunteers (both core and non-core) to review NSD patchset ..
05:51:14 <KanagarajM> sridhar_ram, i felt mistral gives that graph control to the user, while heat manages by itself
05:51:17 <sridhar_ram> anyone ?
05:51:32 <sridhar_ram> KanagarajM: that was my thought too
05:51:52 <sridhar_ram> KanagarajM: .. i meant, user has control over the sequence
05:51:57 <KanagarajM> sridhar_ram, yes
05:52:07 <gongysh> KanagarajM, workflow is an engine. user can do ordering.
05:52:19 <gongysh> heat do it in its own way.
05:52:26 <janki> sridhar_ram, I will try to review over the weekend
05:52:36 <sridhar_ram> janki: thanks!
05:52:40 <KanagarajM> gongysh, yes !
05:53:14 <sridhar_ram> KanagarajM: gongysh: can one of you sign up to review NSD patchsets ?
05:53:14 <tbh> thanks janki!
05:53:27 <gongysh> sridhar_ram, let me cover the NSD patchsets
05:53:30 <janki> sridhar_ram, tbh wc :)
05:53:41 <KanagarajM> sridhar_ram, sure.
05:53:59 <sridhar_ram> KanagarajM: gongysh: thanks!
05:54:08 <sridhar_ram> anything else on NSD ?
05:54:33 <sridhar_ram> dkushwaha: tbh: are you planning to add corresponding tacker-horizon changes as well ?
05:55:03 <tbh> sridhar_ram, yup changes are made locally, but facing some issues with existing repo
05:55:15 <sridhar_ram> tbh: okay, thanks
05:55:24 <tbh> sridhar_ram, so will test in different dev env and push those changes too
05:55:32 <sridhar_ram> tbh: sounds good
05:55:38 <diga> o/
05:55:41 <diga> sorry got late
05:55:44 <sridhar_ram> #topic API Framework
05:55:52 <diga> Hi
05:55:53 <sridhar_ram> diga: timing couldn't be better
05:55:57 <sridhar_ram> :)
05:55:58 <diga> :)
05:56:02 <diga> yep
05:56:13 <sridhar_ram> #link https://review.openstack.org/#/c/368511/
05:56:22 <sridhar_ram> diga: please give an update to the team
05:56:30 <diga> yes
05:56:39 <diga> I had discussion with infra team
05:57:08 <diga> ironic team is facing some problem working on pecan + wsme
05:57:42 <diga> pecan& wsme is not stable support
05:58:06 <diga> infra team jroll strongly oppose to go with pecan way
05:58:37 <diga> they are suggesting either go with flask or falcon for future purpose
05:59:43 <diga> so I have gone through falcon & flask, I am thinking to go with falcon as it is faster as compare to flask & has strong communuty support & provide good security features
05:59:53 <sripriya> diga: what exactly do you mean by pecan and wsme is not stable
06:01:14 <diga> sripriya: Actually wsme doesn't have stable support which we are going to use for validation
06:01:55 <diga> sripriya: pecan is ok, but infra team is saying we should not go with pecan way as they are facing lot of issues in ironic now
06:02:03 <sripriya> diga: do you mean the package is not maintained consistently with web frameworks?
06:02:04 <sridhar_ram> sripriya: biggest problem, according to jroll, wsme is no longer maintained and difficult to get support
06:02:11 <diga> sridhar_ram: yep
06:02:23 <sripriya> sridhar_ram: diga: ok
06:02:41 <KanagarajM> diga, is falcon already part of global-requirements ?
06:02:53 <sridhar_ram> Pecan has a different problem of sorts as it is seen has too heavy weight.. pulling in lots of dependencies .. bigger attach surface
06:03:08 <sripriya> sridhar_ram: i wonder about the other projects that have already integrated pecan framework such as neutron etc
06:03:16 <gongysh> File	Type	Py Version	Uploaded on	Size
06:03:17 <gongysh> WSME-0.8.0-py2-none-any.whl (md5)	Python Wheel	py2	2015-08-25
06:03:18 <diga> sripriya: sridhar_ram :  yes, infra team is suggesting that means it is already adopted by the community
06:03:24 <diga> KanagarajM: yes
06:03:41 <KanagarajM> diga, ok. thanks.
06:04:03 <sridhar_ram> sripriya: i'm also interested in seeing the list of openstack projects that switched to Falcon
06:04:21 <diga> I think we should go with falcon, will update the patch
06:04:37 <gongysh> falcon-1.1.0-py2.py3-none-any.whl (md5, pgp)	Python Wheel	py2.py3	2016-10-27	122KB
06:04:52 <gongysh> it seems wsme is not updated for a long time.
06:05:01 <sridhar_ram> my general understanding is Pecan proliferated due to cut & paste off Ironic .. but some sense has prevailed on better light weight alternatives
06:05:07 <gongysh> falcon is in active developing.
06:05:10 <diga> sridhar_ram: sripriya : sure, will send you details on how many projects are now using falcon
06:05:18 <sridhar_ram> diga: thanks
06:05:25 <sridhar_ram> See think as well https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation
06:05:31 <sripriya> diga: here is a good link explaining some of the performance related metric comparison between pecan and falcon
06:05:36 <sridhar_ram> again, giving an edge to Falcon
06:05:51 <diga> sripriya: yeah, gone through it
06:05:51 <sripriya> sridhar_ram: i was just pasting that link :-) thanks
06:06:01 <sridhar_ram> sripriya: :)
06:06:26 <sridhar_ram> diga: is it just Falson or it is going to be Falcon + Flask ?
06:06:44 <sridhar_ram> i've seen cases in my earlier work using CherryPy + Flask
06:06:44 <diga> sridhar_ram: it will be just falcon
06:06:50 <sridhar_ram> diga: okay
06:07:17 <sripriya> KanagarajM: here is the global requirements https://github.com/openstack/requirements/blob/master/global-requirements.txt#L54
06:07:26 <diga> sridhar_ram: falcon is light weight, has less dependancies also
06:08:00 <sridhar_ram> diga: team: I also found this thread with subject "let's just use flask" (by Jay Pipes)...
06:08:06 <s3wong> sorry, was just reminded that we have a meeting today...
06:08:09 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/097808.html
06:08:18 <diga> sripriya: sridhar_ram : will update the PS today by considering all these things
06:08:21 <sridhar_ram> I haven't gone through it full
06:08:26 <sridhar_ram> *fully
06:08:28 <diga> sridhar_ram: okay
06:08:35 <diga> will go through it
06:08:41 <KanagarajM> sridhar_ram, thanks
06:08:50 <sridhar_ram> diga: thanks.. !
06:08:54 <sridhar_ram> KanagarajM: urw!
06:09:02 <sridhar_ram> s3wong: hi there!
06:09:06 <diga> sridhar_ram: welcome!
06:09:38 <KanagarajM> sridhar_ram, :)
06:09:39 <sridhar_ram> diga: I guess the branch name will be "falcon-api-framework"
06:09:43 <KanagarajM> sripriya, thanks.
06:09:45 <sripriya> sridhar_ram: thanks for the link
06:09:51 <KanagarajM> i see the bench marking https://falconframework.org/#Metrics
06:10:01 <diga> sridhar_ram: yeah
06:10:11 <sridhar_ram> another question..
06:11:03 <sridhar_ram> are we going to go with a v2 version of the API with new Falcon and leave the current wsgi serving v1 ?
06:11:12 <diga> sridhar_ram: will propose "falcon-api-framework" now but will update the PS today, & need to finalize it by End of this week
06:11:38 <diga> sridhar_ram: I suggest, we should go with v2 because its complete API refactoring
06:11:50 <sridhar_ram> diga: +1
06:11:58 <gongysh> sridhar_ram, I think we should bump up the version.
06:12:03 <sridhar_ram> others: thoughts ? this is a big decision
06:12:03 <dkushwaha> diga, +1
06:12:11 <gongysh> but do we need to do back compatible?
06:12:33 <sripriya> sridhar_ram: are we changing the way the API interactions are done by users?
06:12:58 <sripriya> sridhar_ram: the purpose of introducing the framework is to have minimal impact on the API itself right?
06:12:58 <KanagarajM> diga, sridhar_ram does falcon not conflict with existing framework , if we plan to use falcon in addition ?
06:13:16 <diga> sripriya: No, endpoint & user interaction will remain same
06:13:28 <sripriya> diga: then why should we bump the version?
06:13:59 <sridhar_ram> that is an unknown to me, will be happy if the API stays the same after the Falcon switchover.. but i'm skeptical
06:14:00 <diga> sripriya: we may need to do some changes in the user interaction, we may not know
06:14:20 <KanagarajM> sripriya, yes, we should not change the version for changing the api framework.
06:14:21 <sripriya> sridhar_ram: diga: IMO it should not change
06:14:41 <dkushwaha> sridhar_ram, i will suggest to have new api version with standard return codes
06:14:43 <diga> I am going through falcon now, will put my understanding in the PS so that we can decide on that
06:14:54 <gongysh> diga, it we don't change much, maybe we just change it into 1.1 to improve some response status code.
06:14:57 <s3wong> yeah, normally we change endpoint (v2/...) if we bump version
06:15:05 <sridhar_ram> again, i agree in principal.. but the devil is in the detail that only when diga gets in we will know
06:15:26 <diga> gongysh: yes, better approach
06:16:09 <sridhar_ram> fair enough, lets diga do his homework.. but the preference is no version bump, may be a minor bump to 1.1 and the goal is to switch over
06:16:18 <sripriya> sridhar_ram: moving to a new framework should not change the way the user interacts with the API, even if it does, it is responsibility of the framework to handle such usecases
06:16:22 <sripriya> sridhar_ram: +1
06:16:27 <diga> sure
06:16:44 <diga> sripriya: yes
06:16:50 <sridhar_ram> sripriya: that is a noble goal ...
06:16:54 <KanagarajM> sripriya, +1 yes  !
06:17:00 <sridhar_ram> lets stick to it
06:17:06 <diga> +1
06:17:10 <s3wong> +1
06:17:24 <KanagarajM> diga, does falcon support swagger ?
06:17:42 <diga> KanagarajM: Not sure, I will have to check
06:17:59 <sridhar_ram> KanagarajM: https://pypi.python.org/pypi/falcon-swagger
06:18:11 <KanagarajM> diga, i think OpenStack community is thinking of swagger integration in API. so it would be better choice if falcon gives swagger support.
06:18:19 <diga> sridhar_ram: :) thanks
06:18:31 <tbh> KanagarajM, no direct support in falcon, but can use falcon-swagger package for that
06:18:45 <KanagarajM> sridhar_ram, tbh thx :)
06:18:53 <KanagarajM> sounds better !
06:19:11 <gongysh> I am looking forward to new API and swagger.
06:19:20 <sridhar_ram> +1
06:19:26 <diga> gongysh: +1 Sure
06:19:35 <sridhar_ram> time to ditch more archaic neutron code ;-)
06:19:49 <diga> :)
06:19:52 <sridhar_ram> no offense to neutron
06:20:38 <sridhar_ram> diga: as you get more clarity, I'd also need to estimate the effort / rough date of completion for release planning purposes
06:20:55 <diga> sridhar_ram: Sure
06:21:07 <diga> sridhar_ram: I will update PS today EOD, we can discuss in the evening
06:21:17 <sridhar_ram> diga: sounds good
06:21:24 <sridhar_ram> anything else on this subject ?
06:21:34 <diga> that's all from my side
06:21:47 <sridhar_ram> diga: thanks for taking this forward !!
06:21:48 <gongysh> we also need a configure opt to switch between wsgi and falcon.
06:22:11 <sridhar_ram> gongysh: i was thinking the same, a safety backup switch
06:22:47 <gongysh> I don't think we need an independent branch for this feature.
06:22:58 <gongysh> let's us do it in the master branch.
06:23:56 <sridhar_ram> gongysh: no, this is a high risk.. we are not sure about the release window when we can get this in and also most project using a separate feature branch for api-framework changes
06:24:38 <diga_> sorry got disconnected
06:24:38 <gongysh> sridhar_ram, our task is easier than neutron.
06:25:14 <sridhar_ram> gongysh: well.. I'd be happier if this turns out into an easy task
06:25:51 <sridhar_ram> but let's take a conservative approach
06:26:12 * sridhar_ram notes just few mins left...
06:26:20 <sridhar_ram> #topic Open Discussion
06:26:49 <xuhaiwei_> sridhar_ram, do we need to discuss the senlin integration part any more?
06:26:50 <sridhar_ram> KanagarajM: quick question on the TOSCA auto-scaling fix for nested templates
06:27:13 <sridhar_ram> KanagarajM: is the fix for specific VDU target going to merge soon ?
06:27:29 <KanagarajM> sridhar_ram, i am following up with sehdev and once its merged, i would start to migrate the current code to use
06:27:55 <sridhar_ram> xuhaiwei_: did you had a chance to update the couple of questions we have in the meeting .. manual scaling and one more that i couldn't remember
06:28:03 <KanagarajM> sridhar_ram, hoping things shuld start by next week !
06:28:07 <gongysh> KanagarajM, what is sehdev doing?
06:28:16 <sridhar_ram> KanagarajM: thanks
06:28:24 <KanagarajM> gongysh, enabling the nested template in ht
06:28:42 <xuhaiwei_> sridhar_ram: In fact, I have already updated the spec last week https://review.openstack.org/#/c/352943/
06:28:52 <sridhar_ram> We can circle back on tacker-senlin in the next meeting.. sorry, we are out of time today
06:29:11 <sridhar_ram> xuhaiwei_: oh, will review.. i think it is close IMO
06:29:20 <sridhar_ram> cores: please review / sign off tacker-senlin
06:29:23 <xuhaiwei_> sridhar_ram: thanks
06:29:25 <sridhar_ram> KanagarajM: specifically you!
06:29:27 <sripriya> sridhar_ram: ack
06:29:38 <sridhar_ram> Alright folks - times up
06:29:47 <sridhar_ram> Happy newyear and merry christmas !
06:29:48 <KanagarajM> sridhar_ram, sure.
06:29:58 <sridhar_ram> talk to you all next year :)
06:29:59 <sripriya> happy holidays everyone
06:30:06 <sridhar_ram> #endmeeting