07:00:34 <stevebaker> #startmeeting heat
07:00:35 <openstack> Meeting started Wed Aug 19 07:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:00:38 <openstack> The meeting name has been set to 'heat'
07:00:41 <stevebaker> hi all
07:00:42 <KanagarajM__> hi
07:00:43 <asalkeld> o/
07:00:46 <ramishra> hi
07:00:51 <stevebaker> #topic rollcall
07:00:57 <Drago> hello!
07:01:03 <stevebaker> #chair asalkeld
07:01:04 <openstack> Current chairs: asalkeld stevebaker
07:01:18 <asalkeld> waaat
07:01:20 <stevebaker> asalkeld: just in case my pub net connection dies :)
07:01:21 <asalkeld> ;)
07:01:24 <asalkeld> ok
07:01:54 <stevebaker> #topic adding items to the agenda
07:01:58 <skraynev> hey
07:02:18 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-08-20_0700_UTC.29
07:02:37 <stevebaker> anyone for any thing?
07:02:46 <pas-ha> o/
07:02:51 <stevebaker> pas-ha: hi
07:03:01 <dgonzalez> hi
07:03:04 <asalkeld> you got my topic in there already
07:03:09 <prazumovsky> hi
07:03:17 <shardy> o/
07:03:28 <stevebaker> shardy: hey!
07:03:43 <asalkeld> stevebaker: we could add a topic for 202 return codes
07:03:43 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-08-20_0700_UTC.29
07:03:48 <shardy> stevebaker: Hi!  Sorry, slightly late!
07:04:13 <stevebaker> done
07:04:31 <Qiming> o/
07:04:40 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
07:04:43 <stevebaker> Qiming: hey
07:05:07 <stevebaker> I've already purged merged things, so feel free to add anything *you* think is important
07:05:19 <asalkeld> "convergence scenario tests" needs rebasing
07:05:27 <_tiantian> hi
07:05:28 <asalkeld> that would be good to get in
07:06:12 <stevebaker> _tiantian: hi
07:06:48 <skraynev> tiantian: hi
07:06:55 <stevebaker> I saw a bunch of zaneb rg changes, but I have no idea how they relate to ramishra's
07:07:17 * asalkeld not sure either
07:07:24 <skraynev> stevebaker:As I understand it's alternative approach
07:07:48 <stevebaker> oh, great ;)
07:07:50 <skraynev> looks like Zane wait feedback from Rabi
07:07:57 <ramishra> yeah. zaneb thinks it's a terrible idea to follow RG approach for ASG
07:08:01 <skraynev> and after that they will choose one
07:09:06 <ramishra> and thinks RG resource itself is not good
07:09:41 <pas-ha> ramishra, make a "non-scaling" ASG?
07:09:53 <ramishra> I need some more opinions. I'm willing to stash my work, if more of us think it's a bad idea
07:10:44 <stevebaker> alright, I've put both series on the etherpad
07:10:47 <pas-ha> no need of immediate stashing, we have to compare both, have silly or not arguments and then decide :)
07:11:55 <stevebaker> ramishra: it could be a proper meeting topic if you were both awake at the same time
07:12:24 <skraynev> pas-ha: do you mean review both without testing :) or review and tests both ?
07:12:24 <stevebaker> #topic dogfooding convergence https://etherpad.openstack.org/p/heat-convergence-tasks
07:12:37 <stevebaker> asalkeld: do you want to take this topic?
07:12:44 <asalkeld> ok
07:12:56 <ramishra> sure
07:12:58 <asalkeld> so i want to make sure we are thinking of testing convergence
07:13:30 <asalkeld> we can do semi formal testing, but it would be great if all devs are now switching over to convergence
07:13:48 <asalkeld> so we can find bugs sooner rather than later
07:14:02 <shardy> Do all the existing functional tests work OK?
07:14:04 <stevebaker> yes, I think we're almost ready to encourage devs to run convergence locally for their regular work
07:14:12 <asalkeld> just set "convergence_eningine=True" in heat.conf
07:14:12 <stevebaker> and file bugs as they find them
07:14:22 <asalkeld> shardy: yes
07:14:30 <shardy> asalkeld: nice! :)
07:14:32 <asalkeld> there is one bug
07:14:40 <asalkeld> that sometimes we get a timeout
07:15:02 <asalkeld> https://bugs.launchpad.net/heat/+bug/1486281
07:15:02 <openstack> Launchpad bug 1486281 in heat "convergence functional tests sometimes timeout" [Undecided,New]
07:15:04 <stevebaker> like this https://bugs.launchpad.net/heat/+bug/1483946
07:15:04 <openstack> Launchpad bug 1483946 in heat "Convergence: self.properties not populated in for handle_delete" [Medium,Confirmed] - Assigned to Rico Lin (rico-lin)
07:15:08 <therve> It's be interesting to ask tripleo to use it
07:15:19 <therve> It will certainly uncover some bugs
07:15:25 <asalkeld> therve: see https://etherpad.openstack.org/p/heat-convergence-tasks
07:15:38 <asalkeld> just trying to think what we need to do re: testing
07:15:52 <shardy> therve: yeah, I can try turning it on in devtest
07:16:02 <stevebaker> therve: we could always have a change which switches over by default and look at how the tripleo gate handles it
07:16:03 <asalkeld> everyone feel free to add to that etherpad
07:16:28 <shardy> Although atm TripleO has heat pinned as current master has broken, so we need to work that out first
07:16:35 <asalkeld> we should also define a set of rally tests we want to run
07:17:05 <skraynev> asalkeld: IMo it's mostly depends on template
07:17:18 <asalkeld> (not in the gate, but when deciding when to switch to default convergence)
07:17:37 <skraynev> currently rally covers common commands like create, delete, etc..
07:17:38 <stevebaker> skraynev: behaviour under load would be interesting to know too
07:17:46 <therve> shardy, Wasn't the issue with ec2 auth?
07:17:48 <stevebaker> for different definitions of "load"
07:17:56 <asalkeld> skraynev: yea - but also the scale (numbers of resources and number of heat-engines)
07:18:03 <shardy> therve: no, unfortunately I think there's some other issue as well
07:18:12 <therve> Arg
07:18:13 <shardy> derekh is investigating
07:18:43 <asalkeld> stevebaker: that's all from me, at this point getting devs to use it would be a good thing
07:19:03 <asalkeld> we can work on serious testing in parallel
07:19:13 <stevebaker> asalkeld: yep, +1. I will whenever the lack of bugs let me
07:19:25 <asalkeld> :-O
07:19:33 <skraynev> therve: btw, looks like your patch for replacing v2 on v3 fixed rally issue, which I mentioned yesterday :)
07:19:43 <stevebaker> asalkeld: meant in a nice way :)
07:19:44 <therve> skraynev, OK cool
07:20:07 <stevebaker> #topic discuss https://bugs.launchpad.net/heat/+bug/1475685
07:20:08 <openstack> Launchpad bug 1475685 in heat "test_asg_notifications failed on gates" [High,Confirmed] - Assigned to Rabi Mishra (rabi)
07:20:08 <stevebaker> discuss!
07:20:16 <therve> Yeah this one is a bummer
07:20:24 <stevebaker> that hit me today, I thought it was my patch
07:20:27 <ramishra> I'm not able to reproduce it locally at all
07:20:42 <asalkeld> lovely
07:21:04 <stevebaker> does this test go through ceilometer?
07:21:16 <asalkeld> maybe add "log" notifications too
07:21:26 <asalkeld> to see if we also get those
07:21:35 <asalkeld> at least we can check the logs for that
07:21:47 <asalkeld> notification_driver=messaging,log
07:22:10 <ramishra> yeah. we can do that
07:22:14 <asalkeld> stevebaker: that is a possible issue
07:22:33 <asalkeld> what if ceilometer pops the notification first
07:22:51 <asalkeld> will that prevent our test reciever getting it?
07:23:09 <asalkeld> does ceilometer re-transmit the notifcation?
07:23:20 <asalkeld> (if it does get it)
07:23:43 <therve> I don't think it does?
07:23:56 <therve> You can register several consumer for notifications though I believe
07:23:59 <asalkeld> in which case that is the likely issue
07:24:04 <stevebaker> it would be nice if ceilometer didn't get involved at all, since its a functional test
07:24:21 <ramishra> there is nothing to do with ceilometer, as I understand
07:24:24 <asalkeld> we could turn this into an alarm
07:24:24 <skraynev> I thought, that our test use another queue for testing notification and ceilometer should not affect it
07:24:55 * pas-ha was biumped.. and back again
07:25:32 <therve> It's worth investigating if something doesn't consume it anyway
07:25:52 <stevebaker> how often is it happening?
07:25:55 <asalkeld> yip, maybe add to that bug
07:26:32 <therve> stevebaker, logstash seems down, but I'd say 5-10% at least
07:26:41 <stevebaker> ug
07:26:47 <asalkeld> https://github.com/openstack/heat/blob/master/heat_integrationtests/functional/test_notifications.py#L129
07:26:52 <pas-ha> stevebaker, not too often, and quite without pattern, rechecks usually help
07:26:56 <asalkeld> that looks like "notifcations"
07:27:01 * stevebaker rechecks
07:27:30 <stevebaker> #topic 202 return codes
07:28:13 <asalkeld> ok so there is a bug that we return the wrong stuff
07:28:21 <asalkeld> (200 instead of 220)
07:28:25 <asalkeld> (200 instead of 202)
07:28:27 <shardy> https://wiki.openstack.org/wiki/Heat/Blueprints/V2API
07:28:43 <shardy> It's on the wishlist for v2, I don't see how we can fix it without a version bump
07:28:47 <shardy> is it a new bug?
07:28:57 <shardy> pretty sure there's an old one too
07:29:03 <asalkeld> so i have patch for this, some of it *should* be ok, but the stack stuff should not change
07:29:44 <asalkeld> bug 1477109
07:29:44 <openstack> bug 1477109 in heat "Normal response codes of "Suspend stack" should be 200" [Medium,In progress] https://launchpad.net/bugs/1477109 - Assigned to Angus Salkeld (asalkeld)
07:30:05 <stevebaker> maybe we should leave the current behaviour just in case someone is checking the exact 20x code
07:30:25 <stevebaker> and add it to the list of things to do for v2
07:30:26 <asalkeld> stevebaker: feel free to -2 those patches
07:30:43 <shardy> I think we have to, unfortunately, as there are non heatclient users of the API
07:30:44 <asalkeld> i can add something to that bug
07:30:59 <stevebaker> I believe return code changing patches have landed in the past in nova
07:31:17 <asalkeld> we *could* change the actions
07:31:24 <asalkeld> (maybe less checked)
07:31:42 <asalkeld> but i am not stressed if that series is -2'd)
07:31:53 <stevebaker> asalkeld: I could maybe summon enthusiasm for a -1
07:32:05 <asalkeld> anyways, just highlighting the issue
07:32:09 <stevebaker> lets discuss on the review
07:32:13 <asalkeld> sure
07:32:20 <stevebaker> #topic open discussion
07:32:31 <prazumovsky> I have one suggestion
07:32:46 <prazumovsky> Recently I used dics with resource page
07:33:09 * stevebaker blushes
07:33:21 <prazumovsky> And it was a bit confusing to search from long list of priperties required props
07:33:24 <asalkeld> lol
07:33:44 <shardy> Got to run folks, ttyl
07:33:53 <asalkeld> later shardy
07:33:56 <stevebaker> prazumovsky: could you elaborate a bit?
07:34:29 <pas-ha> we should have better inner-links for resources docs, down to the property level
07:34:51 <prazumovsky> So have an idea to separate all properties to two subparagraphs: required and optional. Your responce?
07:35:07 <pas-ha> prazumovsky, nice one
07:35:39 <asalkeld> prazumovsky: seems ok
07:35:52 <asalkeld> but is that the most important attribute?
07:36:01 <asalkeld> what about replace/inplace
07:36:11 <stevebaker> prazumovsky: I see, yes grouping properties would be good. I don't know if the deprecated ones are grouped last yet too
07:36:18 <pas-ha> I would also suggest to make it happen on a resource-type-show
07:36:33 <asalkeld> and colour code them too;)
07:36:38 <pas-ha> yay!
07:37:39 <stevebaker> steady on
07:38:00 <prazumovsky> Maybe deprecated should be as supported props and should not have separate subparagraph
07:38:35 <stevebaker> pas-ha: I am *constantly* linking people to a resource when I want to link them to a property
07:38:47 <pas-ha> exactly that
07:38:53 <asalkeld> yeah
07:39:02 <pas-ha> a least ad those permalinks to properties
07:39:22 <stevebaker> I assume it will explode the contents list, but whatever
07:39:39 <stevebaker> pas-ha: could you raise a bug so we remember?
07:39:51 <pas-ha> I think we might be able to control the depth of the TOC
07:39:59 <pas-ha> ok, action taken
07:40:48 <stevebaker> shall we finish?
07:40:53 <asalkeld> yes!
07:40:57 <prazumovsky> yes
07:40:58 <pas-ha> +1
07:41:00 <stevebaker> #endmeeting