20:01:10 <asalkeld> #startmeeting heat
20:01:10 <openstack> Meeting started Wed Jan  9 20:01:10 2013 UTC.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:14 <openstack> The meeting name has been set to 'heat'
20:01:38 <SpamapS> o/
20:01:43 <asalkeld> #chair asalkeld sdake_z stevebaker shardy
20:01:44 <openstack> Current chairs: asalkeld sdake_z shardy stevebaker
20:02:14 <stevebaker> ok
20:02:17 <asalkeld> o/
20:02:22 <shardy> o/
20:02:22 <stevebaker> #topic rolecall
20:02:24 <Slower> o/
20:02:33 <sdake_z> sdake
20:02:39 <shardy> shardy here
20:02:42 <jpeeler> jpeeler here
20:02:47 <Slower> imain
20:02:56 <shadower> shadower here
20:03:14 <stevebaker> #topic Review last week's actions
20:03:25 <stevebaker> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-01-02-20.00.html
20:03:45 * stevebaker asalkeld to setup heat-cfntools git repo (asalkeld, 20:06:02)
20:03:47 <stevebaker> done
20:03:57 * stevebaker investigate injecting heat-cfntools install during cloud-init (stevebake, 20:45:59)
20:04:30 <stevebaker> oh, thats me
20:05:07 <stevebaker> I haven't looked at heat's cloud-init code yet, but this should be possible
20:05:24 <stevebaker> I still want image building to be so easy that everybody spins their own images
20:06:02 <SpamapS> or just uses official images 90% of the time
20:06:11 <sdake_z> both those options make sense
20:06:11 <stevebaker> yes
20:06:17 <sdake_z> trick is getting cfn tools in the 90% images ;)
20:06:22 <shardy> stevebaker: What's difficult about image building atm?
20:06:44 <asalkeld> time
20:06:45 <SpamapS> I've found it quite easy. Just stick the files in /opt/aws and it works.
20:06:50 <stevebaker> the time it takes, having bare metal available to do it
20:06:57 <stevebaker> shardy: ^^
20:07:19 <SpamapS> It should be a hard requirement that these tools only use python stdlib components, so it remains easy
20:07:20 <sdake_z> with stevebake's suggestion of injecting cfn into the image launch, additional requirement that a network host be available to serve them up
20:07:34 <sdake_z> but as an additional option makes sense
20:07:39 <stevebaker> SpamapS: it currently depends on python-boto
20:07:48 <SpamapS> is that new?
20:07:48 <shardy> stevebaker: That's an oz not heat problem tho, and if we package cfntools, then we no longer have to care (much) about image building
20:07:57 <SpamapS> or did I just not use the boto-requiring bits?
20:07:58 <shadower> sdake, I think you can base64 encode the data into the template
20:08:10 <sdake_z> 16k limit on user data
20:08:10 <shadower> the file cfn-tools files contentts I mean
20:08:14 <shadower> right
20:08:22 <stevebaker> shardy: do you think python-boto can be removed as a dependency?
20:08:36 <SpamapS> +1 for making them available in the same way any other apt-get/yum installable package is available.
20:08:48 <asalkeld> agree
20:08:53 <shardy> stevebaker: yes, but not that easily
20:08:53 <sdake_z> agree as well
20:09:02 <asalkeld> (yum/apt-get install)
20:09:06 <shadower> yup
20:09:15 <sdake_z> although dont see a strong incentive to take away jeos toolset
20:09:23 <shadower> weren't people against this the last time? apt/yum
20:09:25 <stevebaker> I've been working on packaging rpm and deb
20:09:38 <shardy> stevebaker: bascically we'd have to maintain our own internal client library for CFN and Cloudwatch
20:09:54 <asalkeld> shadower, well I'd be happy with pip install too
20:09:55 <stevebaker> rpm is done http://repos.fedorapeople.org/repos/heat/heat-trunk/
20:10:15 <stevebaker> completely untested PPA is here https://launchpad.net/~steve-stevebaker/+archive/heat-cfntools
20:10:29 <SpamapS> pip is fine too
20:10:46 <SpamapS> the point is, using regularly available methods means less problems with proxies/restrictions/down servers.
20:10:54 <sdake_z> over the long term when heat becomes standard practice, having rpm/deb packages makes it easy for the 90% to prebake the rpms which eliminates the network requirement
20:11:05 <stevebaker> yep
20:11:13 <stevebaker> are there any actions from this topic?
20:12:01 <stevebaker> #topic shadower's configurable cloud backends patches
20:12:07 <SpamapS> seems like there's a need for heat's userdata generation to know where the tools are per-image.
20:12:16 <stevebaker> #link https://github.com/tomassedovic/heat/compare/master...pluggable-clients
20:12:23 <shadower> so
20:12:52 <shadower> with this the users can import a third-party lib for any cloud that lib supports
20:13:07 <shardy> SpamapS: We expect /opt/aws same as AWS cfnbootstrap tools
20:13:26 <SpamapS> Err, I mean where to grab the tools from, not where to put them.
20:13:51 <shardy> SpamapS: Ok, lets discuss later as this is OT now
20:13:55 <SpamapS> agreed
20:14:25 <sdake_z> seems like import would open us up to a potentially larger user base
20:14:37 <asalkeld> shadower, that looks nice
20:14:44 <SpamapS> shadower: this might be related to something I was discussing with stevebaker earlier in #heat. I'd like to be able to put my own private heat engine up in a standing cloud... so a backend I'd be interested in is just Openstack itself, but from a user standpoint rather than service standpoint.
20:14:46 <shardy> sdake_z: Do you see this as any problem re incubation?
20:14:47 <sdake_z> which seems mostly positive to me
20:15:08 <asalkeld> also for large version differences
20:15:49 <sdake_z> shardy hard to predict if this would be a problem with incubation, but i have only heard positive benefits so far
20:15:56 <shadower> so would you guys be interested in merging this?
20:16:04 <shadower> I can send a patch tomorrow
20:16:06 <stevebaker> does this mean all the backends have to fake being openstack clients?
20:16:10 <shadower> yeah
20:16:14 <Slower> yes
20:16:23 <shadower> I wanted to disrupt the Heat codebase as little as possible
20:16:27 <shadower> minimal code changes
20:16:46 <asalkeld> looks like a good addition
20:16:48 <Slower> in practice it doesn't seem to be a big issue
20:17:10 <sdake_z> ya - probably didn't need a meeting to discuss - git  review do the trick ;)
20:17:27 <shadower> shardy, suggested a meeting because of the incubation
20:17:32 <sdake_z> i see
20:17:34 <asalkeld> nice to have some integratioin in horizon
20:17:40 <sdake_z> armchair qb atm
20:17:49 <shardy> Well it's not just the patch
20:18:07 <asalkeld> so we can add say, rackspace
20:18:16 <Slower> I could see some political ramifications, I think it's worth discussing in a meeting
20:18:16 <shardy> it's the wider issue, ie when we rip out Cloudwatch and move to ceilometer, do we maintain the internal implementation because aeolus needs it?
20:18:25 <stevebaker> so the backends would live outside the heat source project? I see no problem with that
20:18:34 <shardy> Same for all the nested stack resources
20:18:42 <Slower> yeah that is a problem
20:18:46 <shadower> stevebaker, unless Heat wants to ship them, yes
20:18:57 <sdake_z> shardy that is a complicated problem that i expect slower/shadower will come up with an equally good solution ;)
20:19:08 <stevebaker> Its not just nova client that needs to be shimmed, also quantum, swift etc
20:19:15 <shadower> yea
20:19:35 <shardy> sdake_z: OK, but that wider issue is why I suggested to shadower it may be worth discussing before posting
20:19:39 <Slower> what about user-pluggable nested stack definitions? :)
20:19:53 <asalkeld> guys think multi-cloud failover
20:20:14 <sdake_z> got it shardy
20:20:20 <stevebaker> So zaneb has started the pluggable resource types, another approach would be sets of AWS resource types with different backends in the implementations
20:20:21 <asalkeld> rather than different types of backends
20:21:00 <shardy> Slower: Well zaneb made the resources pluggable, so maybe not a huge issue, but it does mean we end up maintaining stuff in tree which is not directly related to openstack (when we move to openstack native implementations for stuff like loadbalancers etc)
20:21:30 <Slower> yeah I'd guess that would be up to the people who are wanting different backends
20:21:32 <shadower> asalkeld, if Heat gets integrated with Deltacloud (which is what Slower and I'd like to do), you could have multi-cloud failover
20:21:48 <shadower> since deltacloud speaks multiple clouds already
20:21:50 <stevebaker> this is related to our nested stack solutions vs openstack projects (DBaaS)
20:21:52 <asalkeld> multi == lots
20:21:58 <asalkeld> not different
20:22:38 <stevebaker> shall we bless this solution to hedge our bets? Long term we may do something different
20:22:56 <asalkeld> I think it's fine atm
20:23:00 <sdake_z> works for me
20:23:03 <asalkeld> +1
20:23:20 <shadower> \o/
20:23:22 <stevebaker> #action git review pluggable-clients (everyone)
20:23:28 <Slower> cool :)
20:23:37 <stevebaker> #topic Plan/priorities and key features for g3 cycle
20:23:45 <stevebaker> sdake_z: GO!
20:23:59 <sdake_z> so you may need a monster energy drink to parse: http://wiki.openstack.org/PTLguide
20:24:11 <sdake_z> but couple key points
20:24:28 <sdake_z> blueprints start 4 weeks before H
20:24:40 <sdake_z> which on this schedule: http://wiki.openstack.org/GrizzlyReleaseSchedule
20:24:49 <sdake_z> would be somewhere around the 28th of march
20:24:53 <stevebaker> #link http://wiki.openstack.org/PTLguide
20:25:03 <stevebaker> #link http://wiki.openstack.org/GrizzlyReleaseSchedule
20:25:36 <sdake_z> we should start thinking about blueprints for H around that time, but if you have something now, might as well get it in launchpad
20:25:53 <sdake_z> the key point, if you see the color coded schedule, is that we run off the release cliff feb 28
20:26:02 <asalkeld> we need a H series
20:26:05 <stevebaker> If there is one thing which we could do better for incubation, I think it is creating more blueprints for feature work
20:26:15 <asalkeld> to target the bp's for
20:26:20 <sdake_z> which gives us about 7 weeks to sort out the remaining bugs in g
20:26:43 <shardy> stevebaker: I agree, need brainstorming/ideas prioritisation for new features
20:26:45 <sdake_z> asalkeld agree, i'll add a h series after meeting
20:27:00 <sdake_z> but key point is, we need g to work well - we can push new features into h
20:27:10 <sdake_z> and bunch of bugs = not working well ;)
20:27:29 <sdake_z> I believe there are 4 blueprints currently, which we should wrap up
20:27:35 <stevebaker> shardy: every brain fart should be a blueprint, then we can "prioritise"
20:27:37 <sdake_z> and really try to focus on hardening the code base
20:28:10 <sdake_z> this is different from how we typically operate
20:28:23 <stevebaker> sdake_z: in what way?
20:28:25 <sdake_z> which is make features along the way - the guide states features should be made up front of the 6 month cycle
20:28:32 <shardy> asalkeld: re ceilometer, how close are we feature wise to being able to use ceilometer for out metric store?
20:28:44 <asalkeld> a while  off
20:28:52 <shardy> not the CW API, the metrics/alarms I was thinking
20:29:01 <asalkeld> we are move the rock in there...
20:29:34 <asalkeld> basically eoghan is merging synaps
20:29:40 <asalkeld> bit by bit
20:30:13 <shardy> asalkeld: OK, so definitely a job for H then
20:30:15 <stevebaker> #action Write blueprints for any current and potential future feature development (everyone)
20:30:45 <sdake_z> can target those for h
20:30:54 <sdake_z> we dont have to do that work now, we can wait until march
20:31:01 <asalkeld> sdake_z I see other projects make bp as they need
20:31:02 <stevebaker> sdake_z: any particular development focus for the rest of G?
20:31:05 <sdake_z> we need to make a good g3 now ;)
20:31:34 <sdake_z> well if your out of things to work on, then making new bps may make sense
20:31:42 <sdake_z> we can start this new process during h
20:31:54 <sdake_z> asalkeld ya, maybe ptl guide is wrong ;)
20:31:57 <sdake_z> i'll ask around
20:32:03 <asalkeld> I think that is mainly for discussion at summit
20:32:08 <sdake_z> right
20:32:14 <asalkeld> could be wrong
20:32:16 <sdake_z> get the new ideas for the next 3 milestones out
20:32:23 <sdake_z> so they can have appropriate discussion
20:32:29 <asalkeld> ya
20:32:47 <sdake_z> rather then ninja add features mid release ;)
20:32:50 <stevebaker> that process would apply more to the heterogeneous teams that the other projects have
20:33:07 <stevebaker> they can only decide what to work on face-to-face at summit
20:33:12 <stevebaker> doesn't apply so much to us
20:33:26 <sdake_z> community is growing, we want to support that model
20:33:27 <asalkeld> we are all in the same office;)
20:33:32 <stevebaker> true
20:34:22 <stevebaker> The norm in other projects seems to be large numbers of blueprints, many of which don't make their targetted milestones
20:35:22 <stevebaker> #action Start moving towards the PTL process (sdake)
20:35:40 <sdake_z> difference between writing a bp and implementing
20:35:56 <stevebaker> #topic Open discussion
20:36:41 <stevebaker> Anything else?
20:36:49 <asalkeld> not from me
20:37:00 <asalkeld> SpamapS, ?
20:37:01 <sdake_z> hmm we should probably have a ptl election
20:37:10 <sdake_z> should have had one before original summit
20:37:12 <stevebaker> why yes we should
20:37:20 <sdake_z> need to wait for zane to return to the office
20:37:29 <stevebaker> should we do it at next week's meeting
20:37:42 <stevebaker> give the candidates a chance to campaign ;)
20:37:43 <asalkeld> there is a process
20:37:50 <sdake_z> there is a method
20:37:52 <SpamapS> noting from me at this point :) more next week
20:37:59 <SpamapS> nothing
20:38:05 <asalkeld> ok
20:38:31 <sdake_z> lets wait until zane returns from pto
20:38:37 <sdake_z> which is next week
20:39:59 <stevebaker> alright, it looks like that is id
20:40:01 <stevebaker> it
20:40:21 <asalkeld> yea, back to bed
20:40:30 <stevebaker> #endmeeting