19:59:41 <sdake> #startmeeting heat
19:59:42 <openstack> Meeting started Wed Feb  6 19:59:41 2013 UTC.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:45 <openstack> The meeting name has been set to 'heat'
19:59:58 <sdake> #topic rollcall
20:00:06 <sdake> sdake here
20:00:10 <zaneb> o/
20:00:14 <shardy> shardy here
20:00:17 <sdake> hidey zaneb
20:00:18 <SpamapS> o/
20:00:25 <stevebaker> \O
20:00:44 <jpeeler> jpeeler here
20:00:54 <sdake> \<>
20:01:02 <sdake> ascii art ftw
20:01:10 <asalkeld> here
20:01:13 <sdake> no asalkeld?
20:01:15 <sdake> hi there
20:01:23 <sdake> ok looks like we got enough to get started
20:01:38 <Slower> here
20:01:42 <sdake> #topic action review from last meeting
20:02:22 * sdake asalkeld, shardy, stevebaker, jpeeler to set implementation field in BPs
20:02:27 <sdake> that looks done
20:02:39 * sdake sdake to set all VPC blueprints to high
20:02:41 <sdake> that looks done
20:02:44 <stevebaker> sdake: do you run the ttx.py script?
20:02:54 * sdake heat devs to sort out if updatestack can update rather then delete in coming week
20:02:58 <sdake> i dont run that
20:03:06 <sdake> have a link?
20:03:15 <shardy> sdake: that's done for instance and autoscaling now
20:03:32 <shardy> which was the objective for G IIRC
20:03:40 <sdake> ok so done then?
20:03:43 <shardy> yup
20:03:45 <stevebaker> sdake: https://github.com/ttx/bp-issues <- his sanity check on LP fields
20:04:05 <sdake> #info all actions from 1-23-2013 meeting completed
20:04:22 <sdake> for those  that weren't here last week, we cancelled the meeting since most were travelling
20:04:38 <sdake> I'd like to go through the blueprints and bugs and make sure we are set for g3
20:04:42 <sdake> #topic blueprint review
20:05:14 <sdake> #link https://launchpad.net/heat/+milestone/grizzly-3
20:05:32 <sdake> stevebaker still blocked on the vpc work?
20:06:04 <stevebaker> I should be able to start soon, just waiting for some network ports to arrive in the mail
20:06:23 <sdake> https://blueprints.launchpad.net/heat/+spec/raw-template-db
20:06:41 <stevebaker> that might have to be bumped
20:06:56 <sdake> might or should, lets make a decision here ;)
20:07:17 <asalkeld> doesn't look needed
20:07:21 <stevebaker> OK, bump it. Any spare cycles will be spent on the vpc blueprints
20:07:23 <shardy> looks low priority to me
20:07:31 <zaneb> +1
20:07:54 <sdake> #info bump https://blueprints.launchpad.net/heat/+spec/raw-template-db to H cycle
20:07:57 <zaneb> sdake: will we be doing a db migrations reset for G?
20:08:05 <sdake> i think we should
20:08:11 <shardy> +1
20:08:14 <sdake> but should probably have a vote on it
20:08:23 <zaneb> ok, so that should probably be done at the same time
20:08:28 <zaneb> (or before)
20:08:31 <asalkeld> what about current users?
20:08:43 <asalkeld> they have to reinstall?
20:08:56 <asalkeld> maybe talk to ppetit
20:09:14 <zaneb> no, just restart the numbering where it is
20:09:22 <sdake> #action sdake to bring up thread on openstack-dev about dumping the db migrations
20:09:45 <zaneb> asalkeld: if nova can get away with it, we certainly can
20:10:17 <sdake> #link https://blueprints.launchpad.net/heat/+spec/resource-properties-schema
20:10:38 <sdake> lets have discussion about it on ml and see what pops up
20:10:56 <sdake> zaneb your assigned to that last link
20:11:10 <sdake> feb 21 is deadline for blueprints
20:11:11 <zaneb> bump
20:11:19 <zaneb> that's low priority
20:11:23 <stevebaker> its a nice-too-have, but low priority
20:11:34 <sdake> #info bump https://blueprints.launchpad.net/heat/+spec/resource-properties-schema to H cycle
20:11:36 <stevebaker> at least until horizon ui picks up
20:11:58 <zaneb> stevebaker: +1
20:12:09 <shardy> +1
20:12:23 <asalkeld> yea
20:12:32 <sdake> #link https://blueprints.launchpad.net/heat/+spec/aws-cloudformation-init
20:13:02 <sdake> jpeeler?
20:13:14 <jpeeler> thanks to pfreund, i think the only thing left is implementing configsets
20:13:27 <jpeeler> so i'm working on that
20:13:38 <sdake> ok, so looks goot for feb 21?
20:13:43 <sdake> goot/good ;)
20:13:48 <jpeeler> yep, question about cfntools though
20:13:49 <zaneb> gut
20:14:01 <jpeeler> are we trying to maintain the copy in heat-jeos with the separate repo or what?
20:14:02 <sdake> #info https://blueprints.launchpad.net/heat/+spec/aws-cloudformation-init on target for g3 deadline
20:14:19 <jpeeler> (i can wait on that question)
20:14:21 <asalkeld> just seperate cfn
20:14:33 <stevebaker> jpeeler: I plan to rip cfntools out of heat-jeos and replace with a pip install
20:15:32 <stevebaker> in the meantime, any changes will be manually synced between heat-jeos and heat-cfntools
20:15:34 <sdake> we will try to get through as many bugs as possible - but may not be able to tackle them all in this meeting
20:15:39 <sdake> #topic bug review
20:15:50 <sdake> #link https://bugs.launchpad.net/bugs/1072906
20:15:52 <uvirtbot> Launchpad bug 1072906 in heat "Handle XML as well as JSON in ReST API" [Medium,Confirmed]
20:16:18 <zaneb> that's more of a bluprint
20:16:33 <sdake> ok, so make blueprint and remove as bug?
20:16:34 <asalkeld> if we used wsme it comes for free
20:16:48 <asalkeld> (what is in ceilometer)
20:16:51 <shardy> zaneb: have you looked at the controller code, I think it could be quite simple?
20:16:55 <zaneb> sdague: probably
20:17:00 <zaneb> sdake: probably
20:17:18 <sdake> #action zaneb to move 1072906 to blueprint
20:17:19 <zaneb> I think selecting between the two is not that hard
20:17:36 <shardy> we already have JSON and XML serializer/deserializer implementations IIRC, so we just have to fix the content type detection
20:17:36 <sdake> so as a blueprint, that going to make 21?
20:17:36 <zaneb> actually getting the output in an acceptable XML format... possibly hard
20:17:48 <zaneb> sdake: no
20:17:50 <shardy> assuming same wsgi middleware as the CFN api that is
20:18:05 <sdake> ok - file as a blueprint and we can take up in h cycle and close the bug please ;)
20:18:13 <zaneb> ok
20:18:26 <sdake> #link https://bugs.launchpad.net/bugs/1072905
20:18:30 <uvirtbot> Launchpad bug 1072905 in heat "make template functions "Fn::" pluggable." [Medium,In progress]
20:18:47 <stevebaker> another blueprint ;)
20:19:13 <asalkeld> tho not a big job
20:19:15 * stevebaker notes that its Mark Shuttleworth's fault that blueprints are a separate thing in launchpad
20:19:31 <shardy> it is a confusing distinction
20:19:32 <sdake> #action zaneb refile 1072905 as blueprint
20:19:45 <sdake> so as a blueprint that going to make 21?
20:20:34 <asalkeld> let's wait and see?
20:20:54 <sdake> would like blueprints to be stabilized so we know what work we have on our plates
20:21:02 <zaneb> Fn:: pluggableness is actually a pretty big job
20:21:05 <sdake> if we aren't going to finish something for g3, no sense spending effort on it now
20:21:15 <sdake> need to focus on g3 specific tasks
20:21:22 <asalkeld> we could just prioritize?
20:21:22 <zaneb> as in, Havana cycle job
20:21:32 <sdake> ok - well still please file blueprint and close bug ;)
20:21:34 <asalkeld> and do what we can
20:21:39 <sdake> #link https://bugs.launchpad.net/bugs/1072917
20:21:41 <uvirtbot> Launchpad bug 1072917 in heat "heat cli: Template Body maximum length problem." [Medium,Triaged]
20:21:58 <shardy> I need to investigate this, it's broken with qpid but works with rabbit
20:22:12 <shardy> probably something simple, but not sure yet
20:22:28 <stevebaker> hmm, so not much chance of replicating it in a unit test
20:22:34 <shardy> planning to look into it next week
20:22:41 <sdake> #link https://bugs.launchpad.net/bugs/1072940
20:22:43 <uvirtbot> Launchpad bug 1072940 in heat "backtrace on console 3-5 minutes after HA test completes" [Medium,In progress]
20:22:59 <shardy> I'm pretty certain this is fixed now
20:23:20 <shardy> The backtrace was because the create greenthread didn't get deleted, which is now does
20:23:32 <shardy> I just need to re-run the integration test to prove
20:23:33 <sdake> ok - so state of bug is wrong?
20:23:45 <shardy> I was just going to re-test then close it as invalid
20:23:47 <sdake> #action shardy to rerun ha test for 1072940 and fix state
20:23:53 <sdake> it was a valid bug th o ;)
20:23:58 <sdake> so close as fix commited i think
20:24:03 <shardy> Yeah, it's not notabug anymore
20:24:11 <shardy> was valid previously :)
20:24:25 <shardy> ok will do
20:24:31 <sdake> #link https://bugs.launchpad.net/bugs/1072948
20:24:32 <uvirtbot> Launchpad bug 1072948 in heat "some resource create and delete operations could block in failure scenarios" [Medium,In progress]
20:24:43 <sdake> so this is fixed, but shardy had some problems with the patch
20:24:48 <sdake> what is your thinking here shardy
20:25:12 <shardy> I think if nova is broken, heat is broken, introducing some hard-coded timeout logic is just wrong IMO
20:25:23 <asalkeld> +1
20:25:28 <zaneb> I think there are enough safeguards on create already
20:25:28 <asalkeld> delete bug
20:25:39 <zaneb> some on delete would be good though
20:25:47 <asalkeld> we have a stack create timeout
20:26:01 <zaneb> because state may go from ERROR -> ERROR and we have no way of detecting the transition
20:26:21 <asalkeld> don't we have a timeout on delete?
20:26:38 <zaneb> asalkeld: should use the same one as for create
20:26:48 <zaneb> i.e. timeout for whole stack
20:26:57 <asalkeld> yip
20:26:58 <zaneb> but has same value as create timeout
20:27:00 <sdake> however if nova breaks, there is no way for the heat user to identify nova is broken, and they may then think heat is broken
20:27:05 <zaneb> so, pretty long wait
20:27:36 <zaneb> sdake: I think you need timeout on nova only if instance starts in ERROR state
20:27:38 <asalkeld> sdake, you can adjust the timeout
20:27:49 <sdake> wedging heat entirely because nova misbehaves at some point seems wrong
20:28:05 <shardy> but if nova (or any other core service we rely on) is broken, everything is broken
20:28:08 <asalkeld> sdake, it won't wedge heat
20:28:19 <shardy> Is this a real problem, ie do we have any sort of reproducer?
20:28:23 <asalkeld> it will timeout and fail
20:28:48 <sdake> i have seen it happen but no reproducer
20:28:56 <sdake> but didn't wait for a timeout from heat proper
20:29:09 <sdake> ok well we can close bug then if everyone feels current functionality is ok
20:29:11 <shardy> The real problem is the while True loops in the instance resource
20:29:13 <asalkeld> ya, the timeout is big
20:29:31 <shardy> we should just make that a specific number of retries
20:29:37 <sdake> #action sdake 1072948 should be closed
20:29:47 <asalkeld> we need parallel resource startup!
20:29:54 <sdake> #action shardy to file bug with what he thinks are necessary steps to deal with problems in 1072948
20:30:01 <sdake> ;)
20:30:06 <zaneb> shardy: +1
20:30:16 <shardy> sdake: Ok, will do
20:30:21 <sdake> ok #link https://bugs.launchpad.net/bugs/1072952
20:30:23 <uvirtbot> Launchpad bug 1072952 in heat "Implement Rollback feature of AWS API" [Medium,Triaged]
20:30:49 <sdake> blueprint?
20:30:52 <shardy> I'm planning to do that next week
20:31:02 <shardy> can convert to blueprint if you prefer
20:31:08 <sdake> looks like one to me
20:31:13 <shardy> ok, will do
20:31:18 <sdake> #action shardy to convert 1072952 to blueprint
20:31:36 <sdake> #link https://bugs.launchpad.net/bugs/1072955
20:31:37 <uvirtbot> Launchpad bug 1072955 in heat "Implement Fn::Base64" [Low,Triaged]
20:31:44 <sdake> I dont think this is needed
20:31:59 <stevebaker> blueprint?
20:32:04 <asalkeld> noop
20:32:06 <zaneb> yeah, extremely low priority
20:32:08 <sdake> i think it is a noop
20:32:14 <zaneb> currently, yeah
20:32:19 <sdake> I did implemenet this once, and it broke heat
20:32:33 <sdake> because it passed base64 to cloudinit which didn't expect it
20:32:49 <zaneb> could set the mime-type to cloudinit to base64
20:33:01 <zaneb> er, mime-encoding
20:33:05 <sdake> #action sdake to close 1072955
20:33:26 <sdake> #link https://bugs.launchpad.net/bugs/1087530
20:33:27 <uvirtbot> Launchpad bug 1087530 in heat "sendfile possibly problematic with eventlet" [Medium,In progress]
20:33:34 <zaneb> sdake: don't close it, people might want to use Base64 elsewhere in their template
20:33:47 <stevebaker> https://review.openstack.org/#/c/21184/
20:34:13 <stevebaker> I realise now it is client side code only, but no harm in removing it
20:34:27 <sdake> zaneb do you plan to fix this before 21st then?
20:34:35 <sdake> or bump to h
20:34:38 <sdake> #undo
20:34:38 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x195de10>
20:34:39 <sdake> #undo
20:34:40 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x1d820d0>
20:34:44 <zaneb> sdake: no, just leave it open and bump imo
20:34:57 <sdake> #action zaneb to turn 1072955 into blueprint and bump to h
20:35:12 <sdake> #link https://bugs.launchpad.net/bugs/1087530
20:35:13 <uvirtbot> Launchpad bug 1087530 in heat "sendfile possibly problematic with eventlet" [Medium,In progress]
20:35:41 <sdake> ok that review looks good stevebaker, i'll approve after meeting
20:36:08 <sdake> ok the rest are unassigned
20:36:28 <sdake> lets go through those and see if any interest folks ;)
20:36:45 <stevebaker> https://bugs.launchpad.net/heat/+bug/1096013 is what I'll be working on next
20:36:45 <sdake> also, zane is a bit busy with another task unrelated to heat for 2-4 weeks so wont be able to help with our final g push
20:36:46 <uvirtbot> Launchpad bug 1096013 in heat "Instance resource doesn't allow IP assignment to VPC/quantum network" [High,Triaged]
20:37:16 <sdake> #link https://bugs.launchpad.net/bugs/1072935
20:37:18 <uvirtbot> Launchpad bug 1072935 in heat "interrupting a nosetest results in backtrace on future creations of stacks" [Low,Triaged]
20:37:45 <sdake> developer focused bug, can probably bump to h
20:37:53 <zaneb> sdake: can we add some more milestones? current buckets are only "grizzly-3" or "everything else"
20:38:07 <asalkeld> h
20:38:16 <sdake> ya i'll see if i can yet
20:38:36 <sdake> #action sdake to bump 1072935 to h
20:38:53 <sdake> #link https://bugs.launchpad.net/bugs/1072937
20:38:54 <uvirtbot> Launchpad bug 1072937 in heat "odd error from heat list after a delete" [Low,Triaged]
20:39:16 <sdake> this is super hard to reproduce
20:39:22 <sdake> and may not be present any longer
20:39:35 <stevebaker> that should be heat-cfn list, not heat list
20:39:42 <sdake> old bug
20:39:47 <sdake> from v4 days i think ;)
20:40:07 <zaneb> should still be around, hard to reproduce though
20:40:21 <asalkeld> just delete it and if it happens again re-create?
20:40:29 <zaneb> fix is there in the comments
20:40:29 <sdake> prefer to keep a record
20:40:31 <stevebaker> i say delete
20:40:34 <sdake> but doens't mean we have to fix for h
20:41:09 <asalkeld> well bump it then
20:41:19 <zaneb> why delete when we have collected all that info about how to fix it in the bug
20:41:46 <stevebaker> I mean close, it is still searchable
20:42:04 <zaneb> it's still a bug too, so why close
20:42:09 <asalkeld> yar, you can't actually delete
20:42:21 <sdake> #link https://bugs.launchpad.net/bugs/1072958
20:42:22 <uvirtbot> Launchpad bug 1072958 in heat "Create a getting started guide for scaling out" [Medium,Triaged]
20:42:34 <sdake> this seems like h material
20:43:20 <sdake> #link https://bugs.launchpad.net/bugs/1072957
20:43:23 <uvirtbot> Launchpad bug 1072957 in heat "Add role to users, similar to nova's user role assignment" [Medium,Triaged]
20:43:48 <sdake> #action shardy to speak with keystone folks about this
20:44:08 <shardy> I think this is an internal user->role mapping, not a keystone role?
20:44:22 <sdake> wasn't this the bug we were speaking about earlier in the week shardy?
20:44:28 <sdake> #undo
20:44:28 <shardy> not high priority IMO, no users have asked for this
20:44:29 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x1dd10d0>
20:44:51 <shardy> no, the one we discussed is the create stack as non-admin when it creates User/AccessKey resources
20:44:58 <sdake> right
20:45:11 <sdake> #link https://bugs.launchpad.net/bugs/1096001
20:45:12 <uvirtbot> Launchpad bug 1096001 in heat "Parser Fn::GetAZs intrinsic function returns hard-coded value" [Medium,Triaged]
20:45:18 <shardy> I contacted ayoung about it today, he thinks trusts should help us address it for h
20:45:25 <sdake> nice
20:46:40 <shardy> Our AZ handling is all a bit broken I think (we don't pass AZ's to nova), so I say bump to H and have an multi AZ test/fix then
20:47:41 <sdake> #link https://bugs.launchpad.net/bugs/1096017
20:47:42 <uvirtbot> Launchpad bug 1096017 in heat "AutoScalingGroup missing VPCZoneIdentifier property" [Medium,Triaged]
20:48:07 <shardy> Unless the VPC features are landing for G, we can bump this
20:48:27 <sdake> i am hopeful the vpc features land for g
20:48:43 <sdake> ok well thats all the high/med bugs
20:48:57 <sdake> there are still a few unassigned - feel free to take those up if your bored ;)
20:49:14 <sdake> #topic integrated status
20:49:34 <sdake> So basically we need to present our case as to why we are integrated ready
20:49:39 <sdake> (which is like core)
20:49:57 <asalkeld> serious?
20:50:07 <sdake> i'd suggest everyone send me a couple paragraphs and i'll sort it out into one email
20:50:10 <sdake> ya serious
20:50:24 <stevebaker> ok
20:50:25 <asalkeld> I thought it was a review not marketing exercise
20:50:32 <asalkeld> weird
20:50:51 <sdake> well i could be wrong on what i read in the meeting but thats what it looked like to me
20:50:55 <shardy> I assumed we'd be incubated for ~6months then reviewed
20:51:00 <stevebaker> so there is "core" and "integrated" now?
20:51:14 <sdake> ya, i think they passed new rules just yesterday on this point
20:51:34 <zaneb> stevebaker: core is a subset of integrated
20:52:01 <stevebaker> seems sensible, depending on the specifics of what each means
20:52:05 <sdake> #topic open items
20:52:19 <zaneb> stevebaker: the only difference is trademarks, effectively
20:52:35 <stevebaker> can we talk heat-horizon?
20:52:36 <sdake> ok guys 3 weeks left
20:52:47 * stevebaker invokes mordred
20:52:54 <sdake> please wrap up blueprints and bugs
20:53:09 <sdake> ya what do you want to discuss about heat-horizon
20:53:22 <stevebaker> Monty mentioned that HP need a working horizon UI to heat, and have a developer ready to pick up some heat-horizon work
20:54:23 <sdake> cool
20:54:31 <stevebaker> I'm thinking we should at least get heat-horizon into gerrit and launchpad
20:54:54 <sdake> as a plugin you mean?
20:54:57 <asalkeld> sure, stackforge?
20:55:24 <stevebaker> it could stay in github/heat for now?
20:55:50 <asalkeld> sure
20:55:54 <sdake> github/heat is easy to work with
20:56:04 <sdake> there is alot of overhead to gerrit integration
20:56:05 <stevebaker> sdake: as a horizon plugin. Once we're "integrated" we could propose that it goes into horizon
20:56:08 <sdake> but we can do it
20:56:20 <sdake> ya just thinking about short circuiting the need for a plugin :)
20:56:28 <sdake> ie propose directly in a few weeks
20:56:38 <sdake> vs setup a bunch of infrastructure for 3-4 weeks of time
20:56:45 <asalkeld> +1
20:57:04 <stevebaker> true. I guess there is a risk that horizon devs will want it to stay as a plugin
20:57:07 <asalkeld> tho I think you only get integrated after 8 months?
20:57:35 <sdake> but the core of the issue is the hp dev needs a way to develop on the codebase
20:57:40 <sdake> and that is easy to solve
20:57:48 <sdake> may make more sense as a plugin
20:57:54 <sdake> that is for horizon devs to decide imo ;)
20:58:15 <stevebaker> https://github.com/heat-api/heat-horizon fyi
20:58:28 <sdake> yup
20:58:32 <asalkeld> 1 min...
20:58:40 <stevebaker> thats all from me
20:59:18 <sdake> ok thanks guys
20:59:26 <sdake> #endmeeting