14:01:13 #startmeeting heat 14:01:14 Meeting started Wed Jun 27 14:01:13 2018 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:17 The meeting name has been set to 'heat' 14:01:33 hi 14:01:43 ramishra, o/ 14:02:10 o/ 14:02:48 #topic adding items to agenda 14:02:53 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282018-06-27_1400_UTC.29 14:03:11 Any topic you guys like to discuss? 14:03:41 o/ 14:03:49 kazsh, hi 14:05:01 #topic Multi-Cloud https://review.openstack.org/#/q/topic:bp/multiple-cloud-support+(status:open+OR+status:merged) 14:05:50 ramishra, zaneb I upload the multicloud works earlier 14:06:09 also the spec too 14:06:24 ricolin: will take a look 14:06:28 still need to add unit test and functional test 14:06:50 but would be great if guys can talk a look 14:06:52 ramishra, thx 14:07:33 tricky to parse around credential:) 14:08:13 zaneb: I was wondering if we should merge https://review.openstack.org/#/c/480923 or wait for the multicloud thing to be implemened with ssl options in barbican? 14:08:17 added it to my list 14:08:40 ramishra: yeah, that's a good question 14:08:56 I think we need to figure out an interface that works for both 14:09:45 probably we can land it, been in review for long time though 14:09:51 don't see much conflict on both, but I can depend on ssl one since that will be more secure 14:10:18 not sure if we would complete the multicloud thing this release, though zaneb can surely surprise us:) 14:11:03 ramishra: clearly you have not seen my to-do list ;) 14:11:05 ramishra, I would like to see if we can really make it happen:) 14:11:23 zaneb, and where is it:) 14:12:12 it would be cool if we can do it. that's definitely the thing that is going to generate the most excitement from outside the project 14:12:39 zaneb, API Broker too IMO 14:12:52 that's a separate project though 14:13:03 and also something on my to-do list 14:13:23 zaneb, No, I mean API Broker resource in heat(Not sure if we want to do it, but it;s cool:)) 14:13:32 oh, right 14:13:47 yeah, that's also cool and definitely not happening in this release ;) 14:14:28 I'm going to work on Vitrage resource later once I put tests for multicloud on:) 14:15:22 ricolin: btw I just re-reviewed https://review.openstack.org/541558 (that ltomasbo was asking about earlier) 14:15:56 zaneb, okay will update it right after meeting 14:16:26 ricolin: the main thing it needs is a test 14:16:43 zaneb, ricolin We've similar issue with L7Rule resource. may be that can be fixed too, separate patch would be fine too. 14:16:58 zaneb, I can't remember why I didn't add unit test, but will recheck again 14:16:58 I was about to comment on the review and then forgot 14:18:26 What else needs to discuss? 14:18:43 I've something to discuss.. 14:19:13 https://review.openstack.org/#/c/551871/6/heat/common/config.py, I've added a new config option 14:20:08 therve thinks we should use https://github.com/openstack/heat/blob/master/heat/common/wsgi.py#L211 for it 14:21:09 IMO, it can be confusing as it's used wrt heat vs swift download limit, but would mean the samething in the context of what we're doing 14:21:49 Wanted to know what others think 14:22:41 I guess the advantage of therve's approach would be that the limit is the same no matter how you use Heat 14:23:18 so you couldn't e.g. end up with something that was working in Swift and then you download the templates locally and try it from there and suddenly it breaks 14:23:20 yeah, it's for different services and swift does not have any download limit per se 14:23:41 ramishra, so why can't we set unlimit default? 14:24:09 ricolin: We load the files in memory 14:24:17 ricolin: because we don't want to load infinity bytes into Heat's RAM 14:24:27 zaneb: ok, that probably is a good reason 14:24:55 I mean trying from locally that works when they are in swift 14:25:31 ramishra: yeah, at the very least that's a good reason to set the defaults to the same thing 14:25:46 and arguably they could just use the same config option 14:25:46 I thought it can be confusing when someone tries to see that error and then look for the config 14:26:13 it may be intuitive for the devs but not for the users 14:27:00 I mean operators 14:27:43 But I'm ok either way 14:28:48 the option is not in any group, right? 14:28:58 I think it's fine to use max_json_body_size since that's the buggest size we gonna accept anyway 14:29:09 yep 14:29:12 zaneb, in `Default` I think 14:29:27 I think it's fine to reuse that one then 14:29:32 we can also set overwrite conf if we like 14:30:27 like when swift_objects_download_limit > max_json_body_size we reset swift_objects_download_limit 14:31:25 ricolin: let's not though ;) 14:31:55 OK, but I still think from user point of view it would be confusing when they see an error the stack action failed due to that limit when downloading from swift, but anyway I'll change 14:32:38 ramishra, can we get size before we download it? 14:32:56 ricolin: yes, check that patch:) 14:33:27 ramishra, then user won't fail during downloading right?:) 14:33:32 technically its still the body regardless of whether we're uploading or downloading ;) 14:33:36 they fail before it:) 14:34:32 ricolin: ramishra's point is that it'll fail when sending in a very small request, complaining that the request size is too big 14:35:02 I think we'll need to make sure there's different error messages 14:35:17 but I don't see an obstacle to using the same config option to set the limit 14:35:25 zaneb, yeah we need good message to show that 14:37:41 Anything else?:) 14:38:05 OK we can add another exception type rather than ta config, not use RequestLimitExceeded:) 14:38:26 +1 14:38:26 ramishra, +1 on that! 14:41:50 Okay, if nothing to put on, we can close meeting now 14:43:03 Okay 14:43:17 please please please help to review https://review.openstack.org/#/c/578363/ :) 14:43:27 multicloud spec 14:43:43 ricolin: btw question for you: http://eavesdrop.openstack.org/irclogs/%23heat/%23heat.2018-06-26.log.html#t2018-06-26T13:23:11 14:46:30 zaneb, you hit that in Master? 14:47:43 We did have some period to keep pop those error message out to log during very first introduce policy in code to heat 14:48:01 in a single milestone 14:48:35 http://logs.openstack.org/53/578253/1/check/heat-functional-orig-mysql-lbaasv2/253251f/logs/screen-h-eng.txt.gz#_Jun_27_03_36_07_827551 14:48:41 ricolin: yes, I'm seeing that in the gate 14:49:45 the policy logs are too chatty, and that's easy enough to fix 14:49:50 (keep loading logs...) 14:50:20 zaneb, okay, will find it and take a look 14:50:24 but the fact that we're also seeing "Fetching data from file:///etc/heat/templates/AWS_RDS_DBInstance.yaml" in there suggests something else is happening, like we're reloading the global environment all the time 14:52:29 ramishra, zaneb so those just information log right 14:53:32 in that link that ramishra posted it's still doing it 14 minutes after the test started. I'd expect to see the global env loaded only once per worker at startup 14:55:11 zaneb, might be 14:55:43 ricolin: yeah, it seems to be checking the policy far too often, which probably means something is wrong 14:57:15 that's my concern, yeah 14:59:24 Anyway, let's keep trace on that 14:59:29 ricolin: we can probably raise a bug and do the investigation later, meeting time alomost over 14:59:50 ramishra, +1 15:00:15 +1 15:00:47 let's end meeting now, if nothing to discuss before keep working 15:01:25 #endmeeting