20:01:26 #startmeeting heat 20:01:27 Meeting started Wed Jun 3 20:01:26 2015 UTC and is due to finish in 60 minutes. The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:32 The meeting name has been set to 'heat' 20:01:37 #topic rollcall 20:01:38 o/ 20:01:42 o/ 20:01:44 hi 20:01:48 o/ 20:01:53 o/ 20:02:01 o/ 20:02:06 hi 20:02:20 \o 20:02:43 tag is closed ... 20:02:53 #topic Adding items to agenda 20:03:11 The alt meeting time went really well, good turnout 20:03:21 great 20:03:31 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-03_2000_UTC.29 20:03:46 that makes a nice change :) 20:04:03 and as a bonus, I didn't have to get up ;) 20:04:24 lucky you 6am here 20:05:07 anything for the agenda? 20:05:29 I have one question and one request for review :) 20:05:40 #topic heat reviews 20:05:43 #link https://etherpad.openstack.org/p/heat-reviews 20:05:53 skraynev_: chuck it in :) 20:07:00 There is only one proposed fix for a High bug, and it may be a bit stale. I'll ask Jamie to refresh it when he is about 20:07:59 oh, there is a new bug 20:08:09 looks like our kilo gate is wedged 20:08:15 and if there are some tripleO guys about to help with the use case in https://review.openstack.org/#/c/134848/ 20:08:17 yep 20:09:10 stevebaker: agenda is updated 20:09:29 asalkeld: should an external resource even allow properties to be set? 20:09:57 stevebaker: well it's a pain to remove and add them - I thought 20:10:12 asalkeld: ah, so they'll just be ignored 20:10:26 also messy to remove the validation that defines the required stuff 20:10:39 (so yes, just ignore) 20:10:56 i won't call handle_update etc.. 20:10:57 stevebaker: in a pre-convergence world I think it would have to 20:11:29 to establish the baseline for a future update if you make it a non-external resource again 20:11:39 (disclaimer: I haven't read the spec) 20:11:47 speaking of, https://review.openstack.org/#/c/180022 is the only convergence review I'm aware of, and we could possibly try switching it on once it lands 20:12:02 hahaha :) 20:12:15 we might want to actually run it :-O 20:12:23 i mean obviously nothing will work... 20:12:32 * asalkeld still got to try that, maybe today 20:12:38 switch on locally to fix all the things I mean 20:12:52 yeah, I'll see what happens today 20:13:02 https://review.openstack.org/#/c/163132/ is also convergence 20:13:48 zaneb: got it 20:14:05 or we can have an do-not-merge-me patch that switches it on and see how func.gate reacts to new code being merged :) 20:14:36 #topic High priority bugs 20:14:37 pas-ha: yeah, should be easy 20:14:41 +1 20:15:26 If you refresh the agenda the item is hyperlinked. Too long to paste here 20:16:04 I just wanted to do a quick scan of High,Critical bugs which haven't been started yet, just in case someone is inspired to work on one 20:16:13 #link https://bugs.launchpad.net/heat/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.u 20:16:14 sed=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search 20:16:25 you're right, it *is* too long 20:16:26 ... or bump it down to Medium 20:16:34 zaneb: o.O 20:16:41 zaneb: whhhhhhhy 20:16:59 stevebaker: it sounded like a sort of challenge 20:17:02 btw: https://bugs.launchpad.net/heat/+bug/1388047 looks like a part of existed spec. 20:17:02 Launchpad bug 1388047 in heat "Validation should catch unavailable resources" [High,Triaged] - Assigned to Tetiana Lashchova (tlashchova) 20:17:12 I mean conditionally registered resources... 20:17:29 yes it is 20:17:31 Does anyone want to tackle https://bugs.launchpad.net/heat/+bug/1459837 ? It is really affecting TripleO 20:17:31 Launchpad bug 1459837 in heat "Error messages from nested stacks are awful" [High,Triaged] 20:17:36 i can try fix the error messages I messed up 20:17:45 bug 1459837 20:18:14 stevebaker: how long until L1? 20:18:58 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 20:19:01 I wanna say like 4 weeks 20:19:06 June 23-25 20:19:21 more like 3 20:19:32 ok thanks 20:19:34 3 is like 4 20:19:37 * asalkeld bookmarking that 20:20:47 ok, moving on 20:20:49 https://bugs.launchpad.net/heat/+bug/1433340 - what about this bug? 20:20:49 Launchpad bug 1433340 in heat "stack actions do not guarantee that the stack will be placed into IN_PROGRESS by the time they return" [High,Triaged] 20:20:50 #topic update about functional test for heatclient 20:21:03 I have not seen it on gates couple weeks :) 20:21:18 ok. this item from me. 20:21:25 yeah, that one would be *really* nice to fix 20:21:26 asalkeld, skraynev_: Is that a duplicate? It sounds like the one we closed yesterday 20:22:00 stevebaker: that's similar, but not the same 20:22:15 according to the results for https://review.openstack.org/#/c/180539/ - I suppose, that tests pass :) 20:22:15 that's getting into in-progress 20:22:53 so if somebody review it, it will be good, I plan to move experimental job to gate (non voting ) 20:23:21 nice skraynev_ 20:23:22 asalkeld: I have not re-check it. may be it works ? 20:23:36 asalkeld: ^ it's about bug :) 20:23:45 not about functional tests 20:24:02 skraynev_: yeah, lets make it non-voting. I wasn't even aware of the experimental job 20:24:32 stevebaker: ok. so will upload a patch for it. 20:25:14 that is all for this item ;) 20:25:34 #topic question about destroy behavior of outputs 20:25:44 again from me. 20:26:49 so the idea, that sometimes using outputs may be crucial for stacks. 20:27:08 if we have template with 100 vms and 100 outputs values 20:27:20 which asks ip or id of these vms 20:27:20 skraynev_: do you mean that outputs are not available during IN_PROGRESS? 20:27:31 no 20:28:00 it's slow? 20:28:03 that it can not be scale for big cloud 20:28:08 asalkeld: right 20:28:22 for a big stack you mean 20:28:25 we asked all these instances and it fails with timeout error 20:28:42 pas-ha: big cloud with big stacks :) 20:28:43 heat stack show becomes a tiny ddos 20:28:55 pas-ha: right 20:29:01 what timeout comes into play? 20:29:02 skraynev_: is each one resulting in a nova GET? 20:29:12 stevebaker, yes 20:29:14 asalkeld: 1 minute I suppose 20:29:27 stevebaker: correct 20:29:30 at least one heat has the value it is memoized for the duration of the operation 20:29:55 well we do have the caching on the way 20:30:30 skraynev_: so ID shouldn't result in a nova call, since IP is so often requested maybe we should be storing it in the Server resource_data 20:30:56 I have sometimes thought that convergence should have like a dummy resource (or something, it could be a separate db table) for caching outputs 20:30:59 hashtag fixedbyconvergence 20:31:04 so they'd be part of the dependency graph 20:31:23 stevebaker: it solves only this case, but if it will be something else (another resources with another attribute) 20:31:28 stevebaker: no, it would require some extra development 20:31:39 it seems it would be better to implement sort-of yielding thing in stackresource (like we have for check_*_thing) when it asks for outputs of its child resources 20:31:49 stevebaker: "hashtag fixedbyconvergence" lol ))) 20:31:50 (not currently planned) 20:31:55 that would smear the ddosing 20:31:58 oer time 20:32:28 but timeout problem will be left for sure 20:32:50 no easy solution here... 20:33:17 zaneb: I like idea with separate table and caching. but I don't think that it will be soon or I am wrong? 20:33:32 skraynev_: we have dogpile caching on the way 20:33:43 not sure we need more mechanisms 20:33:49 (for caching) 20:33:50 asalkeld: yeah. Also we discussed some batching way ... 20:33:54 skraynev: no, you're correct 20:34:06 it won't be soon 20:34:26 zaneb: convergence Phase 3 ? :) 20:34:35 skraynev_, batching would help in create/update, not outputs resolution 20:35:04 when no actual resource action is running 20:35:11 skraynev_: lol. well it would be possible to implement once phase 1 is working. phase 2a? 20:35:16 asalkeld: may be. We may try to extend caching solution on this issue 20:36:01 #topic open discussion 20:36:05 i think that would be a good start skraynev_ 20:36:09 zaneb: I thought, that get_reality and some related stuff if phase 2a, so I agree with 2b :) 20:36:31 sold 20:37:02 asalkeld: I just afraid about right approach, when we should update data in cache 20:37:24 asalkeld: on each request or periodically... 20:37:33 skraynev_: not sure 20:37:47 skraynev_: maybe on stack-check? 20:37:50 zaneb: :) 20:38:00 #chair zaneb 20:38:01 Current chairs: stevebaker zaneb 20:38:12 dammit 20:38:19 I need to go soon, so zaneb can endmeeting 20:38:20 asalkeld: but we speak about stack-show... 20:38:52 skraynev_: so I thing in convergence-world they should be refreshed when you trigger a converge 20:39:05 stevebaker: ok. bye 20:39:05 s/thing/think/ 20:39:16 skraynev_: doesn't dogpile have an aging (you can set a timelimit on the caching)? 20:39:40 asalkeld: Yes, it has 20:39:48 asalkeld: memcache does assuming you are using that as the backend 20:39:55 other backends not so much iirc 20:40:06 so the next thing that needs it will have to go get it 20:40:07 asalkeld: but we want get actual info on async stack-show request 20:40:28 asalkeld: you can also invalidate some values using the dogpile 20:40:41 invalidate = make old 20:40:51 kairat_kushaev1: ok, thanks 20:41:22 zaneb: so manually by command, and for other commands should be used values from DB ? 20:41:45 skraynev_: that's also a good idea, trying to parallel'ise the show output 20:42:05 skraynev_: in convergence world that makes sense to me 20:43:24 asalkeld, zaneb: but the one same issue - huge umbers of request in the same time (after converge or after stack-show) 20:44:20 well with convergence we'll not be doing anything that we wouldn't have to anyway to do the converge 20:44:22 hm... may be update cache step by step ... 20:44:36 skraynev_: we should cache the attributes after create/update when we get the status 20:44:38 so I say we burn that bridge when we come to it 20:45:19 it's probably less polling-intensive than the create 20:45:57 zaneb: sounds good 20:46:29 asalkeld: and then update it in separate task periodically .. 20:46:59 skraynev_: honestly not sure, i am not usually a fan of periodic tasks 20:47:07 asalkeld, +1 20:47:19 they become messy to scale 20:47:23 asalkeld: ok. I think we will try to use caching + upload a spec for deep discussion 20:47:30 i'd suggest on demand 20:47:40 I would say cache every attr but "show" after create/update 20:47:44 asalkeld: got it. I tend to agree :( 20:48:29 they usually are not the thing which is changing in-band by itself 20:48:43 pas-ha: not sure, what you mean by "show" after ... 20:48:48 and out-of band changes - we wash our hands 20:48:55 "show" attribute 20:49:04 -2 on periodic tasks 20:49:05 which is everything an object has 20:49:42 pas-ha: what about updating cache ? 20:50:09 on demand if really needed. by check_reality for example 20:50:10 pas-ha: +1, and I wish we had implemented it that way from the beginning. slightly nervous about changing it now though 20:52:08 * asalkeld heading off .. sorting kids for school 20:52:40 about "show" attr - it 1) might be too huge, 2) it *might* contain things that change in-band , you never now for every client 20:53:00 pas-ha: and it's again do not solve issue with several requests in the same time.... however may it works successively now... 20:53:28 pas-ha: unpredictable world!! 20:53:31 :) 20:53:32 skraynev_, several requests? 20:54:18 pas-ha: one request - one output (which references on property not stored in Heat db) 20:55:24 any other discussion? 20:55:38 if people put "show" attr to hard use - they should ask us to add a separate attr for what they are using it 20:55:40 zaneb: none from me :) 20:55:42 IMO 20:56:01 otherwise as your appointed overlord^W chair, I'm shutting this thing down :) 20:56:02 zaneb, i'm good :) 20:56:05 Guys, anyone noticed that stable/kilo is broken 20:56:17 https://bugs.launchpad.net/heat/+bug/1461592 20:56:17 Launchpad bug 1461592 in heat "stable\kilo is broken due to version conflict error" [Undecided,New] 20:56:39 That's all from my side 20:57:12 I think that pas-ha mentioned it above, but not sure about solution 20:57:27 Importance: Critical 20:57:44 sorting out global requirements for kilo I guess 20:58:47 ok, thanks everyone 20:58:51 #endmeeting