08:01:31 <ricolin> #startmeeting heat
08:01:32 <openstack> Meeting started Wed Jun 15 08:01:31 2016 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:35 <openstack> The meeting name has been set to 'heat'
08:02:08 <ricolin> #topic Roll call
08:02:15 <stevebaker> \o
08:02:16 <ramishra> hi
08:02:19 <ricolin> o/
08:02:23 <elynn> o/
08:02:25 <huangtianhua> :)
08:02:51 <ricolin> #topic Adding items to agenda
08:03:06 <KanagarajM> hi
08:03:09 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-06-15_0800_UTC.29
08:03:41 <stevebaker> ricolin: could you add nested-depth event list
08:03:58 <ricolin> stevebaker: sure
08:05:05 <ricolin> #topic HOT generator
08:05:22 <ricolin> https://review.openstack.org/328822
08:05:42 <KanagarajM> team, i tried to put the spec for HOT generator ^^
08:06:27 <KanagarajM> this is mainly for generating the HOT template using python API. I and jdob tried to bring up a POC for the same
08:07:14 <KanagarajM> i would need your help on reviewing it and if possible planing to push it for n-2 :)
08:07:47 <ricolin> Will give it a look:)
08:07:59 <KanagarajM> ricolin, sure. thanks.
08:09:01 <ricolin> Maybe also intreasting to getting futher feature over this like Stack template generater on horizon UI:)
08:09:52 <KanagarajM> ricolin, yes. that is nice idea !
08:10:09 <ricolin> #topic nested-depth event list
08:10:33 <stevebaker> hey, I have a spec-lite bug for this here https://bugs.launchpad.net/heat/+bug/1588561
08:10:33 <openstack> Launchpad bug 1588561 in python-heatclient "event list REST API call should support nested stacks" [Medium,In progress] - Assigned to Steve Baker (steve-stevebaker)
08:10:46 <stevebaker> and the heat and heatclient reviews are ready to go
08:11:15 <stevebaker> https://review.openstack.org/#/q/topic:bug/1588561
08:11:22 <shardy> o/
08:11:27 <shardy> sorry I'm late
08:11:33 <stevebaker> shardy: oh, perfect timing
08:11:57 <stevebaker> shardy: I have a spec-lite bug for this here https://bugs.launchpad.net/heat/+bug/1588561
08:11:57 <openstack> Launchpad bug 1588561 in python-heatclient "event list REST API call should support nested stacks" [Medium,In progress] - Assigned to Steve Baker (steve-stevebaker)
08:12:30 <shardy> stevebaker: ah, yeah, I've been planning to pull all your optimization related patches locally and test w/tripleo
08:12:35 <shardy> or have you already done that?
08:12:40 <stevebaker> I'm getting 17s vs 1.7s for an event-list with ~800 events
08:13:20 <stevebaker> shardy: I always test with tripleo, but I'm not creating big overclouds
08:13:45 <shardy> stevebaker: ack - I'll re-test anyway, but I don't have access to huge resources either
08:13:58 <stevebaker> shardy: thats a different series, but zaneb raised an objection https://review.openstack.org/#/c/317220/
08:13:59 <ramishra> stevebaker: will give it a try too.
08:14:14 <shardy> I've been chatting to some folks that do tho, so we can potentially do some large scale tests at some point
08:14:54 <stevebaker> I need to dig into how much we can get out of sqlalchemy for avoiding hitting the database, which is yak shaving into ripping out all our get session logic :o
08:15:25 <ricolin> stevebaker: Maybe you can move https://review.openstack.org/#/c/323614/ out of dependency
08:15:38 <ricolin> it's a good fix
08:15:57 <stevebaker> ricolin: yeah, that will at least end up at the front of the series, or on its own
08:16:34 <ricolin> stevebaker: nice
08:17:00 <shardy> stevebaker: Hmm, ok - I'll give it some thought and comment on the review
08:17:04 <stevebaker> ta
08:18:39 <ricolin> #topic external resource
08:18:41 <ricolin> https://review.openstack.org/#/c/135492/
08:18:57 <ricolin> I think after team's review
08:19:27 <ricolin> hope this series maybe can get merge
08:21:13 <ricolin> fine move on!
08:21:20 <ramishra> ricolin: I have a raised the concern on doing deps for external resource in the last meeting, though I'm ok with it going in with latest change.
08:21:36 <ramishra> though I still don't know why we need to do that.
08:21:46 <stevebaker> ricolin: but if we waited that change could have its first birthday!
08:21:59 <ramishra> lol
08:22:25 <ricolin> ramishra: We do can resloved all deps with external resources
08:23:31 <ramishra> not sure I understand, deps of an external resource has no meaning as we don't manage it's lifecycle
08:23:32 <ricolin> but will require some hard code on all dep function through
08:24:02 <ramishra> anyway, we should discuss it later.
08:24:09 <ricolin> sure
08:24:30 <ricolin> I'm ok to prevent deps:)
08:24:38 <ricolin> #topic convergence status
08:25:28 <shardy> I hit https://bugs.launchpad.net/heat/+bug/1592374 yesterday
08:25:28 <openstack> Launchpad bug 1592374 in heat "deleting in_progress stack with nested stacks fails with convergence enabled" [High,Confirmed]
08:25:30 <ramishra> We've not seen any major issues from other projects yet:)
08:25:34 <ricolin> shardy: since we already turn convergence to default, is there any test from TripleO about that?
08:25:52 <stevebaker> shardy: is that when deleting just stalls? I'm hitting that
08:25:55 <shardy> it may or may not be specific to convergence, but turning it off has definitely improved (or possibly fixed) it
08:26:02 <shardy> stevebaker: yup
08:26:19 <shardy> stevebaker: specifically it happens every time for me if you delete a stack containing nested stacks that are IN_PROGRESS
08:26:45 <shardy> turning off convergence I hit a couple of suspect locking issues on delete, but they may be the other ones already reported that are specific to not-convergence
08:27:11 <stevebaker> I hit this yesterday but I see my fix has landed already https://launchpad.net/bugs/1592243
08:27:11 <openstack> Launchpad bug 1592243 in heat "Convergence: nested stacks are not populated with correct nested_depth" [High,Fix released] - Assigned to Steve Baker (steve-stevebaker)
08:27:23 <shardy> stevebaker: I started a functional test, which appears to reproduce locally but it looks like theres a rack I need to fix before it'll reproduce in the gate:
08:27:32 <shardy> https://review.openstack.org/329460
08:27:47 <stevebaker> one problem I've seen is with *very* large resource groups (over 500)
08:27:48 <ricolin> I think I have hit the same issue with using exponential backoff for retry https://review.openstack.org/#/c/328613/
08:28:32 <stevebaker> create/update gets slower and slower as the sync point data grows, which can be mitigated with update policy, but that doesn't apply to delete
08:28:37 <shardy> stevebaker: FWIW my deletes failed every time with a SoftwareDeploymentGroup of size 4
08:29:00 <stevebaker> I'm hoping for ricolin's exp backoff to land soon to see if it helps
08:29:28 <shardy> ricolin: I'm planning an experimental job for TripleO that enables convergence
08:29:37 <shardy> ricolin: my local testing indicates it's not ready yet tho
08:29:54 <ricolin> stevebaker: I can further more reduce the syncpoint access
08:29:58 <shardy> I suppose we can look at enabling the job anyway tho
08:30:12 <stevebaker> shardy: yes, that would be good
08:30:13 <ricolin> stevebaker: but it might took more time to excute
08:30:43 <ricolin> shardy: cool
08:30:46 <ramishra> shardy: as tripleo ci does not use heat master and fails back to last commit, if the ci fails, can we not enable convergence and check the periodic jobs for issues?
08:31:31 <shardy> ramishra: we've disabled convergence for all tripleo-ci jobs via puppet atm
08:31:48 <ramishra> yeah, I'm asking can we not just enable it?
08:31:52 <shardy> ramishra: if one wanted to check with it enabled now, you can simply post a WIP patch to instack-undercloud reverting my patch that turned it off
08:32:23 <shardy> basically the experimental job will do that via a conditional override of the hieradata inside instack-undercloud that sets convergence_engine
08:32:38 <shardy> ramishra: No, because I've tested locally and it doesn't work
08:33:12 <shardy> we've probably already promoted current-tripleo to beyond the commit which switched convergence on by default
08:33:21 <shardy> so we can't rely on the periodic job to not promote
08:33:32 <shardy> and even if we did, I suspect we'd be stuck with an increasingly old heat
08:33:59 <ramishra> shardy: ok, I was hoping that it's till behind the convergence switch;)
08:34:11 <ramishra> s/till/still
08:34:29 <shardy> ramishra: we'll want to keep picking up bugfixes (and new features), so a long-term heat pin won't work for us
08:34:43 <shardy> I'll be happy to switch convergence on when we can prove the issues are fixed
08:34:56 <shardy> but bear in mind, on the single-node undercloud we don't gain a lot of the benefits
08:35:08 <ramishra> shardy: yeah, I understand
08:36:20 <ricolin> #topic open discussion
08:36:40 <shardy> I'd appreciate some eyes on these heatclient patches:
08:36:43 <shardy> https://review.openstack.org/#/q/status:open+project:openstack/python-heatclient+branch:master+topic:bug/1590421
08:37:03 <shardy> basically the osc commands to show template/environment mangle the output due to the cliff formatters
08:37:11 <shardy> I've proposed what I think is a more sane format
08:37:18 <shardy> e.g something you can actually cut/paste from
08:37:54 <ramishra> I would like some reviews https://review.openstack.org/#/c/294023/. been there for a long time. Was about to abdndon it. Zane suggested to keep it in the queue for it's fate;)
08:38:06 <stevebaker> shardy: I'll try them out
08:38:17 <shardy> Similarly, if there are any cliff formatter experts, I could use some help with https://review.openstack.org/#/c/327205/
08:38:23 <ricolin> shardy: ramishra: try it out++
08:38:26 <shardy> I can't figure out how to format a list of yaml files
08:38:38 <shardy> I want the name of the file, then a pretty printed yaml content
08:38:47 <shardy> cliff won't let me do that atm
08:38:57 <shardy> probably missing something, any help appreciated :)
08:39:49 <stevebaker> shardy: you don't *have* to use a cliff formatter, you could just print it
08:39:54 <shardy> stevebaker, ricolin: thanks!
08:40:05 <shardy> stevebaker: aha, I wasn't sure if that was the done thing ;)
08:40:13 <shardy> that would certainly be easier :)
08:40:14 <stevebaker> we do it here and there
08:40:23 <shardy> stevebaker: ack, maybe I'll do that then, thanks!
08:40:55 <shardy> ramishra: is there any way to break that patch down in size?
08:41:08 <stevebaker> shardy: also there is yaml markup to denote beginning and end of file in multi file streams - check out the official spec
08:41:17 <shardy> that's probably not helping wrt attracting reviews IMO
08:41:28 <shardy> stevebaker: cool, thanks will do
08:42:00 <ramishra> shardy: it's not complex patch(though looks big), just moved the the some tests around;)
08:42:28 <ramishra> shardy: If breaking down would help it gettting reviewed, I can spend time to do it:)
08:42:38 <shardy> ramishra: ack, I'll try to check it out
08:43:17 <ricolin> Need some help and review on https://review.openstack.org/#/c/280201/
08:43:20 <shardy> ramishra: I just think smaller patches tend to more easily attract reviewers, so if there's a logical way to split it, that may help
08:43:23 <ramishra> shardy: thanks
08:45:12 <ricolin> anything else:)?
08:45:25 <ricolin> going one
08:45:44 <ricolin> going twice
08:45:57 <ricolin> #endmeeting