20:00:45 <shardy> #startmeeting heat
20:00:46 <openstack> Meeting started Wed Jul 31 20:00:45 2013 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:49 <openstack> The meeting name has been set to 'heat'
20:00:54 <shardy> #topic rollcall
20:01:04 <shardy> Hi, who's around?
20:01:16 <bgorski> Hi all
20:01:17 <tspatzier> hi
20:01:18 <jasond> here
20:01:19 <timductive> Hello
20:01:22 <zaneb> I'm awake
20:01:22 <kebray> o/ present
20:01:25 <stevebaker> hi
20:01:35 <jpeeler> hey
20:01:36 <topol> hi
20:01:37 <asalkeld> o/
20:02:01 <randallburt> hi all
20:02:21 <shardy> sdake, therve around?
20:02:39 <shardy> Ok lets get started
20:02:45 <shardy> #topic Review last week's actions
20:03:00 <shardy> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-07-24-20.00.html
20:03:07 <jgriffith> #endmeeting
20:03:07 <mrutkows> o/
20:03:24 <shardy> #info shardy to send mission ML statement
20:03:29 <shardy> I didn't actually do that..
20:03:30 <sdake> hi
20:03:33 <shardy> #action shardy to send mission ML statement
20:03:47 <shardy> #info randallburt resource catalog bp grooming
20:03:53 <shardy> randallburt: did that happen?
20:03:54 <randallburt> Resource blueprints per last weeks meeting:
20:03:55 <randallburt> Already in the pipe:
20:03:55 <randallburt> #link https://blueprints.launchpad.net/heat/+spec/resource-properties-schema
20:03:55 <randallburt> New based on meeting minutes:
20:03:55 <randallburt> #link https://blueprints.launchpad.net/heat/+spec/resource-support-status
20:03:55 <randallburt> #link https://blueprints.launchpad.net/heat/+spec/filter-resources-by-support
20:03:55 <randallburt> #link https://blueprints.launchpad.net/heat/+spec/default-resource
20:03:56 <randallburt> Let me know if I've missed anything. The new ones are targeted at heat-next, so there's room for discussion clarification and/or breaking down into smaller chunks
20:03:58 <randallburt> yup
20:04:03 <shardy> lol, pastebomb ;)
20:04:05 <zaneb> btw all I added my competing mission statement proposal to the etherpad
20:04:12 <randallburt> I was ready ;)
20:04:15 <zaneb> which I no longer remember the url of
20:04:16 <shardy> thanks randallburt
20:04:19 <randallburt> np
20:04:38 <radix> d'oh, here
20:04:41 <shardy> #link https://etherpad.openstack.org/heat-mission
20:05:01 <shardy> If anyone else has input to the mission pls add there and I'll try to combine and send something to the ML
20:05:39 <shardy> anything else from anyone from last weeks meeting?
20:05:50 <topol> what is "symbol manipulation"???
20:06:18 <zaneb> topol: symbol manipulation is programming
20:07:06 <shardy> zaneb: I think that's a bit abstract for a mission statement, but I like the second part
20:07:16 <radix> so then "To harness the tools of programming"?
20:07:21 <topol> +1 on being a little too abstract
20:07:47 <topol> what was wrong with the first mission statement???
20:07:58 <sdake> ya a  bit abstract
20:08:11 <shardy> topol: everybody hadn't had their 2c's, clearly ;)
20:08:14 <sdake> mission statement should be direct and in your face
20:08:21 <zaneb> so, I said "symbol manipulation" because I want to include stuff like the Heat Horizon stuff that's being worked on
20:08:23 <randallburt> IMO its got to have the word orchestration in it. The first one seems more direct, IMO.
20:08:24 <asalkeld> serious bikeshedding
20:08:29 <zaneb> i.e. visual symbol manipulation
20:08:45 <topol> randallburt +1
20:08:45 <randallburt> Lets not get fancy and just call it like it is.
20:08:47 <shardy> zaneb: that's part of Horizon's mission, it just happens to be contributed by those interested in Heat
20:09:04 <zaneb> that's true, but we want Heat to be a tool that supports that
20:09:14 <shardy> Lets move on, please add etherpad comments and I'll try to distil tomorrow
20:09:33 <shardy> #topic h3 blueprint prioritization
20:09:48 <shardy> #link https://launchpad.net/heat/+milestone/havana-3
20:10:13 <shardy> So I've been trying to defer some stuff as we had 37 pending bps for h3
20:10:24 <shardy> but we still have 30, and we only delivered 8 for h2
20:10:37 <sdake> h3 = superman time
20:10:42 <shardy> we have about a month before feature freeze, and need time to review stuff
20:11:02 <shardy> so if your BP is not going to land in the next 3 weeks, please tell me and/or defer it
20:11:39 <shardy> This plan has already been called crazy unrealistic by ttx, so we probably need to bump and deprioritize quite a lot of stuff
20:12:06 <stevebaker> I remain unrealistically optimistic!
20:12:12 <zaneb> lol
20:12:26 <radix> are all 30 of them assigned?
20:12:27 <radix> I guess so
20:12:51 <sdake> lol stevebaker
20:12:56 <topol> thats a lot of symbolic manipulation left to go
20:13:01 <randallburt> lol!
20:13:11 <shardy> Ok, well I won't go through it all now, but also please make sure the Implementation is set, if stuff is "Not Started", I'm gonna start bumping to heat-future
20:13:45 <shardy> Any comments or questions on H3 or the release schedule?
20:13:49 * radix changes his to Good Progress, hopefully that's accurate :)
20:14:02 <shardy> #link https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:14:39 <stevebaker> shouldn't multiple-engines be marked as started and assigned to !asalkeld
20:15:01 <asalkeld> someone else has started on it
20:15:12 <randallburt> jasond:  is looking into it
20:15:14 <shardy> who's taken that, was it jasond?
20:15:22 <shardy> Ok, I'll reassign
20:15:23 <asalkeld> (cool by me)
20:16:13 <asalkeld> I'll jump in and help as soon as I am done with this monitoring stuff
20:16:40 <sdake> perhaps we should jsut remove multiple engines from h3
20:16:43 <sdake> and focus on that for all of I
20:16:59 <stevebaker> it is being worked on
20:17:01 <jasond> asalkeld: cool, i'm keeping notes on my progress here http://dunsmor.com/heat/multi-engine.html
20:17:02 <sdake> ok
20:17:03 <shardy> Ok, cool, well lets move anything which looks at all unlikely to heat-future, better to pull them back into the plan than to defer everything late ;)
20:17:05 <randallburt> not a horrible idea, though I think there's progress to be made in the next few weeks
20:17:22 <asalkeld> agree
20:17:30 <asalkeld> lets do what we can
20:17:35 <randallburt> agreed
20:17:40 <sdake> asalkeld had a good idea for mvoing everything into the api and getting rid of the engine, think that makes sense for i :)
20:17:51 <randallburt> we can "reduce" scope and have new, focused tasks for I
20:18:17 <shardy> Yeah, moving target, we can defer and raise smaller sub-bp's if needed
20:18:27 <zaneb> sdake: I don't agree, I bet nova wishes they had our architecture right now
20:19:01 <randallburt> you know, we could just make everything a celery task and…
20:19:06 * randallburt ducks
20:19:09 <sdake> more deps ugh
20:19:10 <shardy> randallburt: nooo! ;)
20:19:20 <shardy> anyway, onwards..
20:19:35 <shardy> #topic Removal/moving of heat-boto/heat-cfn/heat-watch client tools
20:19:43 <sdake> so missed last weeks meeting
20:19:45 <sdake> my apologies
20:19:51 <sdake> i think we are sorted here with stevebaker and I
20:20:00 <sdake> plan is to move everything into heat-cli
20:20:02 <shardy> sdake: we did discuss this, but I wanted to make sure we've agreeed a way forward
20:20:04 <sdake> and not package the boto/etc
20:20:22 <sdake> as long as boto/heat-cfntools/heat-watch are not the only things in a repo, wea re good to go
20:20:38 <asalkeld> are we putting it into stackforge
20:20:44 <sdake> ya stackforge ++
20:20:57 <asalkeld> and what else is going to be in the repo
20:21:14 <sdake> if its in stackforge I have no objections re packaging
20:21:20 <asalkeld> ok
20:21:20 <stevebaker> yes, stackforge. I need to refresh the review
20:21:27 <shardy> Ok, but all that's going to be in there is heat-boto?
20:21:36 <sdake> heat-watch, heat-cfn
20:21:38 <shardy> as we were going to remove heat-cfn, based on discussion last week
20:21:48 <sdake> i see
20:21:54 <stevebaker> yes, eventually, it is just a code move as the first step
20:21:55 <shardy> heat-watch will die after CM integration finished
20:21:56 <randallburt> posterity?
20:22:08 <shardy> heat-boto can replace heat-cfn (it's actually the same code)
20:22:14 <randallburt> ah
20:22:21 <shardy> so do we need a new repo for one CLI tool?
20:22:33 <shardy> can't it just stay in master, e.g in tools?
20:22:34 <asalkeld> README: unmaintained dev tools
20:22:48 <sdake> master in tools wfm too
20:22:57 <stevebaker> *sigh*
20:22:57 <jpeeler> +1
20:23:00 <shardy> Seems easier than new repo, stackforge etc
20:23:05 <sdake> feels like a alot of wasted work for stevebaker tho
20:23:12 * sdake sorry stevebaker for suggesting it in the first place
20:23:16 <shardy> stevebaker: what's your objection?
20:24:04 <asalkeld> (he is busy head slamming)
20:24:09 <stevebaker> Its all done, I'm happy to do a python release.
20:24:14 <shardy> lol
20:24:36 <sdake> asalkeld hopefully just face palming :)
20:24:45 <asalkeld> yeah:)
20:24:48 <kebray> this may be a dumb question, but what does Boto do that Heat doesn't already do or have included in its own CLI/API?
20:24:53 <shardy> stevebaker: I'm just not sure who will use it, we should encourage people to use the one-true python-heatclient
20:25:02 <sdake> kebray apparently it has high quality debugging functionality :)
20:25:05 <shardy> kebray: nothing
20:25:17 <asalkeld> (it is maintained)
20:25:21 <shardy> but it is a useful dev/debug tool for the CFN compatible API
20:25:29 <kebray> Heat isn't maintained?   How many of us are here in IRC?
20:25:29 <asalkeld> we don't want to maintain that code
20:25:33 <shardy> it's of no use to end users at all
20:25:40 <stevebaker> only heat core developers will use it likely - I really don't see the problem with a new repo
20:25:48 <asalkeld> (just the aws client)
20:25:51 <randallburt> and boto should just work. why maintain two implementations of the same thing
20:26:03 <sdake> new repo is preferrable - get it out of the code base that gets packaged
20:26:05 <shardy> If only heat core developers will use it, surely it's more convenient to leave it in master?
20:26:21 <shardy> sdake: It can be in the tarball/master and not get packaged
20:26:23 <zaneb> kebray: it's meaningless to say we can write a client that works with our own cfn-compatible api. we want it to actually be compatible
20:26:50 <sdake> like I said, master tools not packaged wfm too
20:26:52 <stevebaker> they have zero test coverage. having it in the core repo is a form of endorsement that they should be consumed by users
20:26:57 <kebray> zaneb:  but, "our" client could also interact with CFN, thereby showing it is compatible.
20:27:00 <asalkeld> I think we spent way too much time deliberating
20:27:02 <kebray> one client.. why two?
20:27:19 <sdake> why not three?
20:27:20 <sdake> ;)
20:27:36 <kebray> anyway.. I am probably missing context.. I can take this to the main heat channel.
20:27:44 <shardy> kebray: one client talks to heat-api (python-heatclient), one talks to heat-api-cfn (heat-boto)
20:27:45 <zaneb> kebray: but it never has, and why would we invest time in doing that when boto exists?
20:28:06 <shardy> boto has six *million* downloads from pypi:
20:28:19 <shardy> why would we reinvent our own AWS client lib?
20:28:21 <kebray> ah… ok, context cleared.  makes sense now.
20:29:05 <shardy> Ok, lets move on
20:29:43 <shardy> #topic Reorganize heat-templates repo into per-distro directories for F17/F18/F19/U12/RHEL
20:29:50 <sdake> yes
20:29:56 <randallburt> sounds good to me
20:29:57 <sdake> so right now our tempaltes don't work on f18-f19
20:30:05 <sdake> and templates don't work cross distro
20:30:13 <sdake> so make a top level distro dir in the cfn dir
20:30:22 <sdake> and put the templates in the correct dirs
20:30:24 <shardy> Sounds reasonable, but could end up being a lot more maintenance overhead
20:30:26 <sdake> and work to update our tempaltes
20:30:37 <shardy> considering we can't/don't really maintain what we have all that well..
20:30:39 <sdake> well we aren't maintaining them at all now
20:30:39 <asalkeld> at somepoint our hot templates should be distro agnostic
20:30:41 <sdake> this would force that
20:30:56 <stevebaker> it seems that there is a good case for reorganising by heat release (grizzly, havana...)
20:30:57 <sdake> asalkeld at that point we could revisit this decision
20:31:01 <kebray> Isn't the goal to soon get to cross-distro templates?
20:31:21 <randallburt> asalkeld:  well, they *could* be written that way. I hope we don't lose flexibly in that regard.
20:31:23 <shardy> sdake: the templates shouldn't change between releases (the CFN ones at least..)?
20:31:40 <asalkeld> I think we need to seperate out the guest config somehow
20:31:46 <sdake> f18 for example adds some firewalld stuff
20:31:47 <randallburt> kebray:  sure, but not *all* templates have to be cross distro. For some that's not even desireable
20:31:53 <sdake> this means all our f17 templates dont' work on f18/f19
20:31:58 <sdake> they dont' work on rhel, even though rhel is an image type
20:31:59 <sdake> etc
20:32:07 <sdake> they are just generally poorly maintained
20:32:14 <sdake> maybe that is an orthognal discussion :)
20:32:27 <shardy> sdake: one alternative would be to do better at keeping them working on latest-stable of e.g Fedora
20:32:49 <sdake> yes but we have hard time tracking which ones we have sorted on the latest distro vs those that dont
20:32:56 <sdake> whereas with dirs, if its in the f19 dir, its been tested
20:32:59 <shardy> sdake: if they are generally poorly maintained, how will adding more help?
20:33:07 <asalkeld> (I think it's a good plan, but we should try to make them more portable too)
20:33:11 <sdake> the f17 templates were miantined well
20:33:22 <sdake> but we never went back and ported them to f18/f19
20:33:24 <sdake> we need to do that
20:33:36 <shardy> Ok, well we can try it and see how it works out I guess :)
20:34:18 <sdake> the only thing that brought this up is I have been putting the distro in templates I write
20:34:21 <sdake> in the filename
20:34:25 <sdake> to help indicate what it works on
20:34:29 <sdake> directory makes more sense
20:35:07 <zaneb> +1 for trying that
20:35:18 <sdake> for trying which?
20:35:18 <asalkeld> maybe impl. zanes Fn::File idea to be able to put userdata/metadata
20:35:27 <asalkeld> in different files
20:35:45 <asalkeld> so the main template is portable
20:35:48 <shardy> sdake: well lets try it for the cfn example templates, and aim to have the HOT templates more portable via the software config abstraction discussed in software-configuration-provider
20:35:59 <sdake> wfm
20:36:01 <asalkeld> +1
20:36:07 <zaneb> trying the different directories
20:36:08 <sdake> we can always revisit when hot goes live
20:36:27 <shardy> Ok, cool, any other comments on this or shall we move on?
20:36:36 <asalkeld> on and up
20:36:36 <stevebaker> I still think the top level directory of heat-templates should relate to the audience of who will be using
20:36:37 <sdake> i'll work out the move patch
20:37:05 <sdake> stevebaker could you expand?  You mean havana/griz/etc?
20:37:58 <stevebaker> as in demonstration of features (wordpress 10 ways...), production templates for specific apps, templates for testing only...
20:38:32 <sdake> atm I think we would end up with demo templates only atm :)
20:38:33 <shardy> stevebaker: The problem with that is then we're not just providing examples, but people will expect "production ready" application templates
20:38:36 <sdake> but seems like a good idea to me
20:38:54 <shardy> heat-core don't want that responsibility IMO
20:39:10 <shardy> but others interested in that could contribute to heat-templates I guess
20:39:13 <sdake> shardy agree - should be community responsibility
20:39:15 <stevebaker> anything flagged as a production template will be adopted by someone to keep it that way
20:39:21 <randallburt> I think we should be pretty explicit that we're providing examples of features, not something one hangs their hats on
20:39:24 <sdake> I have read several blogs people want  to build businesses just making templates
20:39:26 <shardy> which I think is what we discussed when we separated the templates into their own repo
20:39:48 <randallburt> they should *work* sure, but not have to be bullet proof examples of how to deploy wordpress
20:40:01 <sdake> i think our examples should all work well
20:40:06 <shardy> stevebaker: So we'd need process to align templates with maintainers etc
20:40:08 <sdake> and wordpress seems like a simple app to deal with
20:40:12 <kebray> randallburt:  I disagree… there should be at least a couple templates the Heat dev team guarantees work, and has real world value… more than just demonstration.
20:40:15 <randallburt> for a very mangaged definition of "well"
20:40:18 <shardy> long term, good plan, short term too much effort IMHO
20:40:26 <randallburt> shardy:  agreed.
20:40:33 <topol> is there a contrib directory where folks can contribute production templates or other templates?
20:40:34 <kebray> At least for the short term… to help adoption.
20:40:52 <shardy> topol: that has been discussed but not yet
20:40:57 <sdake> topol they can just do a review request for the cfn dir
20:41:06 <kebray> We need to build an ecosystem… not just a tool.
20:41:16 <topol> kebray +1
20:41:30 <shardy> we could add one, and put a README in there saying they're community maintained
20:41:40 <asalkeld> yea
20:42:28 <randallburt> but we still need to be diligent then on stuff that stops being maintained. othewise #heat gets flooded with support requests for templates that don't have anyone riding herd on them
20:42:52 <shardy> randallburt: That is basically my worry too
20:42:54 <kebray> randallburt:  agreed… the list should be small.
20:43:02 <shardy> Anyway, shall we move on and follow up on the ML?
20:43:08 <stevebaker> yep
20:43:09 <shardy> #topci Open Discussion
20:43:11 <randallburt> sounds good
20:43:21 <zaneb> topci?
20:43:21 <shardy> #topic Open Discussion
20:43:32 <shardy> zaneb: fat fingers ;)
20:43:37 <stevebaker> anything for me? I need to go do the school run
20:43:47 <sdake> jasond had a complaint about the cloudinit-write-files bp
20:44:01 <shardy> sdake: complaint?
20:44:12 <shardy> stevebaker: o/
20:44:15 <sdake> apparently write-files doesn't work with cloudinit0.6
20:44:16 <kebray> Topic:  removal of AWS stuff… I know HOT solves a lot of that.. but, I think there's still a reference to AWS in the UserData section with heat-cfn… no?
20:44:21 <jasond> it depends on cloud-init 0.7 now, which broke the cloud server resource
20:44:40 <jasond> so are we officially discontinuing support for cloud-init 0.6?
20:44:43 <stevebaker> does that mean ubuntu is broken too?
20:44:44 <randallburt> kebray:  which should remain for compatability unless/until native tooling gets sorted (IMO)
20:44:47 <jasond> stevebaker: yes
20:44:48 <shardy> sdake: hmm, so which distro's is that a problem for?
20:44:51 <sdake> ya u12.04 broke
20:44:52 <stevebaker> ouch
20:44:55 <sdake> rhel6.4
20:44:58 <sdake> f17
20:45:00 <jasond> CentOS 6.4
20:45:06 <stevebaker> hmm, might have to back that out
20:45:10 <zaneb> nothing important then :D
20:45:11 <shardy> No RHEL 6.4 is 0.7.1
20:45:18 <sdake> ya I tend to agree re backout
20:45:23 <jasond> shardy: not the package in EPEL
20:45:35 <sdake> although I like the change, perhaps an optional feature
20:45:38 <shardy> F18+ is 0.7.2, F17 is nearly EOL (or is?)
20:45:44 <sdake> f17 is eol
20:45:52 <shardy> jasond: It's in RHEL common for RHEL 6
20:45:56 <randallburt> agreed, its a good change, just breaks with some older but still "supported" distros
20:46:07 <jasond> shardy: i'll check
20:46:10 <shardy> jasond: So in theory should be removed from EPEL at some point
20:47:57 <sdake> so question I think this centers around , is what is the lowest level of cloudinit we intend to marry ourselves to with heat for grizzly
20:48:16 <shardy> sdake: s/grizzly/havana?
20:48:20 <randallburt> havana? or was this going to be back ported?
20:48:20 <sdake> sorry havana
20:48:28 <sdake> brain damage :)
20:48:31 <shardy> If so then I say 0.7.2
20:48:50 <shardy> F18+ and RHEL 6.5+, not sure about Ubuntu, we'll need to check
20:48:54 <sdake> this makes ubuntu 12.04 non-functional
20:49:13 <shardy> sdake: even with the cloud-archives repos?
20:49:22 <sdake> not sure about cloud-archives repo
20:49:58 <shardy> Ok, well we can follow up and investigate I guess
20:50:27 <jasond> i don't see it http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/c/
20:50:28 <shardy> there were several fixes which we need related to metadata retrieval, which means 0.7.2 works and 0.7.1 in some cases doesn't
20:50:29 <sdake> well if it should be reverted, can you file a bug shardy and assign to me
20:51:43 <shardy> Ok, yeah jasond pls raise a bug with details and we'll work out what to do
20:51:51 <shardy> anyone have anything else?
20:51:53 <jasond> shardy: will do
20:52:21 <bgorski> I have aquestion about bp with multi region support
20:52:36 <shardy> bgorski: ok
20:53:22 <bgorski> I updated the wiki page accordingly with the ML discussion
20:53:42 <bgorski_> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
20:54:33 <bgorski> And one big problem I see right now is that the only way right now to pass template for nested stack is by url
20:55:24 <zaneb> bgorski: I replied to your ML post already
20:55:35 <zaneb> short version: you are SOL
20:55:37 <zaneb> sorry :(
20:56:29 <zaneb> randallburt: is one of the blueprints floating around covering the {"File": ...} feature?
20:56:39 <randallburt> zaneb:  not to my knowlege
20:56:52 <zaneb> maybe that needs to be number 31
20:56:58 <randallburt> IIRC it was discussed on the ML, but not bp afaik
20:57:06 <randallburt> asalkeld?
20:57:15 <asalkeld> hello
20:57:21 <shardy> Files section of environment?
20:57:22 <randallburt> IIRC, you're working on template upload?
20:57:34 <randallburt> is that what we mean or something different?
20:57:42 <asalkeld> well it's not a part of the env really
20:57:56 <stevebaker> back
20:58:03 <asalkeld> but we need the client to read the template
20:58:16 <asalkeld> and slurp the File's
20:58:28 <shardy> I think this is a deployer problem, not a heat problem
20:58:39 <shardy> provide a template repo with http access, sorted..?
20:59:00 <randallburt> there are a couple of bps for that
20:59:12 <zaneb> shardy: that's a weak answer
20:59:16 <shardy> anyway probably can't discuss it in 2mins, so we can follow up on the ML
20:59:20 <randallburt> somewhat controversial, but they're out there
20:59:35 <asalkeld> shardy, this would help with Metadata: {Fn::File: {Ref: Distro}}
20:59:37 <shardy> zaneb: maybe, but we don't, IMHO want Heat to become a general-purpose template store
20:59:38 <bgorski> we can continue on ML
20:59:51 <zaneb> shardy: totally agree, we should not be storing them
20:59:55 <shardy> thanks all
21:00:00 <shardy> #endmeeting