20:01:05 #startmeeting heat 20:01:06 Meeting started Wed Feb 20 20:01:05 2013 UTC. The chair is sdake_z. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:09 The meeting name has been set to 'heat' 20:01:25 hidey ho - rollcall pls 20:01:43 o/ 20:01:43 _o/ 20:01:44 |o 20:01:44 hi 20:01:45 o/ 20:01:54 _\o/_ 20:02:01 stevebaker: semaphore? 20:02:19 ~o~ 20:02:21 Wuthering Heights by Semaphore.. a classic. :) 20:02:27 o/ 20:02:49 #topic graduation 20:02:54 so grats folks 20:03:06 11 months all in we were successful :) 20:03:10 woot! That's awesome 20:03:12 * stevebaker shoots silly-string 20:03:23 very nice work guys 20:03:36 * SpamapS mourns poor old Mr Silly-string.. why'd we have to shoot him? ;) 20:03:39 very cool 20:03:59 not to be debbie downer but i expect the project will change a bit ass we add more contributors 20:04:03 me too here 20:04:11 hi angus welcome to the party ;) 20:04:35 #topic g3 rc1 bugs 20:04:50 sdake_z: downer? I think its going to change only in that it will get more awesome. :) 20:05:04 yup hope so ;) 20:05:10 better then decline ;) 20:05:20 https://launchpad.net/heat/+milestone/grizzly-rc1 20:05:28 better than most of the redhat started projects I've been on :) 20:05:36 ok we got 14 bugs 20:05:49 slower blame the devs ;) 20:06:02 we have 2 weeks to fix these bugs 20:06:25 I feel like https://bugs.launchpad.net/bugs/1105806 needs a bit of careful handling. If we can fix that in a way that sets up Havana to eliminate the use of /var/lib/cloud/data that would be ideal. 20:06:26 Launchpad bug 1105806 in heat "/var/lib/cloud belongs to cloud-init, heat should not write files there" [Medium,Triaged] 20:06:27 1 a day 20:06:31 rather then go through all of them i'd like to just talk about the unassigned ones 20:07:04 and get someone assigned 20:07:06 or remove them 20:07:21 #link https://bugs.launchpad.net/bugs/1105806 20:07:40 i can take this one 20:07:50 ok 20:07:51 unless stevebaker has something in the works already 20:08:03 sdake_z can't we just priotise them 20:08:09 and work from the top 20:08:12 nope, but at lease I am familiar with the area now 20:08:40 they are priortized i believe 20:08:59 ok, job done then? 20:09:21 woo! party time ;) 20:09:32 there are only two other unasssigned bugs 20:09:45 #link https://bugs.launchpad.net/bugs/1072938 20:09:48 Launchpad bug 1072938 in heat/grizzly "nosetests -a does not return error if credentials not loaded on functional tests" [Low,Triaged] 20:10:25 may be easier to fix, but how much do we care if we are going to testr eventually? 20:10:38 * stevebaker started playing with testr yesterday 20:11:15 well g is one release - should either fix bugs or say invalid 20:11:21 what we do in the future is not relevant ;) 20:11:36 fair enough 20:11:36 IMO, for an RC, low bugs are not really valid. 20:11:45 I think drop from g 20:11:45 I'd like to know if moving to testr is considered a "feature" for feature freeze 20:11:52 unless people are sitting around twiddling thumbs 20:11:57 is nose the cause of the issue? 20:12:20 stevebaker: testr is enough of a different experience that I'd delay it to havana as well. 20:12:32 no big changes please :) 20:12:34 ok 20:12:46 the main reason to love testr is parallelization, and right now, nose takes what, 10s to run? 20:12:56 what about unittest -> testtools? 20:13:06 the other reasons are to help iterate and make tests faster by tracking their run times... 20:13:06 when we did it with nova we dove into the deep end during a not so busy period giving us time to work out issues that cropped up 20:13:24 stevebaker: unittest to testtools should be safe 20:13:27 lets not change the test infra right before a release :) 20:13:40 stevebaker: I'd just let new tests switch to testtools as a need is identified. testtools just makes it easier to write more clear/concise tests.. and it builds on top of unittest 20:13:42 +1 20:13:49 pff ;) 20:14:03 stevebaker - fearless or reckless ;) 20:14:21 jpeeler you might taking that bug 20:14:27 might/mind 20:14:41 sure 20:15:20 #link https://bugs.launchpad.net/bugs/1072949 20:15:22 Launchpad bug 1072949 in heat/grizzly "Reset DB migrations" [Low,Triaged] 20:15:35 this will be our last opportunity 20:15:43 I guess we need to decide if we want to pull the trigger on this one 20:16:24 any debate? 20:16:28 is it really a breaking change? nova did something similar 20:16:43 they squashed tho right? 20:16:45 +1 for doing it now. I doubt it will be so simple after G 20:16:53 sdake_z: yes 20:16:58 ya if we dont do it now we wont ever do it ;) 20:17:07 +1 for doing it now 20:17:10 it will break existing users 20:17:20 do it quick 20:17:25 +1 20:17:37 so we have 10 days to find any issues 20:17:37 ok - probably should reprioritize to critical then 20:17:39 +1 20:18:06 zaneb you mind taking this one 20:18:07 Probably worth an email to openstack@ ... I doubt Heat has "production" users, but it may be disruptive to those in full scale testing. 20:18:20 sure, can do 20:18:23 thx 20:18:59 with G, technically Heat will still be an incubated component right? Like, its not official until H? 20:19:02 anyone having trouble with reviews of bugs? 20:19:34 you mean code reviews? 20:19:40 ya 20:19:43 any stuck 20:20:14 spamaps to be integrated in havana 20:20:35 Voted on "Approve graduation of Heat (to be integrated in common Havana release)?" yes (10) abstain (1) no (1) 20:21:24 #topic open items 20:21:36 2 weeks for bug fixes and finding 20:21:42 then 3 weeks to fix any critical/high bugs 20:22:01 during that 3 weeks we can start cleaning up the bps for havana and having a look at them 20:22:24 would performance bugs count for this current 2 weeks? 20:22:29 sounds good 20:22:37 define performance bug 20:22:50 Well I plan to spin up a few racks of servers w/ heat + nova baremetal 20:23:03 so scale +1 20:23:12 I know its going to take 48*single boot time...but it should be able to go a lot faster than that. 20:23:27 unless the fix is major architecture rewrite, I say go for it 20:23:36 I figure for low impact low hanging fruit, would be nice to get those in now. 20:23:37 spamaps it should be multithreaded 20:23:40 otherwise blueprint 20:23:56 should take single boot time + 400usec for api calls per node 20:24:15 sdake_z don't need to be threaded 20:24:26 if you see somehting specifc - file a bug ;) 20:24:31 sdake_z: well the single boot time is like, 10,000,000 usec .. so.. the 400 didn't seem worth mentioning :) 20:24:36 hold on, we only wait for nova to create the server, not to boot it 20:24:46 just shouldn't block waiting for active 20:24:51 each stack create is a separate operation 20:24:51 it has to go "ACTIVE" 20:25:00 just to get the instance id 20:25:00 with a separate thread 20:25:03 I said "single boot" I guess I mean "single create" 20:25:21 anyway, just wanted to make sure thats a problem people will be open to tackling now if I can find a low impact way to do it 20:25:24 (which I can... I think) 20:25:40 you mean multipel vms in one template? 20:25:57 patrick would love this too 20:26:01 right we don't have o block waiting for active, we don't need to block until we actually need something from the instance info. 20:26:18 ok i thought you meant 48 separate api calls 20:26:22 no, one stack 20:26:27 48 machines 20:26:41 (40 or so are in a single instance group) 20:26:42 SpamapS: are you using an autoscaling group? 20:26:47 ^^ aye 20:26:49 SpamapS: Error: "^" is not a valid command. 20:27:15 ok, that should be fixable in a not-too-horrible way I would imagine 20:27:38 also there is the nova.boot(mincount) optioin 20:27:52 so nova creates the instances for you 20:27:56 yeah, lazy load of details... lots of things we can do without tackling the multiple threads issue 20:27:56 blocking on dependency execution rather then parent creation seems easy enough 20:28:18 lets not implement it in the meeting, just getting the greenlight is good enough :) 20:28:29 wfm - 10 days after that lockdown ;) 20:29:18 blueprint review? 20:29:25 2 weeks 20:29:26 I know they're all "done" 20:29:35 oh you mean existing ones 20:29:39 ya w eshould be set there 20:29:49 did anything slip through the cracks at the end? 20:29:59 ya shardy put some code in 20:30:04 that may need a review 20:30:12 the schedule slipped a day 20:30:39 https://blueprints.launchpad.net/heat/+spec/update-rollback ? 20:32:25 * SpamapS has a conflicting appointment and must bow out now 20:32:32 ok blueprint looks good 20:32:35 anything else? 20:33:06 one last thing.. is everyone ok with uvirtbot joining #heat and posting messages whenever there is a New bug reported on launchpad? 20:33:17 yes please 20:33:19 yes 20:33:20 please 20:33:42 ok, I've asked soren to join it to the channel.. the new bug tracking will take a couple of days 20:33:51 * SpamapS disappears 20:33:52 nice 20:33:54 thanks! 20:33:56 ok anything else? 20:34:01 no 20:34:06 #endmeeting