20:01:39 <sdake> #startmeeting heat
20:01:40 <openstack> Meeting started Wed Apr  3 20:01:39 2013 UTC.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:43 <openstack> The meeting name has been set to 'heat'
20:01:50 <sdake> #topic rollcall
20:01:55 <asalkeld> o/
20:02:05 <stevebaker> stevebaker
20:02:18 <zaneb> yo
20:02:25 <jpeeler> hey
20:02:38 <hanney> hi
20:02:42 <Slower> o/
20:02:43 <fsargent> hi
20:02:55 <sdake> hi
20:03:01 <sdake> looks like we have enough for a meeting
20:03:10 <sdake> #topic blueprint review
20:03:24 <sdake> we have a ton of blueprints, many more then we can get through in this meeting
20:03:31 <asalkeld> yea
20:03:37 <sdake> I'd like for folks to start thinking about them
20:04:05 <sdake> and how it relates to our other items of docs and tempest integration and general unit test improvements
20:04:15 <sdake> lets get rolling
20:04:43 <sdake> https://blueprints.launchpad.net/heat/+spec/resource-type-route
20:05:25 <stevebaker> maybe possible thanks to this https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routes
20:05:38 <asalkeld> that seems contained
20:05:44 <stevebaker> I think you can set attributes on a quantum router to specify routes
20:06:05 <sdake> jpeeler looking to get more involved in quantum
20:06:07 <stevebaker> need a quantum developer to provide some examples though
20:06:10 <sdake> looks like a good opportunity
20:06:27 <stevebaker> yep
20:06:33 <SpamapS> o/
20:06:44 <sdake> hey spam we are just doing bp reviews
20:06:55 <SpamapS> excellent, sorry for the tardy, other meeting went long
20:07:03 <sdake> happens all the time ;)
20:07:36 <sdake> stevebaker would you mind putting that link in the blueprint to help jpeeler get rolling
20:07:52 <stevebaker> its already a dependency of the blueprint
20:08:09 <sdake> cool
20:08:29 <sdake> #link https://blueprints.launchpad.net/heat/+spec/moniker-resource
20:09:13 <asalkeld> so I started this
20:09:30 <asalkeld> but at the time the moniker client was a wip
20:09:35 <asalkeld> so halted
20:09:47 <sdake> ok well then I'll unapparove it
20:09:56 <stevebaker> this could be 2 separate blueprints, native moniker, and route53 resource types
20:09:58 <asalkeld> also zaneb suggested moniker could keep the resourcees
20:10:19 <asalkeld> stevebaker, -1
20:10:25 <asalkeld> too many bp
20:10:34 <zaneb> I'm still in favour of that, but I expect we probably will still have to implement it for them
20:10:36 <asalkeld> makes life difficult
20:10:42 <stevebaker> ok, still native + route53 would be good though
20:10:46 <asalkeld> yea
20:11:59 <sdake> https://blueprints.launchpad.net/heat/+spec/raw-template-db
20:12:23 <sdake> this seems like a could add if we were out of other work to do, which is not the case
20:12:31 <sdake> so I'll set priority to low
20:12:40 <zaneb> tbh I think it's time we just cleaned that up
20:12:41 <stevebaker> I think that should be rejected, template is parsed so early in the process these days that there is no raw to store
20:13:13 <zaneb> stevebaker: huh? we only ever store the template raw
20:13:46 <stevebaker> zaneb: not raw yaml. it is parsed then serialized to json
20:14:14 <zaneb> right, but that's not what the raw_template table is
20:14:23 <asalkeld> well imagine a case were a cloud provides standard templates
20:14:29 <zaneb> it's called that because we used to also store the parsed template
20:14:41 <asalkeld> wouldn't it make sense to try save space?
20:14:45 <zaneb> i.e. after parameter subsititutions and stuff
20:15:01 <asalkeld> and store the template once
20:15:29 <zaneb> and we got rid of the parsed template because it was unnecessary state
20:15:36 <zaneb> asalkeld: we do only store the template once
20:15:53 <asalkeld> well this is suggesting not doing that
20:15:54 <SpamapS> I think having the actual template submitted, not the parsed one, is incredibly useful for developer workflow where they can ask for the current running template and review the diff.
20:16:13 <asalkeld> that won't go away
20:16:20 <SpamapS> If its all parsed templates then the diff they're looking at is not the code they wrote.
20:16:44 <stevebaker> SpamapS: a structural diff might be more helpful anyway
20:16:45 <zaneb> I'm not following this discussion at all. This blueprint is about the fact that what should be a Column in the database is actually a separate table.
20:16:51 <SpamapS> That BP is just suggesting moving the template into the main stack table as a blob right?
20:17:11 <stevebaker> yeah, that seems harmless, and low priority
20:17:51 <zaneb> SpamapS: parsed templates are completely ephemeral, we parse them on demand and there is no user access to them
20:17:55 <SpamapS> I'd say measure the latency of calls and define a target. If the latency is too high, this would be just one of many things (some less impactful) to do to bring it down.
20:18:24 <sdake> latency in heat is not an issue with current openstack design
20:18:30 <zaneb> I don't care about latency, but I care about maintainability of the code
20:18:35 <sdake> so even more reason to make low priority
20:18:51 <SpamapS> zaneb: sounds like it should be a bug, not a blueprint.
20:19:11 <asalkeld> I am not sure priorty really matters, it what the devs want to work on
20:19:15 <zaneb> SpamapS: as I've said before, the distinction is entirely specious ;)
20:19:33 <asalkeld> lets move on
20:19:37 * zaneb blames Shuttleworth
20:19:49 <zaneb> asalkeld: +1
20:19:55 <sdake> well for the moment i'll keep priority low
20:20:19 <sdake> https://blueprints.launchpad.net/heat/+spec/quantum-security-group
20:20:38 <SpamapS> zaneb: blueprints are good for keeping users unaware of the problem and unable to comment.. ;)
20:20:49 <zaneb> lol
20:21:03 <stevebaker> that change can be resurrected now that feature freeze is over
20:21:16 <stevebaker> next!
20:21:17 <sdake> stevebaker you indicated good progress on this blueprint, interested in handing off to jpeeler?
20:21:24 <sdake> guess not ;)
20:21:40 <sdake> https://blueprints.launchpad.net/heat/+spec/rest-xml
20:21:42 * jpeeler will take any quantum stuffs that people are willing to give up
20:21:49 <stevebaker> jpeeler: you could have a crack at rebasing https://review.openstack.org/#/c/22280/ and see if it still applies
20:23:08 <asalkeld> I think we should just use pecan+wsme
20:23:21 <stevebaker> should we wait until a user actually asks for xml, then give it a higher priority?
20:23:24 <asalkeld> that handles a range of serialization
20:23:39 <SpamapS> who actually wants XML?
20:23:44 <asalkeld> there is a bp for that
20:23:46 <sdake> tend to agree with stevebaker nobody cares for xml
20:23:56 <stevebaker> George Reese
20:24:12 <zaneb> I assumed we needed it because all the other APIs have it
20:24:16 <SpamapS> The TOSCA bits that are being discussed will satisfy the XML lovers.
20:24:22 <stevebaker> glance doesn't
20:24:36 <SpamapS> I say let he who requests XML implement it :)
20:24:36 <zaneb> if nobody wants it then I'm more than happy to kill it
20:24:47 * zaneb never wanted to implement it anyway
20:24:51 <sdake> spamaps +1
20:25:26 <zaneb> SpamapS: +5
20:25:27 <stevebaker> http://lists.openstack.org/pipermail/openstack-dev/2012-August/000857.html
20:26:23 <sdake> jay makes alot of sense there
20:26:34 <zaneb> agree
20:26:58 <asalkeld> that's why pecan+wsme is good
20:27:05 <asalkeld> it does the conversion for you
20:27:23 <asalkeld> you don't have to do anything
20:27:27 <sdake> ok lets move on
20:27:44 <zaneb> asalkeld: there would be work to massage the data though (see discussion in the blueprint)
20:28:05 <asalkeld> I'll read
20:28:20 <sdake> https://blueprints.launchpad.net/heat/+spec/raw-template-db
20:28:38 <sdake> https://blueprints.launchpad.net/heat/+spec/function-plugins
20:28:39 <stevebaker> didn't we just do that one?
20:28:41 <sdake> wrong cp ;)
20:29:02 <zaneb> I started on this, but didn't get very far
20:29:07 <zaneb> distracted by other work
20:29:15 <asalkeld> I think if we get a new format this gets less important
20:29:43 <asalkeld> we could have a solid aws format and a pluggable native one
20:29:58 <sdake> I believe one thing we are struggling with is helping to define priorities as a team
20:30:06 <stevebaker> should it be a depencency for these https://blueprints.launchpad.net/heat/+spec/bash-environment-function https://blueprints.launchpad.net/heat/+spec/template-string-function
20:30:31 <asalkeld> or just merge them
20:30:32 <sdake> would everyone be open to voting on setting "Design to approved" before working on the code
20:30:35 <zaneb> I don't know if we're doing a new format or what it would look like, so it's very hard to comment
20:31:07 <asalkeld> zaneb, that was just a thought
20:31:12 <zaneb> stevebaker: not necessarily, we can add those natively
20:31:24 <zaneb> stevebaker: i.e. not using plugins
20:32:03 <stevebaker> sdake, I wouldn't be keen on that process. it might discourage some interesting experiments
20:32:53 <asalkeld> yea lets not add more process than we need
20:33:22 <SpamapS> sdake: I think that "Approved" merely means "pay attention to this, the project is on board" not "go ahead and work on it"
20:33:54 <asalkeld> I think a problem with bp is they are a requirements/request view ; we then need a design/development view
20:33:58 <sdake> spamaps it seems to mean to most folks "go crazy its a blueprint" :)
20:34:48 <zaneb> so, Approved could be a useful signal for people looking at which blueprints to implement first
20:34:57 <zaneb> wouldn't want to treat it as gating though
20:34:59 <SpamapS> Indeed, the history of that particular value is that in the Ubuntu process teams sponsored Canonical would submit the specs to team managers and they would be approved for dev time..
20:35:17 <SpamapS> for an autonomous project like heat, its way too heavy
20:35:43 <asalkeld> yip
20:36:17 <asalkeld> lots of overlapping blueprints
20:38:04 <asalkeld> sdake i think you can kill this one : https://blueprints.launchpad.net/heat/+spec/cloud-init-metadata-section
20:38:40 <sdake> done
20:39:17 <stevebaker> actually, that sounds interesting
20:39:42 <sdake> too late now ;)
20:40:03 <stevebaker> oh well ;)
20:40:06 <sdake> this is how voting would help us move through blueprints
20:40:50 <asalkeld> stevebaker, you could always redo it
20:41:13 <stevebaker> sdake, can you ask the tech committee how they handle bp tsunamis in their projects?
20:41:43 <sdake> yes that is a great suggestion stevebaker
20:41:44 <sdake> thanks
20:42:13 <sdake> https://blueprints.launchpad.net/heat/+spec/prebuilding-images
20:42:37 <asalkeld> wow that's old
20:42:40 <jpeeler> i thought that was killed a long time ago
20:42:45 <sdake> ya should be killed off
20:42:51 <asalkeld> brought over from github
20:43:12 <asalkeld> yea +1 - kill
20:43:23 <sdake> https://blueprints.launchpad.net/heat/+spec/rolling-updates
20:43:46 <SpamapS> That spec needs updates to be compatible with Amazon's rolling updates
20:44:22 <SpamapS> but in general I'm suggesting going more anyway
20:44:52 <asalkeld> this seems odd (maybe kill it) -> https://blueprints.launchpad.net/heat/+spec/pulgins-way-to-resource
20:46:14 <sdake> https://blueprints.launchpad.net/heat/+spec/abstract-aws
20:46:17 <stevebaker> savana could use Heat without any special resource types
20:46:39 <sdake> abstracting aws seems like a good idea
20:46:55 <asalkeld> sure
20:46:55 <stevebaker> there are some separate bps for specific native resource types
20:47:46 <asalkeld> well it will  be interesting how the native format goes
20:47:48 <SpamapS> I think abstract-aws can be broken up into a few efforts
20:48:03 <stevebaker> yep
20:48:04 <asalkeld> if we get that then almost no point to this
20:48:14 <SpamapS> native resources, doc fixes, and code reorg
20:48:34 <SpamapS> asalkeld: I think native format is just yaml + native resource types :)
20:48:47 <zaneb> not sure abstract is the right word here
20:49:00 <asalkeld> can we kill this: https://blueprints.launchpad.net/heat/+spec/stack-id-to-scheduler-hints
20:49:04 <zaneb> but operators should be able to disable the built-in resources types
20:49:20 <SpamapS> zaneb: partition?
20:49:29 <stevebaker> should we spend some time talking about tomorrow's docsprint? (today for me)
20:49:30 <SpamapS> bifurcate?
20:49:49 <SpamapS> oh tomorrow is doc sprint? Count me in. (missed meeting last week)
20:49:51 <zaneb> SpamapS: I got nothing
20:49:51 <asalkeld> just have a map {'aws::*: disabled}
20:50:08 <SpamapS> zaneb: I'll work on a better word before teh summit
20:50:16 <sdake> #topic docsprint
20:50:22 * ttx lurks
20:50:25 <sdake> so stevebaker brings up a good point
20:50:32 <asalkeld> we need some word items
20:50:45 <asalkeld> and direction (format etc..)
20:50:52 <asalkeld> s/word/work
20:51:06 <sdake> I think what would make sense is a docsprint on 4/4 for US and 4/5 for NZ/AU
20:51:16 <stevebaker> I could write the cli guide, zaneb keen to do the api-ref?
20:51:16 <sdake> that way we can follow each other's work
20:51:47 <zaneb> stevebaker: yep, that seems like a good idea
20:52:09 <asalkeld> what else is there?
20:52:18 <sdake> #topic open discussion
20:52:22 <stevebaker> someone needs to do the heat-admin. but I think the missing manual that we all need to help on is the template writing guide
20:52:50 <asalkeld> I assume in yaml?
20:53:06 <stevebaker> snippets in both formats I guess
20:53:27 <asalkeld> that's a pain
20:53:43 <sdake> #undo
20:53:44 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x32ac250>
20:54:10 <sdake> lets hold off on the full template guide
20:54:18 <sdake> that is months of work
20:54:22 <SpamapS> I'd recommend snippets in yaml, as it is meant for readability
20:54:24 <sdake> and things may change after summit
20:54:38 <stevebaker> maybe we could have a crack at the skeleton structure, so we know what we're in for
20:54:40 <zaneb> well, I think we should autogenerate as much as possible
20:54:40 <asalkeld> well we can do something basic
20:54:49 <sdake> there we go, skeleton structure
20:54:50 <stevebaker> zaneb: +1
20:55:00 <zaneb> I believe stevebaker already made a blueprint for that
20:55:02 <SpamapS> sdake: I do feel like writing the guide, before having 100% native resource types, is a bit suspect
20:55:11 <sdake> spamaps I agree
20:55:19 <stevebaker> zaneb: that still leaves a lot of tutorial style stuff though
20:55:27 <zaneb> that's true
20:55:38 <zaneb> and that's a good place to start
20:55:41 <SpamapS> so, skeleton with the current native types well documented would be a pretty good goal
20:55:48 <SpamapS> also another goal for a doc sprint: *test* the docs
20:55:52 <SpamapS> as in, do everything it tells you to do
20:56:09 <stevebaker> SpamapS: once we have a docs, new features will need to be flagged for DocImpact
20:56:53 <sdake> ok 4 minutes left
20:57:01 <sdake> moving to open discussion now
20:57:05 <sdake> #topic open discussion
20:57:37 <sdake> we got through 10 blueprints in this meeting, just to review them
20:57:40 <zaneb> sdake: so it's open slather for delivery of Havana features now?
20:57:42 <sdake> we have 40 more to go
20:57:56 * zaneb is working on parallel launch
20:58:12 <sdake> ya we can start development now
20:58:15 <stevebaker> if someone is vaguely interested in an unassigned blueprint they should assign it to themselves
20:58:32 <ttx> sdake: still good to go for tagging the release tomorrow ?
20:58:37 <sdake> ttx yes
20:58:52 <ttx> Shall be done around 1500 UTC
20:59:00 <stevebaker> actually, I should release python-heatclient too
20:59:17 <ttx> expect some bugmali while I move stuff to final milestone in LP
20:59:27 <ttx> bugmail*
20:59:33 <sdake> ttx will watch for it
20:59:48 <sdake> our meeting time is over, so ending meeting enjoy ;)
20:59:50 <sdake> #endmeeting