07:01:01 #startmeeting heat 07:01:02 Meeting started Wed May 27 07:01:01 2015 UTC and is due to finish in 60 minutes. The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:01:05 The meeting name has been set to 'heat' 07:01:11 #topic rollcall 07:01:19 hi all 07:01:19 o/ 07:01:20 hi all 07:01:22 welcome, the rest of the world 07:01:22 hi 07:01:24 hi all 07:01:27 o/ 07:01:43 o/ 07:01:45 hi 07:02:02 I see some new nicks in the room tonight 07:02:14 #topic Adding items to agenda 07:02:23 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-05-27_0700_UTC.29 07:02:55 this may end up being a shortish meeting, if we're all feeling a bit post-summit 07:02:55 o/ 07:03:08 o/ 07:03:11 anything else for the agenda> 07:03:13 ? 07:03:40 #topic heat reviews 07:03:51 #link https://etherpad.openstack.org/p/heat-reviews 07:04:06 >only item about semantics of support status parameters 07:04:25 prazumovsky: yep, I pushed that one down 07:04:31 OK 07:04:45 So here is the page I'll be curating https://etherpad.openstack.org/p/heat-reviews 07:05:57 feel free to add your own changes, or changes you think are important, and I'll keep it so that there are no more than 10 reviews so that heat-core have something manageable to put their attention on 07:06:28 stevebaker: ok 07:06:36 hey, https://review.openstack.org/#/c/154977/ merged. we'll need to find something else important but not convergence 07:07:14 Where are we with fixing the memory usage issues? 07:07:35 sirushti: do you think you could refresh https://review.openstack.org/#/c/154977/ ? 07:07:41 uhh...you mean for example parent stack inspection for example? 07:07:46 stevebaker, sure, will do 07:07:51 shardy: thats a point, I'll add my 2 for that 07:08:49 anyone has signed up on the client changes? 07:09:56 Qiming: which ones? 07:10:12 outputs as not-pretty-tables, stevebaker 07:10:27 https://github.com/openstack/heat/blob/master/heat/engine/stack.py#L299 I blame this for memory usage 07:10:28 oh, here is an important client change, it fixes the broken gate https://review.openstack.org/#/c/185834/ 07:10:48 inc0: my changes fix that 07:11:39 Qiming: I think ryansb was going to convert his existing openstackclient work to an in-tree plugin 07:11:39 stevebaker, thing is, this is only run in validation 07:11:45 from what I know 07:11:51 so before stack.store() 07:12:25 inc0: and create, and update. so I think the resources will be in db for the latter times it is called 07:14:00 looks like the heatclient sessionclient change might be almost ready to land <- prazumovsky 07:14:36 yes, I just wait https://review.openstack.org/#/c/185834/ merging 07:14:43 *it 07:15:11 stevebaker, https://github.com/openstack/heat/blob/master/heat/engine/resources/stack_resource.py#L226 this is only place its called 07:16:02 inc0: which is called by _child_parsed_template, which is called by create_with_template and update_with_template 07:16:03 and we can't put db call there, because it will be called before stack.store() 07:16:32 inc0: so its not validate only (and its being called too often, but that is a separate issue) 07:17:12 fair enough, I guess we should dig into that more, but yeah, db call will help a lot 07:17:41 inc0: I just want something that is appropriate to backport to kilo, then we should completely rethink the approach 07:18:06 yeah...whole logic of this fucntion seems...overengineered to say the least 07:18:41 I mean recursively call total resources just to check if it doesn't exceed one variable in config? 07:18:48 are there any heat-specs burning hot right now? 07:18:53 but that's for another discussion. 07:19:10 I'll be cooking spec for random default parameter 07:19:26 I guess its not burning hot, but it touches hot;) 07:20:26 ok, I'll update the heat-specs section later 07:20:30 moving on 07:20:47 #topic parameters for SupportStatus for displaying current status and from which object is supported 07:20:52 OK 07:21:19 Now we have one parameter version which displays version of the current status 07:21:26 #link http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/support.py 07:22:12 I want to add new parameter since which will means since which release this feature is available 07:22:43 ... or when it was deprecated?:) 07:22:51 prazumovsky: like a history of support statuses? 07:22:56 yeah 07:23:10 but 'since' is more suitable for current status, e.g. status.DEPRECATED since ... and version of object is ... 07:23:17 can we not provide multiple support statuses, probably a list ex. SUPPORTED, version DEPRECATED version? 07:23:38 +1 to 'since' 07:24:17 So 07:24:25 since for current statuses 07:24:33 prazumovsky: to me, 'version' is what since means 07:25:06 can we bump version without changing status? 07:25:26 stevebaker: you mean version for current statuses and since for dispaying 'available since'? 07:25:35 inc0: why would we do that? 07:25:55 I don't know, I'm asking - if we can't then I agree - version == since 07:26:37 thing is, what does version mean anyway if we change it *only* on status change? 07:26:40 inc0: I think, we can bump version only if status changed, else for what 07:26:49 afaik, the version never changes after it is set (at least it hasn't to my knowledge), so it seems to already be behaving like a 'since' 07:27:05 prazumovsky, then every version bump is essentialy "since" right? 07:28:13 prazumovsky: since aside, it sounds like you would like a list of status objects to communicate the resource's history, which seems useful 07:28:25 +1 07:28:54 SUPPORTED since 2014.1, DEPRECATED since 2015.1 07:29:06 stevebaker: it's sounds reasonable 07:29:41 if we didn't want to make every status attribute accept a list of SupportStatus, we could always add a SupportStatus.previous_status, and they just accumulate like a singly linked list 07:29:51 with the newest status at the root 07:30:44 stevebaker: that's what I like 07:31:12 prazumovsky: sure, +1 07:31:44 OK, now it's clear for me, what to do, thanks:) 07:32:01 prazumovsky: this is probably worthy of a short spec 07:32:17 please, add an use case as well there 07:32:29 there is a spec https://review.openstack.org/#/c/153235/ ehich can contains this 07:32:31 *which 07:33:26 because this changes relates to deprecation improvements 07:33:34 deprecating improvements? I thought we wanted to do the opposite ;) 07:33:58 (dad joke) 07:34:20 hah 07:34:29 prazumovsky: i've put that spec on the heat-reviews page 07:34:39 but in specs it's just done in regards to docs... 07:34:48 stevebaker: OK 07:34:49 #topic Open discussion 07:35:07 inc0: I think SupportStatus is only used for docs generation? 07:35:42 stevebaker, it would be good to show support_status in resource-type-list too 07:35:43 maybe...I honestly don't know:) 07:36:15 QIming: I work on it 07:36:19 Qiming: yeah, +1 if we don't already. there may be a spec for filtering by status too 07:36:59 prazumovsky, https://review.openstack.org/#/c/147761/ 07:37:22 one question from me - regarding total_resources 07:37:38 Qiming: thank you, I don't know about it 07:37:53 can we think of a way to count these without recursive counts? (I'm talking about not-yet-in-database case) 07:38:21 or wheter or not we *actually* need cfg.CONF.max_resources_per_stack in regards of nested stacks? 07:38:39 I mean once we decoupled these in kilo...what's point of this config? 07:38:59 inc0: its harder now that nested stacks are created via rpc calls. In the old days all stacks were in memory anyway 07:39:22 I know, but that's why this config existed in the first place right? 07:39:34 to limit memory consumption if user wants huge stack 07:39:54 now we decoupled nested stacks, so its only a problem with huge single stack 07:40:04 and these are way easyier to count... 07:40:16 inc0: well, or a huge tree of nested stacks on a single heat-engine.. 07:40:30 inc0: you have a point, since they're really separate stacks now we may not need to limit by the whole stack tree, and I think we already have a total stack quota I think 07:40:56 anyone uses single heat engine? and should we care about such people if they're asking themselves for problems anyway? 07:41:17 but yeah, maybe just a limit on stacks, and resources per individual stack is enough, then rely on underlying services to enforce their own quotas 07:41:30 inc0: well, TripleO does in many cases.. 07:41:38 fair enough 07:41:52 but in tripleo total_resources is irrelevant anyway right? 07:41:56 which is the use-case which exposed the excessive memory consumption problems recently 07:41:59 validation I mean 07:42:21 inc0: yeah, keep creating resources until your seed OOM kills something :\ 07:42:24 ironically, validation takes most of memory, not actual execution 07:42:36 But you're right, maybe we should make enforcing the limits optional 07:42:42 the irony was not lost on us 07:42:46 and turn them off for the tripleo seed 07:43:22 my question is - do we need that kind of validation at all;) 07:43:29 inc0, GOOD question 07:43:48 shardy: that may not be backportable though, I may prefer intrepreting max_resources_per_stack to not include nested stack resources 07:43:53 it was relevant in tenat cloud without decouple nested 07:44:05 Frankly I feel that validation mostly exists because services provide poor error feedback 07:44:46 stevebaker: I was thinking a new value to an existing config option, e.g max_resources_per_stack = False or something 07:44:57 that probably would be backportable, as it's not adding a new option 07:45:20 shardy: but if the default remains the same then it still remains broken for everyone else 07:45:40 we can revise if it's required at all, and for now keep this optional 07:45:48 shardy: and it probably has to remain the same for a backport 07:45:50 and later on possibly deprecate whole mechanism 07:45:50 ? 07:46:11 stevebaker: true, but not everyone is creating trees 50 stacks deep 07:46:22 and the option would be available to everyone 07:46:40 stevebaker: if there's a way to fix the validation for the default case, obviously we should do that though :) 07:47:25 thankfully the root_stack_id change which has landed has merits on its own 07:48:44 soo...spec for applying "false" as possible value for max_resources_for_stack? 07:48:55 or just point out 0 == unlimited? 07:49:04 or -1 ;) 07:49:04 shardy, inc0, therve, etc: could you put your thoughts in the review and poke the USians when they're up? I don't mind throwing away that work 07:49:20 stevebaker: sure, will do 07:49:32 Yep 07:49:42 ofc 07:50:17 should we finish off now? any other business? 07:51:02 #endmeeting