19:59:40 <asalkeld> #startmeeting Heat
19:59:41 <openstack> Meeting started Wed Dec 12 19:59:40 2012 UTC.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:44 <openstack> The meeting name has been set to 'heat'
20:00:09 <asalkeld> rollcall
20:00:18 <stevebake> \o/
20:00:22 <jpeeler> here
20:00:44 <zaneb> howdy
20:01:29 <asalkeld> lets go thro' last weeks actions
20:01:39 <asalkeld> see what we forgot to do
20:01:52 <asalkeld> stevebake should submit a ci change to automatically release to pypi when a tag is pushed
20:02:07 <stevebake> done, awaiting approval
20:02:16 <asalkeld> #topic review last weeks actions
20:02:30 <stevebake> also at the request of the projects meeting I've enabled tarball and docs jobs for heat
20:02:37 <asalkeld> #chair stevebake zaneb jpeeler asalkeld
20:02:38 <openstack> Current chairs: asalkeld jpeeler stevebake zaneb
20:02:42 <stevebake> https://review.openstack.org/#/c/17897/
20:02:50 <asalkeld> nice, well done
20:02:56 <zaneb> stevebake: can you close the bug for the PyPi thing then?
20:03:03 <stevebake> no idea what that does ;)
20:03:03 <asalkeld> asalkeld kill the heat-api/python-heatclient repo
20:03:11 <stevebake> zaneb: I think I have, fixed-released
20:03:15 <asalkeld> I haven't done that :(
20:03:35 <zaneb> stevebake: cool, hadn't looked in a couple of days sorry
20:03:55 <zaneb> I don't get as many email notifications from launchpad as I expected
20:04:01 <stevebake> it was only yesterday, to look good for the projects meeting ;)
20:04:16 <asalkeld> #action asalkeld really kill  heat-api/python-heatclient repo this time
20:04:31 <asalkeld> stevebake look at make the gettingStart easier to understand
20:04:35 <stevebake> #action stevebake look at make the gettingStart easier to understand
20:04:42 <asalkeld> :)
20:05:24 <stevebake> annegentle_ mentioned yesterday we should start looking at moving our docs off the wiki
20:05:36 <annegentle_> stevebake: hey, yep.
20:05:37 <asalkeld> #topic docs
20:05:39 <annegentle_> hi all
20:05:40 <annegentle_> :)
20:05:45 <asalkeld> hi
20:05:46 <stevebake> hey!
20:05:54 <annegentle_> so we try to write docs for specific audiences as a pattern for the docs
20:05:58 <asalkeld> so how do we do that?
20:06:08 <annegentle_> Use your docstrings and Sphinx for the other Python devs you want to write for.
20:06:34 <asalkeld> ok
20:06:38 <annegentle_> for operators, people running Heat, think about an overall guide or integrating in to the current docs which are written in markdown or docbook or asciidoc
20:07:00 <annegentle_> for API consumers, try to have an API guide that separate with that audience in mind
20:07:12 <shardy> sorry I'm late - got stuck in traffic :(
20:07:19 <asalkeld> no worries
20:07:25 <zaneb> annegentle_: I thought Re:structuredText was preferred over markdown?
20:07:32 <stevebake> The thing is, our getting started guide should be based on installing packages, but we don't quite have packages yet
20:08:01 <annegentle_> stevebake: ah, okay, sure.
20:08:15 <annegentle_> zaneb: sorry all those ascii-based markups are the same to me :)
20:08:21 <annegentle_> zaneb: RST is fine too
20:08:37 <stevebake> so dev docs are in our own source repos?
20:08:46 <zaneb> annegentle_: cool, thanks for the clarification. we have some of each anyway ;)
20:08:46 <annegentle_> stevebake: yup
20:08:49 <asalkeld> annegent_ so we don't need to put any docs into a separate repo?
20:09:06 <asalkeld> I thought we did
20:09:07 <annegentle_> ops docs will go into the openstack-manuals repo
20:09:16 <asalkeld> I see
20:09:32 <asalkeld> (excuse the newbie questions)
20:09:35 <annegentle_> but since you're not core, you might just start your own separate doc with the future proofing of getting it into it's own "guide" (not wiki pages)
20:09:42 <annegentle_> asalkeld: no worries, glad you're asking! :)
20:10:03 <annegentle_> mostly I just ask people not to reinvent the wheel, use patterns we already have in place, think about audiences
20:10:27 <asalkeld> ok thanks annegentle_
20:10:33 <annegentle_> I think you're heading in the right direction, and drafting in the wiki (or ether pad( is always a good start
20:10:42 <annegentle_> that's all I got, feel free to ask questions as you go
20:10:51 <asalkeld> cool
20:10:52 <stevebake> so if we start writing ops docs, do it in our repo but in the same format as openstack-manuals?
20:11:15 <annegentle_> stevebake: ideally yes, such as in a /doc/heat-install/ folder or some such
20:11:36 <annegentle_> stevebake: then just think of how "heat-install" fits into the overall Install and Deploy manual as a chapter or some such
20:11:44 <stevebake> yep
20:11:50 <annegentle_> stevebake: not required, but for easier insertion later, you know.
20:12:13 <asalkeld> ok we need some bug(s) for this
20:12:51 <annegentle_> one thing that I'll want to think about and understand is your API and how to doc it
20:12:52 <stevebake> annegentle_: will our artifacts still end up on docs.openstack.org?
20:13:16 <annegentle_> stevebake: ideally integrated in with the other docs - install, admin, API are major categories there
20:13:29 <zaneb> annegentle_: there is a markdown doc in the repo with an outline of the API
20:13:30 <stevebake> its fairly vanilla REST, it shoudn't be too hard to document
20:13:39 <zaneb> annegentle_: it's missing examples at the moment
20:13:59 <asalkeld> #action stevebake make a docs bug to convert wiki into openstack consumable docs strings
20:14:03 <annegentle_> stevebake: one consideration - we use WADL to generate http://api.openstack.org/api_reference.html
20:14:31 <asalkeld> Not Found
20:14:32 <annegentle_> that's for a reference listing not for much "narrative" explanation of the API
20:14:56 <annegentle_> sorry
20:14:58 <annegentle_> #link http://api.openstack.org/api-ref.html
20:15:13 * annegentle_ spells things out
20:15:16 <annegentle_> :)
20:15:31 <stevebake> zaneb: documenting in wadl would be handy
20:15:47 <zaneb> yeah, shouldn't be too hard to translate
20:15:55 <annegentle_> one more thought, the Quantum team is looking into generating WADL from their code
20:16:09 <annegentle_> #link http://wiki.openstack.org/Quantum/API/WADL
20:16:19 <annegentle_> might be interesting to look into as well, good to investigate
20:16:33 <stevebake> I *really* wish there had been quantum api docs when I needed them ;)
20:17:34 <annegentle_> :)
20:17:44 <asalkeld> anyone have any more docs to discuss?
20:17:44 <stevebake> i think ours is small enough to hand-document
20:18:25 <stevebake> thanks anne
20:18:37 <annegentle_> you're welcome, glad you're thinking ahead.
20:18:52 <asalkeld> so any other topics people want to discuss?
20:19:02 <stevebake> I doubt well get all this done by g-2
20:19:02 <zaneb> packaging
20:19:22 <stevebake> #topic packaging
20:19:41 <zaneb> jpeeler: are you working on packaging atm?
20:19:56 <jpeeler> yeah, actually have a few questions about that
20:20:01 <stevebake> I've emailed jamespage about ubuntu, maybe they can pull in zigo's work
20:20:22 <jpeeler> 1) is cfntools packaged the way we want now? https://github.com/heat-api/heat-rpms/pull/6/
20:20:36 <jpeeler> 2) do we want to get this in fedora, https://github.com/heat-api/heat-prebuild
20:22:15 <asalkeld> jpeeler, rpm is nice - I think we also just want to be able to fall back to install from github
20:22:24 <zaneb> (2) is a question for shadower and Sl0w
20:22:49 <shadower> do you guys know how much use heat-prebuild actually got?
20:22:53 <stevebake> Slower: ?
20:23:03 <shadower> it's a nifty tool but do people care?
20:23:41 <asalkeld> honestly not sure
20:23:45 <shadower> yeah
20:24:06 <zaneb> I was away when you guys started on that, so I don't know much about it, but I've never heard it mentioned by any users
20:24:14 <shadower> if we're packaging the rest of Heat-related tools (heat-jeos, etc.) it might make sense to add this as well
20:24:24 <shadower> but I don't think it has a super high priority
20:24:52 <asalkeld> there is also action in the image factory/building area
20:25:00 <shadower> zaneb, it takes a template and builds image per resource that has the packages and files specified in the template preinstalled
20:25:18 <shadower> zaneb, so you don't run yum install every time you launch a stack
20:25:29 <zaneb> right
20:25:39 <zaneb> so is that something you guys are pursuing?
20:25:49 <zaneb> or not really working on it any more?
20:25:51 <shardy> we could package all the useful but not essential tools in a heat-utils package?
20:25:58 <shadower> yeah
20:26:05 <shadower> +1
20:26:40 <asalkeld> sounds good
20:26:50 <zaneb> just out of interest, why are the cfn tools in the heat-jeos repo? They have to be kept in sync with Heat, not heat-jeos
20:27:35 <shardy> zaneb: Just historical I think - because heat-jeos picks the individual files up
20:27:39 <shadower> we didn't want heat-jeos to depend on heat. And obviously it needs to include them
20:27:41 <shadower> ya
20:27:52 <stevebake> #topic Image building roadmap
20:28:03 <zaneb> so if we made heat-jeos install from rpm then we could move them?
20:28:14 <shadower> yeah
20:28:28 <asalkeld> well cfn needs to be seperatly installable
20:28:34 <shadower> are they on pypi?
20:28:35 <zaneb> I think it's time that everything moved towards packages
20:28:38 <shadower> they should be imho
20:28:46 <zaneb> please no
20:28:47 <asalkeld> atm cfn is pre-baked
20:28:53 <zaneb> then we are locked to that version
20:29:00 <shadower> right
20:29:04 <shardy> Can we just have a side-repo on fedoraproject.org?
20:29:18 <shardy> so we can update without a release?
20:29:29 <zaneb> shardy: +1
20:29:46 <asalkeld> can't we install from github
20:29:50 <shardy> and the same via a ppa under heat for ubuntu
20:30:08 <asalkeld> git clone & setup.py install
20:30:12 <shadower> +1, but I think that sooner or later we should package them properly -- though now may be too soon
20:30:15 <asalkeld> super simple
20:30:23 <zaneb> asalkeld: our install procedure is a mess. we need to get away from installing from github
20:30:29 <stevebake> So is Image Factory our future for image building?
20:30:33 <shardy> asalkeld: then you need git in all the guest images
20:30:43 <asalkeld> well tarball
20:30:50 <asalkeld> from master
20:30:51 <shadower> stevebake, it's doable. Is it something we want?
20:31:05 <zaneb> asalkeld: build an rpm from master and install that
20:31:17 <asalkeld> then rpm/deb/...
20:31:20 <shardy> stevebake: maybe, not much feedback re the video yet, IMO heat-jeos is fine for now
20:31:29 <zaneb> put the nasty install complexity in the packages, not the getting started guide
20:32:00 <asalkeld> I'd say put it in the template
20:32:02 <stevebake> how about we modify heat-jeos to be able to output the prepared tdl file, which could be fed to imagefactory
20:32:04 <zaneb> then we control how it gets updated + hide it from the user
20:32:18 <shadower> stevebake, iirc that's true now
20:32:47 <shadower> the template heat-jeos produces is in fact an Oz template. And image factory uses oz behind the courtains, too
20:33:36 <shardy> stevebake: we can just use the tdls directly no?
20:33:41 <stevebake> yep, but it always invokes oz, there needs to be an option to just output the tdl which has the cfn files inserted into it
20:34:15 <shadower> btw, the cfn files could be referenced via a URL as well. Which would could solve the distribution
20:34:38 <stevebake> or we need a generic tool which merges files into a tdl and returns an oz/imgfac ready tdl file
20:35:01 <stevebake> which might meet lifeless OoO needs too
20:35:16 <zaneb> if tdl installs from packages then we don't need heat-jeos to modify it
20:35:34 <zaneb> it only exists to hack the cfn-tools files into the tdl
20:36:01 <stevebake> true that
20:37:15 <asalkeld> well you can install cfn-init from the userdata
20:37:30 <zaneb> +100 to that
20:37:31 <asalkeld> aws updates it from the userdata
20:38:04 <asalkeld> so we only really need cloud-init
20:38:49 <zaneb> you mean I'll never have to build a new JEOS again? fantastic!
20:39:02 * zaneb hates that part
20:39:16 <asalkeld> yea
20:39:16 <stevebake> could someone spell out the action steps to get to this nirvana?
20:39:34 <shadower> package cfn-tools, update heat templates?
20:39:35 <zaneb> 1) move cfn-init tools to heat repo
20:39:48 <zaneb> 2) install cfn tools using user data
20:39:54 <zaneb> 3) profit
20:40:07 <asalkeld> zaneb, well maybe seperate repo?
20:40:16 <asalkeld> heat-cfn-tools
20:40:25 <asalkeld> or similar
20:40:32 <zaneb> asalkeld: why? the tools and the engine change in unison
20:40:46 <zaneb> and if the engine is going to install them, they need to be locally available
20:40:48 <asalkeld> they shouldn't
20:40:53 <zaneb> and the correct version
20:40:58 <zaneb> to match the engine
20:41:27 <stevebake> so why install via userdata instead of packages?
20:41:29 <asalkeld> it's like the client repos
20:41:31 <zaneb> asalkeld: at some point they should stop changing, I agree
20:41:39 <zaneb> but I don't think we're there
20:41:52 <asalkeld> yea but install latest
20:42:02 <asalkeld> from a nice clean little repo
20:42:17 <asalkeld> with very little deps
20:42:22 <zaneb> client repos I can sort-of understand, because they have to be installed separately, uploaded to pypi &c.
20:42:34 <asalkeld> like cfn-tools
20:42:42 <asalkeld> no different
20:42:53 * stevebake votes for separate repo
20:43:08 <zaneb> if we have separate repo for cfn-tools then be have to maintain upwards/backward comaptibility
20:43:19 <zaneb> same repo -> version always matches engine
20:43:30 <zaneb> what's not to like? ;)
20:44:14 <shardy> why not release the cfntools as part of the release, then have a side repo which is "latest"
20:44:23 <zaneb> it's the one upgrade thing we can actually get for free
20:44:52 <asalkeld> zaneb, lets take that offline
20:44:59 <zaneb> shardy: why would anyone want to install/package them separately though?
20:45:04 <zaneb> that's the part I don't get
20:45:25 <zaneb> yeah, mailing list question I guess
20:45:26 <stevebake> to bake it into an image?
20:45:39 <zaneb> stevebake: why do that when the engine can install it for you?
20:45:42 <asalkeld> because you don't want to install heat on the instance
20:45:59 <asalkeld> you want to make it easy to install on the vm
20:46:18 <zaneb> maybe I'm misunderstanding this userdata part
20:46:38 <asalkeld> whether it be pypi / rpm / tarball
20:46:49 <shardy> Yeah, and you need an easy way to update it for existing instances after deployment
20:46:58 <zaneb> the proposal is for heat-engine to install it at instance creation through the metadata server and cloud-init, no?
20:46:59 <shardy> Yeah, and you need an easy way to update it for existing instances after deployment
20:47:16 <lifeless> stevebake: oh hai? :)
20:48:05 <asalkeld> zaneb, we don't have to decide this now
20:48:15 <asalkeld> the end goal is good
20:48:15 <zaneb> yep, let's move on
20:48:18 <zaneb> sorry ;)
20:48:21 <asalkeld> just the steps
20:48:23 <stevebake> lifeless: so we're just talking about heat's image creation needs, oz vs image factory
20:48:38 <zaneb> stevebake: are those different things?
20:48:53 <stevebake> no, different interface ;)
20:49:09 <zaneb> ;)
20:49:57 <asalkeld> any more topics?
20:50:08 <stevebake> so were there any actions to extract from that discussion?
20:50:09 <asalkeld> 9mins left
20:50:16 <shardy> well you could have an imagefactory builder plugin which didn't use oz, but that's OT ;)
20:50:40 <shadower> image factory does more than oz -- uploads to various cloud providers. Oz just builds the images
20:50:42 <asalkeld> email discussion on where to keep cfn-tools
20:51:23 <asalkeld> #action start an email discussion on where to keep cfn-tools for easy install
20:52:15 <asalkeld> well if no more topics I am going to end meeting
20:52:49 <asalkeld> #endmeeting