20:00:48 #startmeeting heat 20:00:49 Meeting started Wed Jul 17 20:00:48 2013 UTC. The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:53 The meeting name has been set to 'heat' 20:01:02 Hi 20:01:03 #topic rollcall 20:01:06 evening all 20:01:07 hello all 20:01:11 Hi 20:01:13 hi 20:01:14 o/ 20:01:15 hi 20:01:15 o/ 20:01:16 here 20:01:18 Hi! 20:01:27 o/ 20:01:31 hi 20:01:33 Hi, I'm new to HEAT but very interested in it. I mostly focus on Keystone 20:01:36 o/ 20:01:40 hi 20:01:44 topol: first lesson, Heat is not an acronym :) 20:02:03 topol: and _welcome_!! 20:02:05 failed the 1st day quiz... again... :-) 20:02:17 * mordred hands topol a consolation cookie 20:02:17 o/ 20:02:20 thanks 20:02:30 mordred: you really should stop putting so much rum in those. 20:02:37 SpamapS: NEVAR 20:02:37 #topic h-2 20:02:38 I can never figure why everybody thinks it is an acronym 20:03:02 because its FOUR letters? 20:03:25 zaneb: I have no idea. people respond to emails I've written with "TripleO" spelled out referring to the project as ooo ... so who knows 20:03:26 milestone-proposed is cut! https://github.com/openstack/heat/commits/milestone-proposed 20:03:32 zaneb: Perhaps they are in need of Human Enhanced Acronym Training. 20:03:33 well done everyone 20:03:40 congrats! 20:03:50 lots of goodness in h2 20:04:24 here btw 20:04:46 I assume that means it is open season on master. difficulty of backporting fixes notwithstanding 20:05:06 I'll mark my ceilometer patches as wip 20:05:10 anyhoo, back to the real agenda 20:05:14 #topic Review last week's actions 20:05:15 I am just cleaning up 20:06:03 heat-core to write a mission statement (stevebaker) 20:06:05 stevebaker to start mission discussion on list (stevebaker) 20:06:07 wow, totally failed to do that 20:06:25 must have been busy 20:06:26 #action stevebaker to start mission discussion on list 20:06:42 Hello! 20:06:44 asalkeld, stevebaker to raise some documentation blueprints 20:06:48 hi 20:07:01 which brings us to 20:07:03 #topic Documentation 20:07:38 I need to document the environ stuff 20:07:54 A template writing guide is heat's missing manual 20:07:55 and resource-templaets 20:08:13 but with HOT, that is a moving target 20:08:14 asalkeld: I can do the latter if you like 20:08:19 i have an open a change request that has an example with some of the templates in it 20:08:20 https://review.openstack.org/#/c/37302/ 20:08:29 so I wanted to get a HOT spec started and was wondering what the best way would be 20:08:31 why is HOT still a moving target? 20:08:57 I think it would be good to start documenting all the templates 20:08:59 SpamapS: because its incremental and feature focused now vs. a spec-up-front as originally proposed 20:09:00 can we just pick a way, call it v1, and move forward? 20:09:01 I don't see that we my change hot as reason not to doc 20:09:04 I'll be working on blueprint generate-resource-docs in this cycle 20:09:11 SpamapS, the plan would be to let the HOT spec evolve with implementation. right now we have hello world, but plan to add more features step by step 20:09:23 stevebaker, i would love to help out with that 20:09:27 +1 for evolving it with implementation 20:09:59 as asalkeld says, thats not the best reason for not publishing the way it works now and a guide on how to use it as it works now. 20:10:04 we just need somewhere to put it 20:10:06 I created a BP for getting started with the HOT spec based on the current hello world impl. Happy to drive this 20:10:06 I think documentation should reflect reality. 20:10:08 and make sure core reviewers are asking people to update the docs as people implement features 20:10:38 I think it would be best done in the github repo so we have governance and review, like we have with API docs 20:10:50 +1 to TravT documentation should evolve with real-time changes. 20:10:51 radix: i would even go further, whenever a new feature comes it needs to be doc'ed as well as any template 20:10:59 radix: right, doc changes ideally would precede or accompany all changes to HOT. 20:10:59 yes, it should go in heat/doc/source, in a new book 20:11:25 SpamapS: not just HOT, but any feature moving forward, yes? 20:11:32 (hopefully not in xml docs) 20:11:34 jsloyer: that's what I meant 20:11:54 not xml, rst 20:11:59 phew 20:12:10 hehe 20:12:20 radix: yes please :) 20:12:21 we do something very similar in keystone. its very helpful 20:12:22 rr 20:12:26 randallburt: yes please :) 20:12:34 for new folks like me trying to learn what already exists 20:12:42 stevebaker, when I look at the current doc directory in github, will it be example enough to start the HOT spec? or do you recommend a specific piece that is in good shape? 20:12:47 (its not xml) 20:12:51 if someone wants to volunteer to create an rst a skeleton structure for a Template Writers Guide, raise your hand 20:12:57 i have 20:13:01 https://review.openstack.org/#/c/37302/ 20:13:07 I think I just saw kebray shed a tear 20:13:10 If the docs are in the repo, then the doc changes could be part of the review set 20:13:10 * tspatzier raises hand 20:13:23 raises hand 20:13:27 btw, I opened this BP for it: https://blueprints.launchpad.net/heat/+spec/hot-specification 20:13:48 sounds like we have docs moving forward nicely :) 20:14:04 tspatzier: we need to focus on our audience, template writers need to be guided in how to write templates. at best a HOT spec would be in the appendix 20:14:39 stevebaker, agreed. Will try to keep it similar to the cfn spec which is quite user friendly 20:14:56 I can update the BP to reflect this. 20:14:57 jsloyer: cool, I'll take a look at that. 20:15:02 so jsloyer, your patch has a lot of files in it. Is one of them *the* v1 HOT spec??? 20:15:19 https://review.openstack.org/#/c/37302/6/doc/source/templates/hot/hello_word.rst 20:15:34 jsloyer: when I get to blueprint generate-resource-docs I'll look at generating files into that structure 20:15:56 k 20:16:14 stevebaker: let me know if you need any help, have some spare cycles 20:16:37 So, does anything need to be done with these pages: https://wiki.openstack.org/wiki/Heat/DSL https://wiki.openstack.org/wiki/Heat/DSL2 20:16:47 zaneb: now we're incubated, could you resurrect the api docs and merge them with the main openstack api docs? 20:17:12 mmmmm, I thought I did that on the last docs sprint 20:17:29 i think it is still its own document in our source tree 20:17:43 we're integrated 20:17:46 not incubated :) 20:17:55 zaneb stevebaker http://docs.openstack.org/developer/heat/man/ 20:17:56 they had to tag their grizzly docs before we could merge ours 20:18:04 in......ed 20:18:05 stevebaker: so I need to submit it to some other repo? 20:18:12 yes, some other repo 20:18:31 * stevebaker looks 20:18:32 TravT: I don't think so. those are more talking points/jump off for future features/HOT format stuff 20:18:37 does anybody have a preference? 20:18:37 https://github.com/openstack/api-site 20:18:40 ? 20:18:45 or I'll just pick one at random ;) 20:19:02 thats the one https://github.com/openstack/api-site/tree/master/api-ref/src/wadls 20:19:17 randallburt: maybe at least update them to point them to the real docs when available? 20:19:48 TravT: maybe, but they aren't docs. those pages are early spec proposals. 20:19:48 ok, can do. are there any tools for testing that? 20:19:50 Am I right in that after H-3 we shouldn't be merging major features before H? 20:20:03 zaneb: mvn package ;) 20:20:05 stevebaker: I believe that's how it works 20:20:28 so one last cycle? 20:20:32 dam 20:20:36 if that's a week worth of installing xml-y java-y stuff, forget about it 20:20:38 so this cycle will be quite busy, and in theory we'll be able to put more effort into docs after h-3 20:21:04 after H-3 we should focus on docs, testing, bug fixing, and planning. 20:21:07 zaneb, maybe make a heat template 20:21:11 asalkeld, That means finishing ceilometer stuff? 20:21:15 It's going to be tight 20:21:17 that installs all the docs 20:21:30 #topic h3 blueprint milestone and priority 20:21:30 therve, yea 20:21:47 #action zaneb merge api docs with api-site repo 20:21:52 asalkeld: oh man, now I have to get OpenStack running as well? ;p 20:22:00 haha 20:22:13 #link https://launchpad.net/heat/+milestone/havana-3 20:22:25 (one way to keep the xml from you host) 20:22:32 32 blueprints! 20:23:08 we delivered 8 in h-2, and 8 in h-1 20:23:20 I 20:23:27 so we're on track? 20:23:58 some of those aren't prioritized, so are they "officially" in h3? 20:23:59 well we just have to work 4 * as hard 20:24:13 I'd like to think that the havana cycle has been all about ramping up, and we have a chance on delivering a bunch of those, but 32 might be a bit optimistic ;) 20:24:34 some big ones there 20:24:53 Some are in progress for a bit, but yeah 20:24:59 20 sounds more realistic 20:25:24 Any blueprint assigned to you, its up to you what milestone to set it to. So *please* take a look at your own and set some realistic milestones 20:26:22 4 are still unassigned so good targets to be pushed 20:26:23 yip 20:26:43 some of them are more umbrella blueprints that are ongoing, abstract-aws, open-api-dsl 20:27:04 I hope to start going on rolling-updates as of Monday. 20:27:24 SpamapS: cool 20:27:41 SpamapS: need to chat with you on the rolling updates in #heat after meeting 20:28:31 m4dcoder: of course 20:29:01 anything else on h-3? 20:29:19 #topic Open discussion 20:29:29 I have questions about: https://review.openstack.org/#/c/36844/ 20:29:38 My implementation of the main feature of this blueprint (generating a template for a resource) allows for two use cases via a flag to the function. The first is that you want a very simple template generated, where the resource's properties schema is mapped to parameters and properties, but nested schemas are not resolved. The second resolves nested schemas resulting in more generated parameters. I wanted to open it up for 20:29:39 discussion because the function implements the requirement of the blueprint, while giving additional functionality. 20:30:15 It has been -1 for this additional functionality and I would like to hear more voices on the matter 20:31:19 andrew_plunk2: maybe you should also provide some examples on how (+ why) it would be used 20:31:34 it's not easy to reverse engineer from the code 20:31:51 would it suffice to split it into two separate commits? 20:31:55 two separate blueprints? 20:32:10 so the basic gain would be being able to see more parameters rather than less 20:32:13 +1 for two changes 20:32:23 I don't see a problem with that patch 20:32:47 +1 for two patches 20:33:09 As of now, horizon has a heat UI, with a freakin awesome animated topology diagram. 20:33:11 I pity the fool who does not make this a part of their heat workflow! 20:33:12 the second one still gets my -1 for adding unnecessary complexity 20:33:37 thanks everyone 20:33:52 :) 20:34:04 then splitting commits doesn't solve andrew_plounk's original question though.. which, is more input on the second part of the change. 20:34:14 andrew_plunk2: IMO generating the template isn't about _seeing_ stuff. it's about _doing_ stuff with it 20:34:18 zaneb: is that like saying we might as well not submit it? Still unclear on the process there 20:34:30 there has been discussion of implementing some heat resources that use Otter for auto scaling. this would allow for more incremental implementation of the new autoscaling design. does that sound reasonable? I can write an email if that's not clear 20:34:34 -1 is not a ban-hammer 20:34:39 -2 is the ban-hammer :) 20:34:48 zaneb: ah, cool. thanks 20:34:56 * topol the dreaded red x 20:35:15 I tend to launch stacks on the command line then watch them in horizon, its very insightful 20:35:41 andrew_plunk2, I think we just need a use case 20:35:44 radix: does that makes sense as a "general" or openstack resource or as something say under resources/rackspace? 20:36:04 (how are we going to benefit from the feature) 20:36:33 some example outputs (one for each proposal) would help me understand the controversy 20:36:57 randallburt: I think at first it makes sense to call it Rackspace-specific, but it should be trivial to generalize them once we have a separate autoscaling service 20:37:13 radix: k 20:37:18 asalkeld: A big point of this blueprint was to give an end user a starting off point of a template for a resource. That user might want the bare minimum or every possible functionality of the resource filled in 20:37:20 ie the implementations of the resources should stay the same 20:37:58 My implementation would allow for either 20:38:04 andrew_plunk2: but every possible functionality of the resource is filled in in both cases 20:38:06 so yea, I get the first part (and like it) 20:38:25 the difference is that one will work, and the other will not 20:38:48 zaneb, I think you two need to talk 20:38:55 (off line) 20:39:07 I wanted to bring up two blueprints, https://blueprints.launchpad.net/heat/+spec/software-configuration-provider, https://blueprints.launchpad.net/heat/+spec/signaling-coordination 20:39:48 I raised a blueprint this week about Multi region support for Heat (https://blueprints.launchpad.net/heat/+spec/multi-region-support). If you can review it and give me some feedback it would be great. 20:39:54 basically its an addition to HOT to allow installation and configuration of software 20:40:56 jsloyer, the signalling will need some kind of api 20:41:05 SpamapS most likely has some opinions here 20:41:23 I was hoping moniker would move along faster 20:41:30 asalkeld: yeah i was on the fence whether it should be an api or something that gets called from the client 20:41:35 in more of a peer to peer 20:41:42 asalkeld, we discussed something related this week in #heat 20:41:47 * SpamapS reads 20:42:17 to me a moniker message q would be nice for this 20:42:30 but that is not quite ready 20:42:44 jsloyer: I love the de-coupling of "this is a configuration for X" and "this is a server that has configuration for X" 20:42:56 asalkeld, I guess we will create a wiki with use case some implementation considerations and then find out what is there as potential starting point. 20:42:58 moniker? 20:43:18 spamaps: trying to keep things simple here with a nice clean format to accomplish some more complicated coordination tasks 20:43:30 +1 on decoupling software from infrastructure 20:43:34 jsloyer: I will put some time into a true evaluation. I've wanted this in Heat for a long time now. :) 20:43:37 sorry marconi 20:43:40 https://wiki.openstack.org/wiki/Marconi 20:43:47 moniker was dns I thought 20:43:48 hehe OK 20:43:53 jsloyer: and the other bit, sharing data between software/instances, I also am very interested in making that smooth. 20:43:58 radix Moniker is now Designate… it's DNS for Openstack. 20:44:02 right. (and now designate) 20:44:05 i am definetly open to other ideas as well here just wanted to get it on the books 20:44:18 (my bad too many M* names) 20:44:38 kebray: yeah that was a "do you really mean moniker" :) 20:45:10 too many bad M* names 20:45:32 so good that this project is not called Meat, isn't it? 20:45:36 so we can continue this over #heat or through the email distro, just wanted to get the ball rolling 20:45:40 hahaha 20:45:49 Meat is Heat's messaging library 20:45:50 sure 20:45:56 lol 20:46:00 hehe 20:46:28 tspatzier: is that some sort of acronym? ;) 20:46:47 zaneb, no, then I would write MEAT :-) 20:46:53 * topol zaneb beat me to the acronym joke 20:47:10 * topol need to type faster 20:47:11 jsloyer: I definitely will stay plugged in on those blueprints. 20:48:26 yeah, I think the communication mechanism is important 20:48:40 should we wind up the meeting? 20:48:43 aye 20:48:48 yip 20:48:56 thanks all, we can continue in #heat 20:49:01 #endmeeting