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