20:00:04 <stevebaker> #startmeeting heat
20:00:05 <openstack> Meeting started Wed Aug 12 20:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:09 <stevebaker> #topic rollcal
20:00:09 <openstack> The meeting name has been set to 'heat'
20:00:16 <skraynev_> o/
20:00:19 <stevebaker> hi all
20:00:19 <jdandrea> o/
20:00:24 <jasond> o/
20:00:26 <prazumovsky> o/
20:01:02 <tspatzier> hi all
20:01:19 <stevebaker> #topic adding items to the agenda
20:01:30 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-08-12_2000_UTC.29
20:01:38 <stevebaker> its a short one currently
20:03:07 <stevebaker> ok, it might be a short meeting :)
20:03:19 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
20:03:22 <pas-ha> o/
20:03:54 <stevebaker> I think all the convergence and ASG/RG peeps are asleep
20:04:05 <prazumovsky> I think, deprecation can be erased from list of reviews, it's merged
20:05:05 <stevebaker> I would really appreciate reviews on this to fix the deployment race bug https://review.openstack.org/#/c/206256/ Use atomic_key for deployment metadata updates
20:05:32 <skraynev_> prazumovsky: just update etherpad then
20:05:38 <skraynev_> please :)
20:05:59 <prazumovsky> skraynev_: done
20:06:54 <stevebaker> ooo, has refactor-asg been merged!?
20:07:12 <pas-ha> stevebaker, not completely yet AFAIK
20:07:28 <stevebaker> ah, the link is wrong
20:08:46 <skraynev_> stevebaker: just a first patch
20:09:02 <skraynev_> I wanted to start land this code...
20:09:28 <stevebaker> as for heatclient, polling might be ready to land https://review.openstack.org/#/c/188889/ and the first osc command could really use some reviewing https://review.openstack.org/#/c/195867/
20:09:37 <skraynev_> but was confused by separate support of ASG and RG.. so hold it
20:11:03 <stevebaker> ok, lets move on
20:11:07 <stevebaker> #topic Using trusts for re-authentication during one long request (skraynev)
20:11:31 <skraynev_> unfortunately shardy is on vacation, so I wanted to ask it on meeting :)
20:11:57 <skraynev_> looks like we have issue with re-authentication during one long time request
20:12:38 <skraynev_> e.g. when token lifetime is 30 min and create takes more then 40 minutes - you will get error
20:12:41 <stevebaker> skraynev_: we're still recommending the workaround of setting the token timeout to the maximum length of the operation :/
20:13:26 <skraynev_> stevebaker: yes. pas-ha remaindered me about it
20:13:40 <therve> skraynev, I think it's doable, nobody took the time to actually tackle the issue
20:13:50 <therve> I'm sure we've talked about it in the past
20:14:11 <stevebaker> but yeah, likely shardy is the one to ask about what needs to happen to use trusts for this. I think previously there were keystone blockers preventing it
20:14:23 <therve> https://bugs.launchpad.net/heat/+bug/1306294
20:14:23 <openstack> Launchpad bug 1306294 in tripleo "Heat fails to re-authenticate when faced with authentication failure during stack operations" [High,In progress]
20:14:24 <uvirtbot> Launchpad bug 1306294 in tripleo "Heat fails to re-authenticate when faced with authentication failure during stack operations" [High,In progress]
20:14:25 <uvirtbot> Launchpad bug 1306294 in tripleo "Heat fails to re-authenticate when faced with authentication failure during stack operations" [High,In progress] https://launchpad.net/bugs/1306294
20:14:51 <jdandrea> So nice the bots posted it thrice.
20:15:08 <shprotby> Bot attack!
20:15:14 <skraynev_> therve : yes. I meant this one (did not check bugs :) )
20:15:47 <stevebaker> pas-ha: do you know how much is left on https://bugs.launchpad.net/heat/+bug/1393268 ?
20:15:47 <openstack> Launchpad bug 1393268 in heat "cleanup scheduler tasks in resources" [High,In progress] - Assigned to Pavlo Shchelokovskyy (pshchelo)
20:15:47 <uvirtbot> Launchpad bug 1393268 in heat "cleanup scheduler tasks in resources" [High,In progress]
20:15:48 <uvirtbot> Launchpad bug 1393268 in heat "cleanup scheduler tasks in resources" [High,In progress] https://launchpad.net/bugs/1393268
20:16:11 <pas-ha> server updates (last of servers) are on review
20:16:32 <stevebaker> pas-ha: then that is it?
20:16:33 <therve> \o/
20:16:38 <pas-ha> some more icky places in rackspace resources, might ping randall and jason for them
20:17:11 <pas-ha> and then the very (for me) strange places in stackresource and its children
20:17:35 <pas-ha> not even sure if they have to be fixed in the first place though...
20:17:46 <skraynev_> therve: will read. thx. it's more useful, than I expected :) need to read pedantically
20:18:05 <stevebaker> we should raise a lower-priority bug for the rackspace ones
20:18:28 <pas-ha> ok, will do, and take a closer look into the stackresource
20:18:28 <stevebaker> possibly we should raise a bug per remaining resource so they can be tracked
20:19:07 <skraynev_> therve, stevebaker: do you know when shardy be here? on the next week ?
20:19:07 <stevebaker> pas-ha: any chance you could raise a bug per resource? and we can close that one when the current server changes land
20:19:25 <pas-ha> I could, no problem
20:19:56 <therve> skraynev, No idea no
20:20:07 <stevebaker> skraynev_: he is actually in Dublin for work, as is zaneb. So you can always email him
20:20:44 <skraynev_> stevebaker:  cool. thank you
20:20:59 <pas-ha> in the end I kind of liked what I've ended doing in serverupdateprogress task object, might unite all? most? other progress tasks into it..
20:21:40 <stevebaker> pas-ha: do you mean this? https://review.openstack.org/#/c/204248/
20:21:53 <pas-ha> yes
20:22:32 <stevebaker> I'll check it out
20:23:04 <stevebaker> its been added to https://etherpad.openstack.org/p/heat-reviews too
20:23:06 <pas-ha> although a kind of "big" change is that now some parts of "compute" client plugin API is required
20:23:15 <pas-ha> thanks
20:24:07 <stevebaker> #topic Open Discussion
20:24:20 <therve> Maybe we should talk about the outage of the day
20:24:27 <therve> https://bugs.launchpad.net/keystone/+bug/1484086
20:24:27 <openstack> Launchpad bug 1484086 in Keystone "ec2tokens authentication is failing during Heat tests" [Undecided,New]
20:24:27 <uvirtbot> Launchpad bug 1484086 in keystone "ec2tokens authentication is failing during Heat tests" [Undecided,New]
20:24:29 <uvirtbot> Launchpad bug 1484086 in keystone "ec2tokens authentication is failing during Heat tests" [Undecided,New] https://launchpad.net/bugs/1484086
20:25:04 <therve> ec2 auth is not working anymore on keystone v2 for stack users
20:25:14 <therve> Not sure if they consider it a regression
20:25:24 <therve> But we may want to push moving to v3
20:25:55 <therve> Ie add https://review.openstack.org/202824 and https://review.openstack.org/206640 to the priority list?
20:26:18 <stevebaker> hmm, can we do something like unset the domain on the credentials we use?
20:26:21 <skraynev_> I had a question about https://review.openstack.org/#/c/212062/ : may we enable skipped tests?
20:26:41 <skraynev_> to make sure, that it works for v3 ?
20:26:58 <therve> skraynev, They are enabled, it's still failing for other reasons
20:27:05 <therve> But I think I know which ones :)
20:27:32 <therve> Still, it's not really the correct solution
20:27:45 <skraynev_> therve: I thought, that it skips them https://review.openstack.org/#/c/211983/ ?
20:28:05 <therve> skraynev, Yeah but my patch is based on a previous commit
20:28:17 <skraynev_> therve: oh. got it.
20:28:28 <skraynev_> no more questions :)
20:28:35 <stevebaker> therve: if existing stacks are going to break on kilo->liberty upgrade then I would insist that it is a regression
20:29:08 <therve> stevebaker, Possibly not if you change the heat configuration during the upgrade
20:30:30 <stevebaker> therve: so the issue is that we are creating stack users in the heat domain, then signing ec2 urls with those credentials, which fails ec2token auth because domains are enforced in v2 now?
20:30:56 <therve> stevebaker, You can't use a domain other than default in v2, yeah
20:31:20 <therve> https://review.openstack.org/#/c/208069/
20:31:57 <pas-ha> I've asked them to wait with backporting it to kilo for now
20:32:21 <therve> pas-ha, Thanks, good idea
20:32:58 <stevebaker> ok, sounds like we should move to v3 asap
20:33:31 <stevebaker> is there a git commit comment flag for adding to release notes?
20:33:46 <stevebaker> DocImpact might have to do
20:34:08 <therve> Yeah
20:34:12 <pas-ha> UpgradeImpact too
20:34:15 <skraynev_> The UpgradeImpact line contains the string UpgradeImpact and a comment about why the change impacts upgrades. It is used to indicate that a change has upgrade implications for those doing continuous deployment or N to N+1 upgrades. Also consider updating the 'Upgrade Notes' section in the release notes for the affected project.
20:34:24 <stevebaker> therve: do you know is this the only configuration change required? https://review.openstack.org/#/c/202824
20:34:48 <therve> stevebaker, I believe so
20:34:56 <stevebaker> whoever approves https://review.openstack.org/#/c/202824 can edit the commit message first
20:35:32 <therve> The other change uses the same config value
20:35:43 <stevebaker> I need to do the school run, shall we finish up or should I transfer the chair to .... pas-ha
20:35:59 <pas-ha> chair taken ^)
20:36:08 <stevebaker> #chair pas-ha
20:36:08 <openstack> Current chairs: pas-ha stevebaker
20:36:20 * stevebaker throws the chair and walks out
20:36:45 <skraynev_> stevebaker: good luck :)
20:36:57 <therve> That's all I had personally
20:37:03 <skraynev_> anything else ? :)
20:37:03 * pas-ha cites Gogol
20:37:11 <skraynev_> that's all from me too...
20:37:33 <pas-ha> since we are in open discussion - anything else to discuss?
20:38:06 <skraynev_> throw the chair and let's finish :)
20:38:17 <pas-ha> ok, three..
20:38:23 <pas-ha> two..
20:38:29 <pas-ha> one..
20:38:32 <skraynev_> last chance
20:38:36 <shprotby> Good bye
20:38:41 <pas-ha> thanks everybody :)
20:38:46 <pas-ha> #endmeeting