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