20:00:21 <stevebaker> #startmeeting heat
20:00:22 <openstack> Meeting started Wed Jan 15 20:00:21 2014 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:26 <openstack> The meeting name has been set to 'heat'
20:00:32 <wirehead_> What a hot topic
20:00:36 <stevebaker> #topic rollcall
20:00:45 <shardy> o/
20:00:46 <kbenton> o/
20:00:46 <jasond> o/
20:00:50 <wirehead_> o/
20:00:52 <tspatzier> hi all
20:00:53 <shadower> hey
20:00:55 <SpamapS> o/
20:00:59 <andersonvom> o/
20:01:00 <mspreitz> o/
20:01:06 <jpeeler> hey
20:01:10 * radix here
20:01:29 <randallburt> hi
20:01:39 <pshchelo> o/
20:01:50 <arbylee> hi
20:02:05 <stevebaker> #topic Review last week's actions
20:02:06 <radix> cyli and rockstar might be here soon, they'll be helping out with autoscale
20:02:32 <stevebaker> Its already on the agenda, but if you haven't already then vote on the alt meeting time http://doodle.com/rdrb7gpnb2wydbmg
20:03:00 <stevebaker> #topic Adding items to the agenda
20:03:03 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-1-15.29
20:03:35 <stevebaker> anything to add to the ^?
20:03:57 <radix> something about AS blueprints, maybe
20:04:20 <stevebaker> radix: done
20:04:36 <stevebaker> #topic Inclusive meeting times - slight return
20:04:51 <stevebaker> #link http://doodle.com/rdrb7gpnb2wydbmg
20:04:58 <zaneb> I'm awake
20:07:01 <stevebaker> looking at that poll...
20:07:37 <stevebaker> it looks like its between 1st and 4th options
20:08:04 <SpamapS> \o/ those are the ones I picked I think
20:08:06 <wirehead_> Of course, in the interests of inclusiveness, maybe the worst possible option must be picked instead of the best possible option? </troll>
20:08:10 <zaneb> yep, and they both seem about equally bad
20:08:25 * stevebaker points wirehead_ to the door
20:08:26 <SpamapS> stevebaker: actually
20:08:36 <SpamapS> stevebaker: you may want to include the current meeting times too
20:08:46 <SpamapS> stevebaker: what you really want is the one that has the most people who _cannot_ make the current meeting times.
20:08:49 * stevebaker points SpamapS to the door
20:09:03 * SpamapS shuffles away
20:09:04 <SpamapS> :)
20:09:08 <wirehead_> ;)
20:09:08 <stevebaker> :)
20:10:06 <stevebaker> So how about we go with the first option for the rest of icehouse? The next PTL can renegotiate 2 new times that suite them
20:10:20 <randallburt> stevebaker:  good plan.
20:10:30 <SpamapS> 2nd'd
20:10:42 <stevebaker> which is UTC 00:00:00.000
20:10:42 <zaneb> stevebaker: so, therve and bgorski did not reply, but I assume they are in the same boat as shardy?
20:10:45 <andersonvom> +1
20:10:53 <stevebaker> yes, sucks to be euro
20:11:19 <shardy> zaneb: similar give or take an hour yeah
20:11:48 <stevebaker> but it seems we have many US contributors so should accomdate them
20:13:08 <stevebaker> I think we have enough channels to communicate that missing our european friends once a fortnight won't be too bad
20:13:44 <stevebaker> any objections or alternatives?
20:13:45 <wirehead_> By "European friends" you mean "European friends who do not have a sleeping disorder"?
20:13:49 <wirehead_> :D
20:13:58 <stevebaker> exactly
20:14:41 <wirehead_> *crickets*
20:14:48 * shardy drums fingers
20:14:59 <stevebaker> #agreed Alternate heat meeting time will be Wednesday 22nd UTC 00:00
20:15:04 <radix> woohoo!
20:15:11 <stevebaker> #topic icehouse-2 release status
20:15:15 <radix> (not that I can make it, just happy that it's agreed :)
20:15:20 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-2
20:15:37 <mspreitz> You mean Thursday 0 UTC, right?
20:16:09 <mspreitz> Wednesday 24:00 UTC
20:16:10 <shardy> stevebaker: how long have we got before we branch it?
20:16:12 <stevebaker> I was brutal enough with this list that we can actually use it for i-2 release planning. If I was too brutal then feel free to change something back
20:16:24 <stevebaker> EOD Tuesday the branch will happen
20:16:41 <skraynev_> stevebaker: OMG. 4 am in local time)))
20:16:43 <radix> alrighty
20:16:45 <zaneb> mspreitz: yes, the first one one here http://doodle.com/rdrb7gpnb2wydbmg
20:17:34 <shardy> stevebaker: Ok, cool few days to get stuff reviewed then :)
20:17:37 <stevebaker> if you want to prioritise reviews then doing it by bp/bug priority might be good
20:18:13 <stevebaker> radix: do you think as-lib has a chance of i-2?
20:18:41 <radix> stevebaker: I think it has a chance for at least one patch to get in, but I dunno about all of it
20:18:48 <stevebaker> pshchelo: should cancel-update-stack be Needs Code Review?
20:18:57 <radix> I'm fixing One Weird Unit Test before submitting a patch today
20:19:00 <radix> but it won't be the whole thing
20:19:21 <stevebaker> radix: lets not kick it yet then
20:19:24 <radix> okie
20:19:25 <wirehead_> Learn how a Rackspace software developer solved a Heat problem with One Weird Unit Tests (Sorry if the joke's been made already)
20:19:47 <zaneb> wirehead_: no, but thanks for saying what everyone was thinking ;)
20:19:47 <shardy> stevebaker: FYI I've nearly finished keystone-v3-only, but waiting on getting keystone bug #1259584 merged before I can post the remaining patches
20:19:49 <uvirtbot> Launchpad bug 1259584 in keystone "ec2 signature validation fails with v3 credentials" [Medium,In progress] https://launchpad.net/bugs/1259584
20:19:51 <radix> hehe
20:20:04 <stevebaker> SpamapS: do you think retry-failed-update will get an i-2 push?
20:20:08 <shardy> stevebaker: so that may be possible if I can chase the keystone folks for reviews
20:20:28 <shardy> otherwise will be early i3
20:21:04 <stevebaker> tspatzier: where is schema-code-consolidation at?
20:21:42 <tspatzier> stevebaker: I submitted another patch set today that addresses all issues I discussed with zaneb
20:21:47 <zaneb> stevebaker: it was very close a couple of days ago, and there is a new patch I haven't reviewed yet
20:21:54 <SpamapS> stevebaker: yes it will get a "today" push :)
20:22:06 <zaneb> I will look at it today for sure
20:23:01 <stevebaker> btw there are a bunch of heatclient reviews needed for https://blueprints.launchpad.net/heat/+spec/get-file
20:23:11 <tspatzier> btw: just wanted to update the status of the bp, but got a connect error ...
20:23:40 <stevebaker> any other i-2 updates?
20:24:01 <zaneb> tspatzier: I changed it to "Needs Code Review"
20:24:14 <tspatzier> thanks zaneb
20:24:17 <zaneb> I assume that's what you wanted ;)
20:24:26 <tspatzier> exactly :-)
20:24:41 <stevebaker> #topic i18n log messages
20:25:10 <pshchelo> stevebaker: only the part in client, for the heat part I'm waiting to see how the deletion of inprogress stacks will take shape for multi-engine
20:26:16 <stevebaker> This is a PSA. Apparently OpenStack will support i18n on log messages, so keep this in mind when reviewing any log.info(_('bleargh'))
20:26:30 <randallburt> ugh
20:26:39 <radix> o.O
20:26:59 <stevebaker> One day there may be different translation domains, so these will change to log.info(_LN('snork')) or somesuch
20:27:02 <shardy> stevebaker: wow, even debug logging?
20:27:26 <stevebaker> shardy: that I don't know
20:27:29 <randallburt> its the thought that counts?
20:27:30 <zaneb> stevebaker: what does that mean?
20:27:39 <pshchelo> not being a native English speaker I too think this is excessive
20:27:46 <shadower> yeah
20:27:46 <zaneb> what should I be doing differently while I am keeping it in mind?
20:27:57 <stevebaker> zaneb: it means don't -1 a review just because it has _() in a logging statement
20:28:02 <randallburt> zaneb:  i18n your log messages
20:28:04 <stevebaker> like I did ;)
20:28:12 <zaneb> ok
20:28:21 <zaneb> pretty sure I have never done that ;P
20:28:29 <stevebaker> #topic openstack-heat-templates version tagging
20:28:45 <stevebaker> who added that? sdake?
20:28:59 <jpeeler> i did, by request of sdake
20:29:13 <jpeeler> basically i know we have directories for fedora/debian releases
20:29:48 <jpeeler> but is the idea to have what's in the repo packaged and distributed the same for every version of openstack?
20:29:55 <jpeeler> or will it be versioned
20:29:57 <shardy> which is wrong anyway, because many templates will work on more than one version..
20:30:01 <stevebaker> I think any of those templates should be ported to the latest release and the old on deleted
20:30:08 <stevebaker> old ones
20:30:13 <shardy> (I meant OS versions, the directories)
20:30:53 <stevebaker> shardy: we could never confirm that though
20:31:03 <SpamapS> Is there an opportunity to turn that repository into an integration test suite?
20:31:05 <shardy> stevebaker: one issue we have is we evidently don't have the resources to re-test all example templates for every Fedora release
20:31:29 <SpamapS> if so.. then it should be managed and released as part of icehouse/juno/etc.
20:31:39 <SpamapS> at the very least we should try to validate all of them
20:31:46 <stevebaker> so how about we just support the latest release and make any required fixes when we get the chance. They are just example templates afterall
20:31:48 <shardy> SpamapS: automated testing via gate tests would be ideal, but I'm not sure how realistic that is
20:32:08 <randallburt> SpamapS:  a good idea that. we may have some QE folks doing something kinda like that.
20:32:40 <jpeeler> well my understanding is we'll have to support it for havana and obviously icehouse now
20:32:51 <stevebaker> given that we have different heat releases now, the matrix is exploding
20:32:58 <jpeeler> maybe the havana support is not an upstream requirement
20:33:30 <SpamapS> so my thinking is that we should do whatever we can to make sure they will work with the current release of Heat. And so if they are in the gate, they can get tagged on release day.. and we can manage them confidently as we deprecate things.. people can just use the tagged examples for stable releases.
20:33:44 <SpamapS> sadly, I have no time to do this. :-/
20:33:50 * SpamapS shuts up
20:33:55 <randallburt> SpamapS:  +1 but me either atm ;)
20:34:22 <stevebaker> what we need is a public (glance) template repo which has metadata of known working combinations
20:35:16 <zaneb> I think we're getting a bit off-topic ;)
20:35:27 <stevebaker> lets move on, I don't know the answer
20:35:41 <stevebaker> #topic tempest bug fixing day
20:35:59 <stevebaker> Some of you may have seen this
20:36:01 <stevebaker> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/023859.html
20:37:27 <stevebaker> On Jan 27th some are dedicating a day to looking at gate blocking tempest issues. Heat isn't causing any of these at the moment (hopefully) but I wonder if there is interest in spending a day doing things like:
20:37:42 <stevebaker> - setting up tempest locally and running heat tests
20:37:48 <stevebaker> - writing new heat tests
20:38:06 <skraynev__> stevebaker: do you mean tempest tests?
20:38:06 <stevebaker> - debugging the gate issues with the heat-slow tests
20:38:14 <randallburt> sounds fun ;)
20:38:24 <shardy> stevebaker: +1, sounds like a good plan
20:39:06 <stevebaker> and we can use #heat for helping with issues and diagnosing gate
20:39:10 <shardy> stevebaker: can we get the various tempest tests we'd like to write into either launchpad of an etherpad beforehand, so everybody can see who's doing what wrt new tests?
20:39:18 <skraynev__> stevebaker: does heat-slow job work now? I mean: did you finished related changes for this job?
20:39:40 <stevebaker> skraynev__: it runs but the tests time out
20:40:03 <stevebaker> yes, if you have a new test that you want to write then please raise a Wishlist bug in heat lp
20:40:34 <shardy> stevebaker: and we're tagging them with "tempest" right?
20:40:48 <skraynev__> stevebaker: so, May I ask to review again this https://review.openstack.org/#/c/60078/ ?)
20:41:08 <stevebaker> skraynev__: the cause could be any one of: slow boot in nested virt, neutron connectivity, something else
20:41:15 <stevebaker> shardy: yes, and tag it tempest
20:41:26 <shardy> stevebaker: Ok, thanks
20:42:37 <skraynev__> stevebaker: something else - the best reason))
20:42:42 <stevebaker> skraynev__: I just ran "check experimental" on that, lets see what happens
20:43:10 <stevebaker> #action Jan 27th Heat Tempest Awesome Fun Day
20:43:29 <stevebaker> #topic autoscaling blueprints
20:43:35 <radix> so
20:43:57 <wirehead_> so
20:43:59 <skraynev__> stevebaker: ok ,thanks
20:44:11 <radix> I'm about to change a few of them to live beyond i-3: the AS-API client, and the resources that use it
20:44:28 <radix> Still going to have the in-process as-lib-based resources in this release, though
20:44:57 <stevebaker> ok, that sounds appropriate
20:44:59 <radix> that should alleviate the pressure a bit, while still giving us something useful for the icehouse release :)
20:45:03 <radix> also
20:45:16 <radix> cyli (now here) and rockstar (not available for this meeting) are going to be working with me on it, so hello to them :)
20:45:25 * cyli waves
20:45:38 <zaneb> cyli: o/
20:45:42 <randallburt> o/
20:45:48 <shardy> cyli: welcome! :)
20:45:59 <cyli> thanks!  :D
20:46:14 <radix> that's all from me :)
20:46:18 <skraynev__> cyli: hi)
20:46:24 <shardy> radix: sounds good
20:46:31 <wirehead_> They've been working on the Rackspace Otter side, so they should know the overall AutoScaling problems well. :)
20:46:48 <wirehead_> Bonus points: Now you will be able to say that Heat is where the rockstar developers hack.
20:46:56 <radix> heh heh
20:47:04 <stevebaker> #topic Open Discussion
20:47:22 <kbenton> zaneb: can you chat about this? https://review.openstack.org/#/c/41044/
20:47:51 <zaneb> sure
20:48:02 <zaneb> I haven't had the chance to look at the latest patch yet
20:48:09 <shardy> oh wow, that's been around for a while ;)
20:48:18 <kbenton> the latest just removed the dependency thing that didn't end up helping
20:48:22 <kbenton> otherwise still the same
20:48:42 <zaneb> but suffice to say, this is doing all of the things we talked about _not_ doing at the exorcism session at summit ;)
20:49:10 <kbenton> If it doesn't merge or abandon soon, it will fall under jurisdiction of the historical society. :-)
20:49:36 <zaneb> lol
20:49:39 <kbenton> I don't see any way to fix this connectivity dependency issue though.
20:49:43 <SpamapS> hey whats goign on with stack-convergence ?
20:50:11 <zaneb> so it seems like there's still other issues with modelling existing stuff in Neutron that we haven't specifically identified yet
20:50:33 <zaneb> namely the RouterInterface thing
20:50:54 <zaneb> which should maybe just be a property on the Port?
20:51:16 <zaneb> it doesn't seem to correspond to an actual object in Neutron
20:51:35 <kbenton> Doesn't it correspond with the router port?
20:51:53 <kbenton> er router interface
20:52:28 <zaneb> kbenton: is that something with a uuid that we could reference in the Route?
20:54:20 <zaneb> in the code it does neutron().add_interface_router(router_id, {'port_id': port_id})
20:54:22 <kbenton> zaneb: it is a heat resource. Doesn't that mean it could be referenced?
20:54:24 <radix> SpamapS: hm, I'm curious about that too
20:54:36 <SpamapS> I feel like it isn't going to get done.
20:54:53 <radix> I haven't actually looked at it at all
20:54:57 <stevebaker> zaneb: even if RouterInterface is deprecated now, the dependency workaround will still need to remain until it is deleted. Surely the Route review can continue on that basis
20:54:59 <zaneb> kbenton: no, not really
20:55:10 <SpamapS> Which is fine, but I think stack deployers will have a harder time managing long term stacks without it.
20:55:34 <SpamapS> and I need a related bug fixed (I call it a bug, might be a feature) where we need to be able to select individual members of an instance group for deletion before scale down.
20:55:43 <zaneb> stevebaker: I'm OK with a temporary workaround, but we need completely different properties on the Route IMO
20:56:22 <zaneb> stevebaker: right now it just takes an IP address, and it needs to take the ID of something
20:56:41 <shardy> SpamapS: I was discussing that feature with shadower today, I think we need a BP to track it
20:57:02 <zaneb> if that something is a Port and we need a temporary hack to get the RouterPort into the dependencies, that is OK
20:57:21 <SpamapS> shardy: I linked a bug to stack-convergence
20:57:28 <kbenton> zaneb: it will still need to take the IP as well to address the issues i pointed out in the comments
20:57:48 <zaneb> kbenton: I really don't see that issue as an obstacle
20:57:50 <SpamapS> shardy: without that feature, stateful services simply cannot be managed as a group.
20:57:51 <stevebaker> zaneb: it looks like nexthop could be an IP *or* the UUID of some neutron resource
20:58:24 <kbenton> stevebaker: If it's a UUID, it has to unambiguously translate to an IP address because that's what neutron needs
20:58:29 <zaneb> stevebaker: that's not a long term fix, because just sticking an IP in there will never get the dependencies right
20:59:01 <stevebaker> zaneb: maybe for a start nexthop could be IP only, then later a nexthop_type could be added for specifying different resources
20:59:16 <kbenton> stevebaker: an a port does not unambigously translate to an IP
20:59:20 <kbenton> and*
20:59:21 <stevebaker> then nexthop could be a UUID, not an IP
20:59:36 <zaneb> kbenton: but we know that Neutron is just using the IP address as a key to look something else up. As long as that lookup is unambiguous, I don't care that the IP is ambiguous
20:59:37 <shardy> SpamapS: I think those bugs are a bit different to the as-choose-victim feature, but yeah all related
21:00:10 <kbenton> stevebaker: that's what zaneb was leaning towards but we cannot translate a UUID to an IP in all cases
21:00:16 <shardy> out of time..
21:00:27 <stevebaker> also something to consider, does not having the dependency actually matter in this case? possibly the route can be established before the endpoint exists
21:00:32 <kbenton> stevebaker: there is also the issue of using a device not managed by openstack as a nexthop
21:00:36 <stevebaker> #endmeeting