20:00:19 <stevebaker> #startmeeting heat
20:00:20 <openstack> Meeting started Wed Jan  8 20:00:19 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:24 <openstack> The meeting name has been set to 'heat'
20:00:26 <notmyname> so le'ts keep working on it as a group as part of openstack, not against everyone else
20:00:36 <stevebaker> hi all
20:00:40 <stevebaker> #topic rollcall
20:00:43 <shardy> o/
20:00:44 <andersonvom> o/
20:00:44 <asalkeld> o/
20:00:45 <jasond> o/
20:00:46 <zaneb> \o
20:00:53 <spzala> hi
20:00:55 <jpeeler> o/
20:01:14 <tspatzier> hi
20:01:27 <m4dcoder> o/
20:02:28 <stevebaker> the only action last week was the alt meeting time poll, that is on the agenda anyway
20:02:47 <stevebaker> #topic Adding items to the agenda
20:02:54 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-1-8.29
20:03:33 <shardy> stevebaker: I was wondering, if radix is around, if he can give us a status update of where the autoscaling stuff is headed?
20:03:47 <radix> oh, hello
20:03:53 <shardy> hey radix
20:03:53 <radix> thanks for the namecheck, I forgot about the meeting time again :P
20:04:07 <stevebaker> shardy: I'll add it
20:04:31 <stevebaker> alrighty
20:04:43 <stevebaker> #topic Inclusive meeting times - redux
20:05:13 <stevebaker> http://doodle.com/rdrb7gpnb2wydbmgimvtgws7/admin#table
20:05:54 <stevebaker> so europe gets a raw deal out of all the meeting times in this scenario
20:06:08 <stevebaker> #link http://doodle.com/rdrb7gpnb2wydbmgimvtgws7/admin#table
20:06:11 <shardy> It's unfortunate it's going to split the group so much
20:06:44 <asalkeld> no europe
20:06:59 <stevebaker> so the first thing is to establish what these meetings are for. Any important decisions should happen on the mailing list, so we don't need everyone to attend every meeting
20:08:36 <stevebaker> so another option is to have the alt time be bad for west-coast US, and good for APAC, russia and europe
20:09:25 <stevebaker> for some measure of "good"
20:09:31 <zaneb> stevebaker: what sort of time are we talking?
20:11:00 <randallburt> sorry I'm late
20:11:32 <stevebaker> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140115&p1=264&p2=136&p3=33&p4=166&p5=179
20:12:10 <zaneb> ooh, fancy
20:12:41 <stevebaker> it would have to be something like this, so all of US would be out http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=1&day=15&hour=8&min=0&sec=0&p1=264&p2=136&p3=33&p4=166&p5=179
20:12:43 <sdake> define bad for west coast
20:13:14 <sdake> we have 4 core in US iirc
20:13:31 <sdake> losing half the core team half the time doesnt' seem optimal :)
20:13:33 <zaneb> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140118&p1=264&p2=136&p3=33&p4=166&p5=179&p6=137
20:13:39 <zaneb> with LA added ^
20:13:44 <andersonvom> it seems like something around 11pm EST would work well for the other timezones
20:14:08 <zaneb> :(
20:14:09 <stevebaker> there are 6 non-US core
20:15:36 <stevebaker> so the purpose of the meeting is for anyone to raise concerns with enough cores to get some kind of answer
20:16:03 <stevebaker> and for the PTL to find out how specific things are going
20:16:57 <sdake> 11pm est looks like the best slot although it excludes shardy and perhaps some of our east coast us
20:17:51 <stevebaker> shardy: 7am? you'll be awake won't you ;) ?
20:18:05 <shardy> stevebaker: Yeah, that's do-able :)
20:18:45 <stevebaker> zaneb, jpeeler, you would offically get a pass
20:18:57 <asalkeld> ha: someone else that has to get up for 7am meeting :-)
20:19:00 <zaneb> yeah 11pm EST is too late for east coast. It'll be midnight in the summer too.
20:19:02 <shardy> stevebaker: are we still talking about the wednesday?
20:19:21 <stevebaker> shardy: yes
20:19:41 <zaneb> is the proposal to alternate among 3 meeting times, or just 2?
20:19:59 <shardy> 7am Thursday would be better for me as I'll have to leave early on a wednesday for childcare-run
20:20:00 <stevebaker> just 2 for now, lets keep it simple
20:20:12 <sdake> 2 != simple :)
20:20:22 <zaneb> lol
20:21:01 <sdake> but unfortunately necessary
20:21:04 <stevebaker> shardy: thursday would sometimes clash with my python user group, but that might not matter
20:21:19 <shardy> stevebaker: I can do any days except tues/wed
20:21:36 <shardy> although if we stick with wed I can probably attend some of the meeting
20:21:51 <radix> hmm, maybe 3 meeting swould allow most people to attend 2/3rds of the meetings, whereas 2 meetings would only allow 50%?
20:22:00 <radix> but, yeah, that's complex :)
20:22:16 <stevebaker> so I propose this time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=1&day=16&hour=7&min=0&sec=0&p1=264&p2=136&p3=33&p4=166&p5=179&p6=137
20:23:15 <zaneb> stevebaker: that excludes all of US
20:23:38 <stevebaker> sdake never sleeps
20:23:57 <zaneb> fair point, but he is a special case ;)
20:24:23 <sdake> 11pm is generally past my bedtime, but I can try in a half-hearted fashion to make it :)
20:24:30 <asalkeld> and only 5pm for me, cool
20:24:32 <tspatzier> zaneb, bad move from Munich to NC ;-)
20:24:53 <stevebaker> its a conspiracy!
20:25:02 <zaneb> tspatzier: it seemed like such a good idea at the time
20:25:45 <stevebaker> excluding US sucks, but I think it is worth trying for a bit
20:26:15 <zaneb> stevebaker: can I suggest another poll with all of the options?
20:26:17 <stevebaker> it might mean we do more on the mailing list, which we seem to be anyway
20:26:19 <andersonvom> how many cores would be available at both times this way?
20:26:32 <sdake> there are 4 core in the US IIRC
20:26:37 <stevebaker> so how about we keep the current time for next week and I'll raise another poll?
20:26:45 <sdake> stevebaker +1
20:27:02 <zaneb> sdake: at least 5 by my count
20:27:04 <stevebaker> including the most popular option from the 1st poll
20:27:11 <sdake> 5 may be right
20:27:34 <zaneb> and we have 10? 11 total?
20:27:36 <sdake> imo we want to exclude as few core as possible - even if means non-core gets the shaft
20:27:54 <sdake> if non-core gets the shaft, they can wake up at odd hours if they want to participate :)
20:28:10 <stevebaker> #action stevebaker to raise another doodle poll with a range of alternative times
20:28:32 <stevebaker> ok, lets move on
20:28:38 <stevebaker> #topic icehouse-2 blueprints
20:28:45 <stevebaker> i-2 is two weeks away!
20:29:17 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-2
20:29:45 <asalkeld> we need more reviews, lots of reviews hanging
20:30:09 <sdake> i stopped reviewing over the christmas break - will start up again
20:30:16 <sdake> asalkeld I think alot of folks were in that same boat
20:30:17 <stevebaker> https://blueprints.launchpad.net/heat/+spec/parameter-nested-schema has no asignee, I'll have to kick it unless it gets one soon. asalkeld? tspatzier?
20:30:44 <asalkeld> stevebaker, kick it for now
20:30:46 <zaneb> stevebaker: I believe therve was thinking of looking at it
20:30:57 <asalkeld> (ok, nice)
20:31:01 <zaneb> but I think it depends on stuff that tspatzier is working on
20:31:17 <zaneb> tspatzier: can you raise a blueprint for that so we can set up the dependencies?
20:31:46 <stevebaker> I'll assign it to therve. he can unassign
20:31:47 <randallburt> zaneb, stevebaker I think he was talking about new constraint types after merging param and property schema, so this may be tangental
20:31:57 <tspatzier> stevebaker, I am currently working on the 2nd part of unifying the schema code. I plan to submit a WIP patch tomorrow to get some feedback.
20:32:24 <tspatzier> once that is done, I think this BP will be easier to solve
20:33:03 <zaneb> ++
20:33:06 <stevebaker> likewise, any blueprint with Delivery: Not Started will probably just be kicked to i-3 in 6 days time, so please update anything you're working on
20:33:10 <tspatzier> zaneb, I can open a BP for the work I am currently doing, so we can track the dependency
20:33:17 <zaneb> tspatzier: thanks :)
20:33:49 <tspatzier> zaneb, will I be able to set the dependency? Or will one of the core members have to do it?
20:34:11 <zaneb> tspatzier: not sure, but if you can't ping me and I will do it
20:34:11 <stevebaker> you could try, or ping us
20:34:21 <tspatzier> ok, will do
20:34:25 <sdake> tspatzier I think you have to be in the "drivers" group to set deps but not certain
20:35:03 <stevebaker> anything else on i-2? If you don't think you're blueprint will be ready in time feel free to move it to i-3 now
20:36:11 <stevebaker> #topic tempest slow tests
20:37:00 <stevebaker> so any change in tempest can now be run against the heat-slow tempest job if you comment with "check experimental" https://review.openstack.org/#/c/63260/
20:37:39 <shardy> stevebaker: any idea roughly how long the slow job takes?
20:37:46 <stevebaker> however simple tests with an instance and a waitcondition are currently failing http://logs.openstack.org/60/63260/1/experimental/gate-tempest-dsvm-neutron-heat-slow/1d62626/testr_results.html.gz
20:38:32 <stevebaker> shardy: 27 minutes, but tests are timing out. Not sure if timeout is due to slowness or connectivity fail
20:39:10 <sdake> heat has a 10 minute wait condition limit by default IIRC, and when I ran heat in a vm, it took 27 minutes to boot a vm, so that might be the problem
20:39:10 <stevebaker> if anybody has the time and ability to debug why those tests are failing in gating that would be a huge help
20:40:02 <stevebaker> sdake: yes, it may just need cranking up the timeouts, or it may be a neutron connectivity issue
20:40:19 <zaneb> stevebaker: what kind of environment are these tests running in? not bare-metal, I assume?
20:40:29 <radix> I wonder if nested hardware virtualization is turned on for those VMs.
20:40:43 <stevebaker> zaneb: all-in-one devstack on hpcloud or rax
20:41:01 <stevebaker> radix: I doubt it
20:41:05 <radix> :(
20:41:14 <radix> that would make a huge difference
20:41:21 <zaneb> yeah
20:41:23 <stevebaker> radix: gate has enough problems without enabling that ;)
20:41:27 <MikeSpreitzer> 27 minutes?  I am doing nested virtualization, and it takes nowhere near as long.
20:42:05 <stevebaker> so ping me if you're keen to have a crack
20:42:18 <stevebaker> #topic Software config POC
20:42:54 <stevebaker> I've split up the blueprint a bit, have a look at the dependencies https://blueprints.launchpad.net/heat/+spec/hot-software-config
20:43:28 <shardy> stevebaker: nanjj was asking earlier in #heat if you wanted some help with the software-config tasks
20:44:19 <stevebaker> tspatzier: I wonder if nanjj could take on https://blueprints.launchpad.net/heat/+spec/hot-software-config-rest ? It would mean adding full test coverage to these existing changes https://review.openstack.org/#/q/topic:bp/hot-software-config-rest,n,z
20:44:32 <stevebaker> and this https://review.openstack.org/#/c/58885/
20:44:54 <tspatzier> stevebaker, I can talk to nanjj tomorrow morning when he is up
20:45:05 <stevebaker> tspatzier: ok, thanks
20:45:28 <tspatzier> stevebaker, I also read you ML post from Dec 14th (yeah, my vacation was looong). Are the next steps still valid?
20:45:53 <stevebaker> I'm working on this at the moment, so I hope nobody has any issue with an inclusion intrinisic function https://blueprints.launchpad.net/heat/+spec/get-file
20:45:55 <tspatzier> i.e. are you looking for people to implement a chef and puppet provider?
20:47:24 <stevebaker> tspatzier: yes, but it might be a bit early for that. We really need a get_file mechanism first
20:48:02 <tspatzier> agree on the get_file. that makes a lot of sense. The long inline script in your sample is nasty
20:48:43 <shardy> would that get resolved in the client, or in the engine via the environment?
20:49:12 <stevebaker> tspatzier: but we can push ahead with the hot-software-config and hot-software-config-rest blueprints for now. I'm hoping that at least get-file and hot-software-config-rest will make it into i-2
20:49:13 <zaneb> shardy: both
20:49:41 <zaneb> shardy: that is to say, in the engine, but the client would see it and ensure that the files get put into the environment automatically
20:49:45 <stevebaker> shardy: both client and engine need to "evaluate" get_file calls
20:49:56 <tspatzier> stevebaker, sounds good
20:50:36 <shardy> zaneb, stevebaker: Ok, sounds good, as long as we're passing the files via the environment rather than allowing urls to be referenced in the template parser
20:50:59 <zaneb> stevebaker: the client part is technically optional (you could make people include the files manually), but makes things ~10e6 times easier
20:51:12 <stevebaker> shardy: the plan is to fetch urls on the client side, and put the contents into the files section
20:51:15 <zaneb> shardy: ++
20:51:21 <shardy> stevebaker: +1
20:51:45 <stevebaker> shardy: should we do the same for --template-url too? I would like to
20:51:46 <zaneb> we need to stop resolving URLs in the api/engine unless they're from Swift
20:51:53 <radix> +1
20:52:13 <stevebaker> zaneb: --template-object is currently fetched client-side
20:52:14 <shardy> stevebaker: +1, and kill that parameter for the v2 API
20:52:40 <shardy> (but still allow it in the client, which will load and pass the template body)
20:53:09 <stevebaker> I've actually moved template_format.py and environment_format.py from heat to heatclient since we'll have to parse in heatclient to evaluate get_file
20:53:23 <zaneb> stevebaker: remember you have to think about nested stacks also
20:53:33 <stevebaker> heat already depends on heatclient
20:53:42 <chmouel> I was wondering if there was some work done already to move heatclient to requests like others *clients ?
20:53:58 <stevebaker> chmouel: that is looking for a volunteer
20:54:09 <susaant> stevebaker: Continuing the ML discussion - some of the vendor images do not allow installation of addition software. They allow config through ssh or REST etc. Will hot software-config take into consideration such scenarios.
20:54:15 <stevebaker> 6 minutes
20:54:17 <chmouel> stevebaker: cause httlib and utf8 is a PITA
20:54:23 <stevebaker> #topic autoscaling update
20:54:28 <radix> susaant: which vendors?
20:54:39 <shardy> radix: can you give us a quick update on where you're headed and what the status is?
20:55:01 <shardy> radix: you have quite a few BPs not started, so interested to hear the plan and check if you need help :)
20:55:17 <radix> yeah, sorry about that, that's my own failing. it should be farther along but I have been distracted by lots of other things
20:55:19 <susaant> radix: one sucnexample is f5 virtual big ip...
20:55:46 <stevebaker> susaant: we need to figure that out later, but you'll need to be *very* specific about what you're trying to achieve
20:55:48 <radix> my next task is still to start adapting parts of the PoC therve and I worked on a while back to submit some tiny patches
20:56:26 <radix> I am pretty much caught up after holiday now so hopefully you'll see patches soon :)
20:56:30 <zaneb> radix: github link?
20:56:42 <radix> sec
20:57:01 <shardy> radix: Ok, so are you going to break out the existing functionality first, ie refactor so we can have native AS resources with abstracted common logic, then add the AS API later?
20:57:16 <shardy> or are you still planning to start with the API then add functionality?
20:57:26 <stevebaker> chmouel: it would be great if you could tackle a heatclient requests conversion
20:57:28 <susaant> stevebaker: ok. Will take up this discussion over email..
20:57:34 <radix> looks like https://github.com/therve/heat/tree/as-api-spike and https://github.com/therve/heat/tree/bp/autoscaling-api
20:58:06 <radix> shardy: hmm, no, I think the plan was to start with the API
20:58:06 <chmouel> stevebaker: sure I can have a look is there a bp referencing this ?
20:58:27 <radix> shardy: but adapting from the existing code
20:58:49 <stevebaker> chmouel: I thought there was a bug for it but couldn't find anything yesterday. Please raise a bp in launchpad python-heatclient
20:58:52 <shardy> radix: OK, I would do the opposite FWIW but it sounds like you have a plan
20:59:15 <radix> regardless it should be tiny patches that don't change any existing functionality
20:59:26 <zaneb> radix: I agree with shardy here. The API is useless without some implementation behind it
20:59:40 <radix> zaneb: hmm, I don't think that's the same thing
20:59:44 <zaneb> but an implementation that allows us to implement native resource types is useful even without an API
20:59:50 <chmouel> stevebaker: ok! will do
20:59:53 <shardy> zaneb: +1
20:59:55 <radix> zaneb: by "start with the API" I of course mean having an implementation. the resources will wrap the API
21:00:14 <zaneb> radix: but what will the API wrap?
21:00:33 <stevebaker> #endmeeting