12:00:17 <shardy> #startmeeting heat
12:00:18 <openstack> Meeting started Wed Apr 15 12:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:21 <openstack> The meeting name has been set to 'heat'
12:00:50 <skraynev> Fuh. Bot works today :)
12:00:50 <shardy> #topic rollcall
12:00:55 <shardy> \o/
12:00:56 <skraynev> o/
12:00:59 <shardy> whoe's around?
12:01:01 <dgonzalez> o/
12:01:04 <ananta> o/
12:01:08 <shardy> who's even..
12:01:21 <ramishra> hi
12:02:08 <pas-ha> o/
12:02:27 <ryansb> \o
12:02:34 <Qiming> hi
12:02:51 <shardy> Ok, hi all, let's get started
12:02:56 <shardy> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:03:06 <shardy> #topic Adding items to the agenda
12:03:14 <shardy> anyone have anything to add?
12:03:54 <shardy> Ok, I'll take that as a no ;)
12:04:05 <shardy> #topic  Any critical bugs (rc2 potential)
12:04:34 <pas-ha> just discovered after ML post - https://bugs.launchpad.net/heat/+bug/1444429
12:04:35 <openstack> Launchpad bug 1444429 in heat "WaitConditionHandle creates stack user without a password" [Undecided,New]
12:04:47 <shardy> So, I checked with ttx, and it's likely we'll have an rc2, but we're still waiting for the bugs we want to backport to be finalized
12:04:54 <zaneb> o/
12:05:12 <pas-ha> not sure how critical is that
12:05:19 <shardy> pas-ha: It's not supposed to have a password, the AWS WaitCondition only has an ec2 keypair
12:05:27 <shardy> I'll take a look after the meeting
12:05:30 <pas-ha> no, thats native one
12:05:55 <shardy> pas-ha: Ok, well definitely one to investigate ;)
12:05:59 <pas-ha> Create_Failed: Resource CREATE failed: BadRequest: Password is not strong
12:05:59 <pas-ha> enough (HTTP 400)
12:06:10 <shardy> #link https://bugs.launchpad.net/heat/+bugs?field.tag=kilo-rc-potential
12:06:45 <zaneb> wow, that's a long list
12:06:46 <shardy> If folks can tag bugs with kilo-rc-potential, it will help track what needs to get backported to proposed/kilo
12:06:51 <pas-ha> shardy, what's the difference between kilo-rc-potential and kilo-backport-potential?
12:07:06 <zaneb> pas-ha: kilo-rc is pre-release
12:07:19 <zaneb> kilo-backport is stable release
12:07:19 <shardy> pas-ha: kilo-rc-potential means it's something we might consider a release blocker
12:07:23 <zaneb> i.e. 2014.1.1
12:07:26 <pas-ha> we already have kilo-backport-potentia
12:07:35 <pas-ha> :)
12:07:35 <shardy> kilo-backport-potential is something we'd consider for a post-release async stable release
12:08:07 <shardy> if we're doing an RC2, we may as well get as many non-risky bugfixes in as we can IMO
12:08:32 <ryansb> +1
12:08:37 <shardy> as zaneb says, that is looking like rather a long list though :)
12:09:52 <skraynev> may be some authors don't know, that their patches are backport potential ?
12:10:22 <shardy> skraynev: it's up to the heat-core folks to set the tag appropriately either when reviewing or when triaging the bug
12:10:49 <shardy> e.g before you +A something, you should think if its a release-worthy fix, and consider tagging the bug referenced from the commit
12:11:05 <skraynev> shardy: yeah, I know, but I told, about patches for review
12:11:42 <skraynev> when it was marked as backport potential and the author of original commit does not know about it and do not do patch to another branch
12:12:35 <shardy> skraynev: Yeah, in that case, it's generally up to the PTL and any other kind folks who are prepared to propose the backports
12:13:12 <shardy> we can't really mandate that authors backport their patches, although it's obviously good if they do :)
12:13:25 <shardy> Ok, does anyone have anything else re rc2?
12:13:41 <skraynev> shardy: :) need gerrit-bot for it
12:13:46 <zaneb> at the risk of making work for myself, I'd say it's the responsibility of the whole core team at a minimum, not just the PTL ;)
12:14:27 <shardy> zaneb: Yeah, I agree, but IME a lot of it falls to the PTL, hopefully that's improved now the role has been rotated quite a bit :)
12:15:08 <skraynev> zaneb: sure. we all can be on this place and nobody don't want to be alone with these responsibilities ;)
12:15:13 <shardy> There are 4 High Triaged bugs on the rc-potential list, it'd be good if folks could either pick those up or deprioritize them
12:15:23 <zaneb> I have +A rights on the stable branches, feel free to add me to reviews :)
12:15:30 <shardy> +1
12:16:29 <shardy> #topic open discussion
12:16:40 <shardy> Could be a quick meeting today ;)
12:16:51 <shardy> anyone have anything they'd like to discuss?
12:16:51 <skraynev> yeah;)
12:17:13 <skraynev> ooops. it was answer on the first message ;)
12:17:22 <shardy> I wanted to point out that events are a terrible interface for user notifications, FWIW
12:17:47 <shardy> I think asalkeld started a thread about it, but I've been trying to consume hooks/breakpoints via events and it's nasty
12:17:57 <zaneb> lol
12:18:14 <shardy> Just thought I'd share that with y'all ;)
12:18:16 <ryansb> shardy: you mean heat events, not "the general term 'events'" right?
12:18:44 <skraynev> ryansb: I think shardy meant first one;)
12:18:47 <shardy> ryansb: Yeah, heat events
12:18:49 * zaneb warms up his zaqar rant
12:19:06 <ryansb> Because the conclusion to that notify-our-users thread was "we like sending events over zaqar as a solution"
12:19:20 <skraynev> zaneb: I'd prefer pluggable mechanism in this case
12:19:30 <skraynev> zaneb: not only zaqar
12:19:42 <shardy> ryansb: I'll take anything which doesn't require 37 API calls and a ton of list mangling on the client side
12:19:43 <zaneb> skraynev: +1. there's no harm in sending it to multiple places
12:20:08 <ryansb> zaneb: I think everyone here has heard the zaqar rant ;)
12:20:09 <shardy> hopefully you'll all take pity on me when I post my heatclient hacks which do that later today and not immediately -2 them ;)
12:20:28 <zaneb> skraynev: although in my broader vision, the zaqar message can be used to trigger a mistral workflow, so it's pluggable by the user :)
12:21:22 <skraynev> zaneb: sounds interesting.
12:21:40 * shardy concludes his event rant
12:22:30 <shardy> Anyone have anything else they'd like to discuss?
12:23:37 <ananta> would like to discuss 1312246
12:23:41 <ananta> bug 1312246
12:23:49 <ryansb> tagging along on the event rant: ceilometer has a spec up for alarming/event notification if folks want to have a peek https://review.openstack.org/#/c/172893/1
12:23:59 <ryansb> <end my topic>
12:24:26 <ananta> wanted to know if it can be made public? https://bugs.launchpad.net/heat-cfntools/+bug/1312246
12:25:02 <zaneb> saw that in my email just now, but haven't read it yet
12:25:40 <shardy> I'm puzzled by what an "attacker" would do in the context of a box they already have root via cloud-init on
12:26:07 <zaneb> wait, I have commented on this before
12:26:42 <ananta> I think its about not setting the setuid properly before running
12:26:51 <ananta> running the command
12:27:14 <zaneb> ananta: no, it's not
12:27:41 <zaneb> but I agree this should be public
12:28:08 <ananta> zaneb: ok
12:28:12 <zaneb> it's up to the template author not to pass untrusted data as an argument there until this bug is fixed
12:28:13 <shardy> Yeah I agree
12:28:24 <zaneb> so they should probably know about it
12:28:44 <shardy> I'd be happy to see it fixed, but it can't be super high priority given that it's not been fixed in a year ;)
12:28:54 <zaneb> whereas I don't think knowing about it makes it significantly easier to exploit
12:29:40 <ananta> zaneb: yes
12:29:42 <ryansb> zaneb: +1
12:30:31 <ananta> shardy: its definitely not high priority
12:31:09 <shardy> ananta: Ok, I've triaged it an assigned medium priority
12:31:19 <ananta> shardy: thanks
12:31:23 <shardy> if you're prepared to help fix it, that would be great
12:31:59 <ananta> shardy: I will investigate and see
12:32:04 <ananta> I don't know right now
12:32:07 <shardy> ananta: thanks
12:32:18 <shardy> Anyone have anything else, or shall we wrap things up early?
12:33:11 <zaneb> just changed it to "public security"
12:33:24 <shardy> zaneb: thanks
12:33:47 <shardy> Ok, if there's nothing else, I'll endmeeting, thanks everyone!
12:33:53 <shardy> #endmeeting