08:00:14 <therve> #startmeeting heat
08:00:15 <openstack> Meeting started Wed May 18 08:00:14 2016 UTC and is due to finish in 60 minutes.  The chair is therve. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:19 <openstack> The meeting name has been set to 'heat'
08:00:24 <therve> #topic Roll call
08:00:32 <therve> Alright
08:00:37 <skraynev> o/
08:00:39 <stevebaker> \o
08:00:43 <ramishra> hi
08:01:36 <therve> tiantian ricolin
08:01:47 <tiantian> o/
08:02:02 <ricolin> o/
08:02:09 <skraynev> therve: I can help with hosting, but would like to give a chance to other guys ;)
08:02:20 <elynn_> Hi
08:02:25 <therve> :)
08:03:18 <therve> #topic Adding items to agenda
08:03:26 <therve> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-05-18_0800_UTC.29
08:03:47 <therve> #topic Make grenade non-voting
08:03:51 <therve> Okay, I added this
08:04:03 <therve> I'm getting more and more annoyed with the grenade job
08:04:15 <therve> I feel that's it's the one that's failing the most
08:04:29 <therve> And never because of actual Heat changes AFAICT
08:04:45 <stevebaker> is it running non heat tests?
08:04:52 <ramishra> yeah, most of the time it's the tempest tests
08:05:04 <therve> stevebaker, Yeah
08:05:12 <therve> Also, it relies on devstack to work on 2 versions
08:05:20 <therve> Which is too much to ask apparently
08:05:51 <stevebaker> how about we start by only running the heat tempest tests
08:06:09 <therve> stevebaker, It wouldn't really fix the issues with devstack
08:06:11 <stevebaker> I realise that doesn't solve devstack version issues
08:06:14 <ramishra> tempest smoke tests, not heat related are the normal failures
08:06:27 <shardy> o/ sorry I'm late
08:06:36 <therve> Hum I guess the latest one was because of tempest though
08:06:54 <therve> Maybe one step would be to disable vpnaas
08:07:20 <therve> I've learnt that it's on maintenance mode, and it's a easy target for the failures we've had recently
08:07:30 <ramishra> IMO, not a good idea to just abandon it, probably we need to find a way to make it stable?
08:08:02 <stevebaker> we could turn off every service which is not involved in the heat tempest tests
08:08:04 <therve> ramishra, So what do you think of removing vpnaas?
08:08:19 <ramishra> we can skip all neutron tempest tests
08:08:33 <skraynev> therve: I thought, that we have a plan to remove all heat non-related tests from tempest job
08:08:41 <skraynev> potentially and for grenade job too
08:09:00 <stevebaker> skraynev: by then tempest will be able to run tests from the heat tree
08:09:20 <stevebaker> skraynev: so there can be way more heat tests running in grenade
08:09:33 <skraynev> therve: I don't see an important reason to execute tests from other projects on our gates
08:09:45 <ramishra> skraynev: its the devstack-gate running the tempest smoke tests after upgrade
08:09:45 <therve> skraynev, That's fair
08:09:47 <skraynev> stevebaker: yeah. it make sense for me
08:09:50 <stevebaker> especially ones which don't depend on heat
08:09:53 <ramishra> that normally fails
08:09:58 <therve> vpnaas is involved in our tests though
08:10:02 <therve> For now
08:10:39 <skraynev> therve: is it difficult to disable it for our gates ?
08:11:22 <therve> I don't think so
08:11:27 <therve> #addchair ricolin
08:11:29 <skraynev> I can take a look on it, but if someone already know what need to do...
08:12:12 <therve> #help
08:12:23 <therve> Hum :)
08:12:24 <stevebaker> hash chair
08:12:29 <ricolin> :)
08:12:35 <therve> #chair ricolin
08:12:36 <openstack> Current chairs: ricolin therve
08:12:59 <ramishra> I tried disabling neutron tests for the job https://review.openstack.org/#/c/312811/1/jenkins/jobs/heat.yaml
08:13:24 <ramishra> but it seems project-config changes does not work with Depends-On.
08:13:25 <therve> ramishra, Should we do that all the time ?
08:13:30 <therve> Yeah it doesn't
08:13:52 <therve> Anyway have to, sorry
08:14:21 <ricolin> I will take over then:)
08:16:01 <ricolin> need more discuss on this topic?
08:16:06 <ramishra> AFAIK, there is no way to disable a specific test
08:16:35 <ramishra> so out best option is to disable neutron tests if we want rather than making the job non-voting
08:16:36 <stevebaker> there must be, we'll be using it extensively when tempest runs our in tree tests
08:17:55 <ramishra> stevebaker: you mean disabling specific test in devstack-gate?
08:18:21 <stevebaker> ramishra: I mean specifying which tests tempest should run
08:19:06 <skraynev> +1 for stevebaker's suggestion
08:19:47 <ramishra> stevebaker: job specific? I don't know how to do it.
08:19:49 <ricolin> Is it make sense to seperate into two gate? Heat tempest gate (voting) and other(non-voting)?
08:20:25 <stevebaker> why have the other at all?
08:20:52 <skraynev> ricolin: more jobs more time for execution ;)
08:21:28 <stevebaker> ramishra: there must be something in the project config for that job which allows specifying what tests to run
08:21:35 <ricolin> Then we can really choose just run HEAT tempest, like stevebaler suggest
08:23:49 <skraynev> ramishra: I see, that in project-config we have such line
08:23:59 <skraynev> export DEVSTACK_GATE_TEMPEST_REGEX="orchestration"
08:24:07 <skraynev> for apache job...
08:24:18 <skraynev> may be we may do the same for other?
08:25:36 <skraynev> ramishra: hm.. and it really uses only heat related tests http://logs.openstack.org/97/317597/1/check/gate-tempest-dsvm-heat-apache/7a15650/console.html
08:26:02 <stevebaker> bingo
08:26:12 <skraynev> let's use it for grenade
08:26:26 <ricolin> :)
08:26:28 <stevebaker> and it should be possible to set OVERRIDE_ENABLED_SERVICES to a much smaller list of services
08:27:26 <ricolin> #topic Spec-lite review: https://bugs.launchpad.net/heat/+bug/1582837
08:27:28 <openstack> Launchpad bug 1582837 in heat "Add resource IDs as an attribute on ResourceGroup" [Undecided,New] - Assigned to Jay Dobies (jdob)
08:28:25 <ricolin> What about this one?
08:29:29 <shardy> Don't we already have a refs attribute that does this?
08:29:35 * shardy looks at the bug
08:29:51 <stevebaker> shardy: the description says the refs attribute is a list not a map
08:30:26 <shardy> stevebaker: shouldn't we just make SoftwareDeploymentGroup work with a list?
08:30:31 <shardy> then it'll also work with ASG IIRC
08:31:15 <stevebaker> there is a reason it needs maps - I think they key is used as the resource name inside the group
08:31:40 <shardy> stevebaker: We could have it also accept a list, e.g via a different property, and just increment using the index as the resource name?
08:32:29 <shardy> that would also make it much easier if you want to join multiple groups of servers into one big SoftwareDeploymentGroup for "allnodes" type actions
08:32:42 <shardy> vs map_merging a bunch of conflicting keys
08:32:43 <stevebaker> shardy: we would end up with deployment group members having different indexes/names to their corresponding resource group members - that would be hella confusing
08:33:03 <stevebaker> shardy: having a name->name mapping makes the association more obvious
08:33:15 <shardy> Hmm, maybe
08:33:28 <shardy> then we need to make repeat capable of generating a map I guess
08:33:40 <shardy> so we can generate a merged map for multiple ResourceGroups
08:33:55 <shardy> {Controller0: <id>, Compute0: <id>} etc
08:36:00 <shardy> +1 for jdob's spec-lite then I guess
08:36:19 <shardy> with a request for enabling map_merge/repeat to join the resulting maps for multiple resource groups
08:36:21 <stevebaker> he may need to explore the consequences a bit more
08:37:19 <shardy> If we do this, we should add the same attribute to ASG I think
08:37:27 <stevebaker> shardy: +1
08:43:27 <stevebaker> shall we move on to general biz?
08:43:48 <ricolin> #topic Open discussion
08:43:52 <ricolin> d
08:44:21 <ricolin> sorry for that, not aware that I'm off line
08:45:48 <ricolin> Could someone review on https://review.openstack.org/#/c/261929/
08:45:58 <KanagarajM> stevebaker, nova_instance -> physcail_resource_id, splitted into two https://review.openstack.org/110557 after your comment. kindly have a look.
08:46:18 <stevebaker> I've started a couple of performance improvement series 1. https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1578851
08:46:18 <stevebaker> 2. https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1578854
08:46:26 <stevebaker> KanagarajM: ok, thanks
08:48:03 <KanagarajM> stevebaker, for other one schema change, we need to decide on.
08:48:15 <shardy_> I had a question re heatclient and event --follow on-failure behavior
08:48:38 <shardy_> I added https://review.openstack.org/#/c/315476/ recently which includes the deployment ID in the event reason
08:49:03 <shardy_> I'm wondering if adding an option to show the resource associated with a failed resource/event when in --follow mode would be a generally useful thing
08:49:26 <shardy_> my main requirement is doing a deployment-show when a deployment resource fails, but we could extend it to be more general
08:50:01 <stevebaker> ricolin: there may be some standard exponential backoff logic you can re-use in that change
08:50:04 <shardy_> stevebaker: I know you started looking at this, does it make sense to revive your work, and/or add this to heatclient?
08:50:04 <ramishra> Would appreciate some reviews for https://review.openstack.org/#/c/294023/ and https://review.openstack.org/#/c/316627/
08:51:43 <stevebaker> shardy_: yes, once the failures command exists by itself it would be good to have an event list option to print the same failure format on a resource failure
08:52:03 <ricolin> stevebaker: Sure, althrough during summit, some discussion point to that we can ignore for Exponential backoff
08:52:18 <shardy_> stevebaker: Ok, cool - basically I want it to dump the stderr out every time we have a deployment FAILED
08:52:22 <stevebaker> shardy_: my original aim was for tripleoclient to just run the failures command on stack failure
08:52:39 <shardy_> stevebaker: yeah, we can do that, I was just thinking it's a more generally useful thing
08:52:54 <stevebaker> shardy_: this does that already in its own command https://review.openstack.org/#/c/271114/
08:53:04 <stevebaker> oh, wait, wrong client
08:53:16 <stevebaker> shardy_: https://review.openstack.org/#/c/280963/
08:54:03 <shardy_> stevebaker: thanks, will check it out - OK if I rebase it so I can test?
08:54:11 <stevebaker> sure thing
08:55:10 <skraynev> guys, regarding decision on summit https://review.openstack.org/#/c/316617/
08:55:26 <skraynev> make rally job periodical
08:55:45 <stevebaker> skraynev: how do we see the results of a periodic job?
08:57:26 <ricolin> using a heat patch to point to a gate job patch(add rally)?
08:58:16 <skraynev> stevebaker: umm.. I forgot to find this info
08:58:18 <skraynev> wait a sec
08:59:16 <skraynev> http://logs.openstack.org/periodic/
08:59:20 <skraynev> #link http://logs.openstack.org/periodic/
08:59:29 <stevebaker> oo, shiny
08:59:37 <skraynev> looks like this link should work ^
09:00:46 <stevebaker> times up
09:00:47 <ricolin> time's up
09:00:48 <ricolin> #endmeeting