14:01:13 <ricolin> #startmeeting heat
14:01:14 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:17 <openstack> The meeting name has been set to 'heat'
14:01:33 <ramishra> hi
14:01:43 <ricolin> ramishra, o/
14:02:10 <zaneb> o/
14:02:48 <ricolin> #topic adding items to agenda
14:02:53 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282018-06-27_1400_UTC.29
14:03:11 <ricolin> Any topic you guys like to discuss?
14:03:41 <kazsh> o/
14:03:49 <ricolin> kazsh, hi
14:05:01 <ricolin> #topic Multi-Cloud https://review.openstack.org/#/q/topic:bp/multiple-cloud-support+(status:open+OR+status:merged)
14:05:50 <ricolin> ramishra, zaneb I upload the multicloud works earlier
14:06:09 <ricolin> also the spec too
14:06:24 <ramishra> ricolin: will take a look
14:06:28 <ricolin> still need to add unit test and functional test
14:06:50 <ricolin> but would be great if guys can talk a look
14:06:52 <ricolin> ramishra, thx
14:07:33 <ricolin> tricky to parse around credential:)
14:08:13 <ramishra> 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 <zaneb> added it to my list
14:08:40 <zaneb> ramishra: yeah, that's a good question
14:08:56 <zaneb> I think we need to figure out an interface that works for both
14:09:45 <ramishra> probably we can land it, been in review for long time though
14:09:51 <ricolin> don't see much conflict on both, but I can depend on ssl one since that will be more secure
14:10:18 <ramishra> not sure if we would complete the multicloud thing this release, though zaneb can surely surprise us:)
14:11:03 <zaneb> ramishra: clearly you have not seen my to-do list ;)
14:11:05 <ricolin> ramishra, I would like to see if we can really make it happen:)
14:11:23 <ricolin> zaneb, and where is it:)
14:12:12 <zaneb> 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 <ricolin> zaneb, API Broker too IMO
14:12:52 <zaneb> that's a separate project though
14:13:03 <zaneb> and also something on my to-do list
14:13:23 <ricolin> zaneb, No, I mean API Broker resource in heat(Not sure if we want to do it, but it;s cool:))
14:13:32 <zaneb> oh, right
14:13:47 <zaneb> yeah, that's also cool and definitely not happening in this release ;)
14:14:28 <ricolin> I'm going to work on Vitrage resource later once I put tests for multicloud on:)
14:15:22 <zaneb> ricolin: btw I just re-reviewed https://review.openstack.org/541558 (that ltomasbo was asking about earlier)
14:15:56 <ricolin> zaneb, okay will update it right after meeting
14:16:26 <zaneb> ricolin: the main thing it needs is a test
14:16:43 <ramishra> 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 <ricolin> zaneb, I can't remember why I didn't add unit test, but will recheck again
14:16:58 <ramishra> I was about to comment on the review and then forgot
14:18:26 <ricolin> What else needs to discuss?
14:18:43 <ramishra> I've something to discuss..
14:19:13 <ramishra> https://review.openstack.org/#/c/551871/6/heat/common/config.py, I've added a new config option
14:20:08 <ramishra> therve thinks we should use https://github.com/openstack/heat/blob/master/heat/common/wsgi.py#L211 for it
14:21:09 <ramishra> 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 <ramishra> Wanted to know what others think
14:22:41 <zaneb> 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 <zaneb> 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 <ramishra> yeah, it's for different services and swift does not have any download limit per se
14:23:41 <ricolin> ramishra, so why can't we set unlimit default?
14:24:09 <therve> ricolin: We load the files in memory
14:24:17 <zaneb> ricolin: because we don't want to load infinity bytes into Heat's RAM
14:24:27 <ramishra> zaneb: ok, that probably is a good reason
14:24:55 <ramishra> I mean trying from locally that works when they are in swift
14:25:31 <zaneb> ramishra: yeah, at the very least that's a good reason to set the defaults to the same thing
14:25:46 <zaneb> and arguably they could just use the same config option
14:25:46 <ramishra> I thought it can be confusing when someone tries to see that error and then look for the config
14:26:13 <ramishra> it may be intuitive for the devs but not for the users
14:27:00 <ramishra> I mean operators
14:27:43 <ramishra> But I'm ok either way
14:28:48 <zaneb> the option is not in any group, right?
14:28:58 <ricolin> I think it's fine to use max_json_body_size since that's the buggest size we gonna accept anyway
14:29:09 <ramishra> yep
14:29:12 <ricolin> zaneb, in `Default` I think
14:29:27 <zaneb> I think it's fine to reuse that one then
14:29:32 <ricolin> we can also set overwrite conf if we like
14:30:27 <ricolin> like when swift_objects_download_limit > max_json_body_size we reset swift_objects_download_limit
14:31:25 <zaneb> ricolin: let's not though ;)
14:31:55 <ramishra> 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 <ricolin> ramishra, can we get size before we download it?
14:32:56 <ramishra> ricolin: yes, check that patch:)
14:33:27 <ricolin> ramishra, then user won't fail during downloading right?:)
14:33:32 <zaneb> technically its still the body regardless of whether we're uploading or downloading ;)
14:33:36 <ricolin> they fail before it:)
14:34:32 <zaneb> 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 <zaneb> I think we'll need to make sure there's different error messages
14:35:17 <zaneb> but I don't see an obstacle to using the same config option to set the limit
14:35:25 <ricolin> zaneb, yeah we need good message to show that
14:37:41 <ricolin> Anything else?:)
14:38:05 <ramishra> OK we can add another exception type rather than ta config, not use RequestLimitExceeded:)
14:38:26 <zaneb> +1
14:38:26 <ricolin> ramishra, +1 on that!
14:41:50 <ricolin> Okay, if nothing to put on, we can close meeting now
14:43:03 <ricolin> Okay
14:43:17 <ricolin> please please please help to review https://review.openstack.org/#/c/578363/ :)
14:43:27 <ricolin> multicloud spec
14:43:43 <zaneb> 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 <ricolin> zaneb, you hit that in Master?
14:47:43 <ricolin> 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 <ricolin> in a single milestone
14:48:35 <ramishra> 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 <zaneb> ricolin: yes, I'm seeing that in the gate
14:49:45 <zaneb> the policy logs are too chatty, and that's easy enough to fix
14:49:50 <ricolin> (keep loading logs...)
14:50:20 <ricolin> zaneb, okay, will find it and take a look
14:50:24 <zaneb> 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 <ricolin> ramishra, zaneb so those just information log right
14:53:32 <zaneb> 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 <ricolin> zaneb, might be
14:55:43 <ramishra> ricolin: yeah, it seems to be checking the policy far too often, which probably means something is wrong
14:57:15 <zaneb> that's my concern, yeah
14:59:24 <ricolin> Anyway, let's keep trace on that
14:59:29 <ramishra> ricolin: we can probably raise a bug and do the investigation later, meeting time alomost over
14:59:50 <ricolin> ramishra, +1
15:00:15 <zaneb> +1
15:00:47 <ricolin> let's end meeting now, if nothing to discuss before keep working
15:01:25 <ricolin> #endmeeting