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