20:00:02 <asalkeld> #startmeeting heat
20:00:03 <openstack> Meeting started Wed Jan  2 20:00:02 2013 UTC.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:06 <openstack> The meeting name has been set to 'heat'
20:00:43 <asalkeld> #chairs shardy asalkeld stevebake jpeeler
20:01:02 <stevebake> http://wiki.openstack.org/Meetings/HeatAgenda
20:01:09 <asalkeld> #chair shardy asalkeld stevebake jpeeler
20:01:10 <openstack> Current chairs: asalkeld jpeeler shardy stevebake
20:01:54 <asalkeld> stevebake, you want to run the show, my fingers are sore?
20:02:05 <stevebake> yep
20:02:11 <asalkeld> (or anyone else)
20:02:16 <stevebake> #topic Review last week's actions
20:02:32 <stevebake> zaneb start an email discussion on where to keep cfn-tools for easy install
20:02:38 <stevebake> which leads into
20:02:47 <stevebake> #topic Steve's cfntools work
20:03:18 <asalkeld> looked good to me stevebake
20:03:24 <stevebake> So hopefully you've read my email.
20:03:47 <asalkeld> yip
20:03:47 <stevebake> https://github.com/steveb/heat-cfntools is a fork of heat-jeos
20:04:05 <stevebake> I've been playing with ubuntu packaging in https://github.com/steveb/heat-cfntools/tree/ubuntu-ppa
20:04:10 <shardy> Looked good to me, apart from the comments about moving to imagefactory - I don't think there's any rush to do that as the IF openstack support still needs some imrpovement IMO/IME
20:04:54 <shardy> stevebake: Have you spoken to zigo (debian packager of heat)?
20:05:06 <asalkeld> good idea
20:05:49 <stevebake> so for imagefactory, redhat has allocated an internal server which has imagefactory installed
20:06:02 <asalkeld> #action asalkeld to setup git repo
20:06:30 <stevebake> I've got root on it now, so I'll have a play with it. But I'll come up with a heat-jeos that still works with oz
20:06:38 <shardy> stevebake: there are several problems, not least that it only supports raw disk images, which makes launching instances horribly slow
20:06:51 <shardy> I sent some patches but they need some review rework
20:06:52 <stevebake> does it use an old branch of oz?
20:07:19 <shardy> and there are other problems which I've not yet fixed up (like a horrid non-sparse copy which writes ~9GB of zeros)
20:07:26 <stevebake> ooo
20:07:54 <shardy> The problems are in the imagefactory code, fairly easy stuff to fix but it's been low priority since I looked at it a few weeks back
20:08:05 <stevebake> ok, I'll dial back the imagefactory integration and focus on the tdls for packaged heat-cfntools
20:08:28 <shardy> As I said, good long term goal, but it should be a background task IMO
20:08:33 <stevebake> cool.
20:09:29 <asalkeld> you want the repo to be called "heat-cfn" or "heat-cfntools" ?
20:09:41 <stevebake> I'll let zigo know that heat-cfntools needs packaging so debian can be used as a heat jeos image
20:10:16 <stevebake> I have no strong feelings, heat-cfntools is fine by me
20:10:17 <shardy> asalkeld: I'd say heat-cfntools, to avoid confusion with the heat-cfn tool
20:10:38 <shardy> stevebake: Sounds good
20:11:05 <stevebake> so the tools are installed in /opt/aws/bin, I assume we shouldn't change that
20:11:22 <asalkeld> https://github.com/heat-api/heat-cfntools
20:11:26 <asalkeld> done
20:11:30 <stevebake> sweet
20:12:23 <stevebake> #topic Fedora packaging
20:12:33 <shardy> stevebake: I think we need to keep that path to keep things the same as the aws cfnbootstrap paths
20:13:20 <asalkeld> agree
20:13:24 <stevebake> yep. currently the ubuntu packaging also installs in /usr/bin. Technically that is a bug but I wonder if it should be promoted to a feature
20:13:46 <asalkeld> we could add softlinks?
20:14:32 <asalkeld> problem is people with templates with full paths
20:14:37 <stevebake> it all gets deleted if the package is removed, so it probably doesn't make much difference
20:14:40 <shardy> stevebake: we really need to keep things compatible with the aws tools, so that eventually we might be able to import/boot an aws AMI or an image with the AWS tools
20:15:19 <stevebake> yep, definitely keep aws compatibility
20:15:28 <asalkeld> good
20:16:09 <stevebake> http://repos.fedorapeople.org/repos/heat/heat-trunk/ has the packages built from https://github.com/steveb/heat-rpms
20:16:38 <shardy> stevebake: did you say you were going to automate nightly builds?
20:16:54 <stevebake> There is some fairly radical changes to https://github.com/steveb/heat-rpms/blob/master/Makefile so I wanted to make sure its all good.
20:17:15 <stevebake> shardy: That is the aim, yes
20:17:24 <shardy> Cool
20:17:41 <asalkeld> I do like that the openstack version seems to work
20:17:59 <stevebake> their snapshots?
20:18:04 <asalkeld> 2013.1dev-20121228.fc18.noarch.rpm
20:19:04 <stevebake> For g-2 we should create a new repo http://repos.fedorapeople.org/repos/heat/heat-grizzly
20:19:53 <shardy> has anyone done much testing on grizzly? I'm still mostly running folsom
20:19:53 <stevebake> and maybe symlink heat-stable to heat-grizzly.
20:20:26 <stevebake> not packages, but I do everything on devstack
20:20:44 <shardy> ok, cool, so we have some test exposure then, good :)
20:21:04 <asalkeld> me too (devstack)
20:21:21 <asalkeld> next topic?
20:21:22 <stevebake> Our repo may need to include python-extras since it is not packaged anywhere
20:21:40 <stevebake> #topic Ubuntu packaging
20:22:02 <asalkeld> zigo is the dude there
20:22:29 <asalkeld> stevebake, you probably need to keep in touch with him
20:22:31 <shardy> asalkeld: what are your thoughts about our release/branch model wrt ceilometers, they branch for each openstack release, but we maintain backwards-compatibility via hacks in the code?
20:23:03 <shardy> asalkeld: It is worth avoiding any mention of Ubuntu when talking to zigo ;)
20:23:09 <asalkeld> well, you can branch at any time
20:23:12 <stevebake> Still no debian uploads visible. zigo is at the mercy of the debian upload process, and ubuntu packaging can't start until it happens
20:23:31 <asalkeld> as long as you tag the version
20:24:19 <asalkeld> but making a branch for say, grizzly seems a good idea to me
20:24:35 <asalkeld> but not g1,g2 etc
20:24:47 <stevebake> no, one grizzly branch
20:25:21 <asalkeld> there is probably a best practice on the wiki
20:25:23 <shardy> asalkeld: Yeah, I'm unsure of the best way to approach it as we're not all running devstack, but it seems like we're getting quite a few conditional kludges in the code, and not sure if a stable branch makes sense or not
20:25:25 <stevebake> we might do more than one g2 release? for brown-paper-bag or major bugs?
20:26:28 <asalkeld> stevebake, as I said you can always create a branch later if you need
20:26:42 <asalkeld> but assume not for starters
20:26:59 <stevebake> Whatever we do, for incubation the priority is to make it work best on current grizzly. That is what we will be judged on
20:27:30 <asalkeld> yip
20:27:57 <stevebake> ah, one thing we should use branches for is heat-rpms. Definitely do a grizzly branch there
20:28:19 <asalkeld> the other long term approach to this is to have different drivers for each openstack release
20:28:27 <stevebake> master heat-rpms will build the nightly packages, grizzly branch will do the stable ones
20:28:56 <asalkeld> so have different resources for different major versions
20:29:11 <stevebake> separately packaged
20:29:12 <asalkeld> but basically means fail to the python-client
20:29:45 <asalkeld> sounds good stevebake
20:30:34 <stevebake> shardy: once packages are easily consumable, how about changing the openstack script to also install and configure heat?
20:30:54 <shardy> stevebake: Sounds like a great idea
20:31:00 <asalkeld> http://wiki.openstack.org/BranchModel?highlight=%28branching%29
20:31:45 <stevebake> and then *finally* we can update the docs with some nice instructions
20:31:53 <shardy> stevebake: Although I think we want to move away from that script to packstack at some point
20:32:07 <shardy> for Fedora that is
20:32:19 <stevebake> yep
20:32:40 <asalkeld> does packstack do erase?
20:32:41 <stevebake> #JEOS building
20:32:46 <stevebake> #topic JEOS building
20:32:49 <shardy> asalkeld: not yet, no
20:32:54 <shardy> AFAIK that is
20:32:57 <asalkeld> https://github.com/openstack/glance/branches
20:33:24 <asalkeld> stable/{folsom, essex, diablo}
20:33:55 <stevebake> sdake wrote a script to build all the tdl images and upload them to github, and github has now discontinued that uploads feature
20:34:09 <asalkeld> groan
20:34:48 <stevebake> We've been given a space on fedorapeople. No backups, no quota. http://fedorapeople.org/groups/heat/
20:35:03 <stevebake> we could use that as our prebuilt images repo
20:35:58 <asalkeld> yea
20:36:29 <shardy> asalkeld: that's basically what I was getting at when I said branching earlier, but not sure if the backport effort is justified for us yet
20:36:48 <stevebake> It seems like as good a place as any
20:36:52 <asalkeld> so what is missing from the fedora ami's
20:36:59 <shardy> stevebake: Sounds good, lack of access to that github repo has been a pain so good to have somewhere we can all access
20:37:10 <asalkeld> and http://uec-images.ubuntu.com/quantal/current/
20:37:16 <asalkeld> just the cfntools?
20:38:23 <shardy> asalkeld: do those images have cloud-init?
20:39:02 <asalkeld> I would assume so
20:39:12 <asalkeld> they are built for amazon
20:39:27 <shardy> I guess we need to do some testing with the new packaged heat-cfntools and see if it works
20:39:30 <asalkeld> but I don't know for certain
20:39:56 <asalkeld> yea, it would be nice not to need this image building at all
20:39:59 <stevebake> once I get some images uploaded somewhere I'll put out the call for testing
20:40:59 <stevebake> asalkeld: are you suggesting modifying heat templates to install heat-cfntools package?
20:41:17 <asalkeld> yea (or do it in the background)
20:42:19 <asalkeld> if it is easy to do, it would make life easier
20:42:57 <stevebake> I'd like image building to be so easy, everyone has customised images with their own pre-loaded packages
20:43:28 <asalkeld> stevebake, prehaps but others just want a jeos
20:43:50 <asalkeld> and it's silly re-making what already exists
20:44:06 <stevebake> so how would doing it in the background work?
20:44:29 <shardy> just inject it via nova user-data for cloud-init
20:44:40 <asalkeld> well if we can insert a cloud-init script to call rpm  install
20:44:56 <asalkeld> that runs before userdata
20:45:12 <asalkeld> seems easy enough
20:45:30 <asalkeld> I hate image building
20:45:41 <asalkeld> seldom works for me
20:45:59 <stevebake> #action investigate injecting heat-cfntools install during cloud-init
20:46:12 <asalkeld> to me it's a barrier to adoption
20:46:38 <asalkeld> serious users will want their own images
20:46:55 <stevebake> yeah, although up to date downloadable images would help
20:47:14 <asalkeld> yip
20:47:31 <stevebake> In our tdls, there is this:
20:47:34 <stevebake> yum -y update fedora-release
20:47:41 <stevebake> is that really required?
20:47:58 <asalkeld> not sure
20:48:34 <asalkeld> steve said at some point yum update was misbehaving
20:48:44 <asalkeld> and needed 2 stages
20:49:32 <stevebake> oh, ok. The TDL spec has specific support for repos and packages, I was hoping to use that instead of <command/> blocks
20:50:50 <stevebake> #topic Grizzly-2 release
20:51:07 <stevebake> Its on the 10th
20:51:24 <asalkeld> that is soon
20:52:01 <shardy> I started getting the functional tests going today, so we can potentially use them to help automate the pre-release testing
20:52:28 <stevebake> https://launchpad.net/heat/+milestone/grizzly-2
20:52:53 <shardy> Anyone aware of any reasons why we shouldn't release next week?
20:53:11 <asalkeld> no, all looks good
20:53:18 <shardy> everything looking fairly OK to me too
20:53:25 <asalkeld> I have a blueprint there
20:53:28 <stevebake> nope, we've been focused on stability for a while
20:53:56 <stevebake> asalkeld: want to push it to g-3?
20:53:58 <asalkeld> I might just move that to g3
20:54:00 <asalkeld> ya
20:54:20 <asalkeld> done
20:55:13 <stevebake> if ttx is around we could find out what the release will involve
20:55:39 <shardy> 1083613 looks like notabug based on ppetits comment
20:56:17 <stevebake> close it I guess
20:56:33 <asalkeld> yip
20:56:41 <shardy> done, and cleared the milestone
20:56:47 <asalkeld> we have 4 mins left
20:56:59 <stevebake> #topic general discussion
20:57:20 <asalkeld> nothing from me
20:57:21 <shadower> fyi, my FOSDEM talk has been accepted so I'll be showing Heat there
20:57:28 <shardy> Do we need a release manager to turn the handle on the release like previously?
20:57:30 <asalkeld> nice
20:57:40 <shardy> I can do it if so, think it's probably my turn
20:57:42 <asalkeld> probably
20:57:50 <stevebake> oh, and I'm co-presenting with Angus at LCA
20:58:01 <asalkeld> sounds good shardy
20:58:02 <shardy> shadower: sounds good
20:58:25 <asalkeld> yea, stevebake we need to schedule some time for that
20:58:31 <asalkeld> (prep)
20:58:50 <stevebake> shardy: does that mean packaging as well? we need to check that you can build and push to the new repos
20:59:01 <stevebake> asalkeld: hell yes
20:59:27 <shardy> stevebake: perhaps we can sort the packaging between us, and I'll coordinate the testing and any other tasks?
20:59:40 <stevebake> shardy: sounds good
20:59:55 <shardy> http://wiki.openstack.org/Heat/ReleaseProcess
21:00:26 <asalkeld> need to make sure that is the same as other projects
21:00:37 <jd__> hi guys
21:00:47 <stevebake> as the first incubation release, the new process may be very different
21:01:10 <stevebake> #endmeeting