20:01:17 <stevebake> #startmeeting heat
20:01:18 <openstack> Meeting started Wed Nov 21 20:01:17 2012 UTC.  The chair is stevebake. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:20 <openstack> The meeting name has been set to 'heat'
20:01:34 <asalkeld> well done stevebake
20:01:41 <stevebake> :O
20:01:53 <asalkeld> do we have some agenda?
20:02:13 <asalkeld> rollcall?
20:02:20 <shardy> One item is, do we want to start posting an agenda before the meeting ;)
20:02:26 <zaneb> o/
20:02:31 <shardy> here
20:02:32 <radez> present
20:02:34 <asalkeld> we probably should
20:02:37 <stevebake> \o/
20:02:40 <asalkeld> asalkeld, here
20:03:16 <jpeeler> jpeeler here. unsure if this is agenda worthy, but need input on caching feature work
20:03:18 <asalkeld> #action shardy post agenda before meeting
20:03:23 <asalkeld> :)
20:03:29 <shardy> sure ;)
20:03:34 <zaneb> jpeeler: that is deinitely agenda-worthy IMO
20:03:42 <zaneb> definitely
20:03:48 <shardy> I saw most other projects post something with a link to etherpad to openstack-dev
20:04:09 <stevebake> or a wiki page
20:04:15 <zaneb> also, there was a discussion about native resource types that could go on the agenda
20:04:25 <shardy> stevebake: Yeah, either
20:04:31 <asalkeld> #agenda image caching, native resource types
20:04:50 <asalkeld> anything else come to mind?
20:04:56 <radez> update on the webui
20:05:00 <shardy> I'd like to discuss getting better visibility of functional tests
20:05:05 <stevebake> release date
20:05:08 <shardy> ie the automated ones
20:05:34 <asalkeld> #agenda image caching, native resource types, release date, webui, better visibility of functional tests
20:05:37 <zaneb> anything we agreed to in the project meeting
20:05:47 <zaneb> (OpenStack project meeting)
20:06:01 <asalkeld> #agenda image caching, native resource types, release date, webui, better visibility of functional tests, update on project meeting
20:06:13 <asalkeld> lets roll
20:06:24 <asalkeld> #agenda  image caching
20:06:34 <zaneb> fwiw there is no #agenda command. and stevebake is the chair ;)
20:06:34 <asalkeld> #topic  image caching
20:06:46 <stevebake> #agenda image caching, native resource types, release date, webui, better visibility of functional tests, update on project meeting
20:06:47 <asalkeld> fair enough
20:06:53 <jpeeler> first off we actually have more wiki pages than i knew about
20:06:54 <stevebake> #topic  image caching
20:07:00 <Sl0w> sorry Slow here too
20:07:03 <jpeeler> https://github.com/heat-api/heat/wiki/Image-caching-for-multiple-instantiations-of-the-same-stack
20:07:07 <jpeeler> http://wiki.openstack.org/Heat/Prebuilding-Images-From-Templates
20:07:16 <jpeeler> they don't really agree :/
20:07:19 <zaneb> stevebake: just add asalkeld as a chair
20:07:25 <stevebake> hows?
20:07:42 <zaneb> I think #chair asalkeld
20:07:44 <asalkeld> jpeeler, http://wiki.openstack.org/Heat/ should  be the master
20:07:48 <shardy> jpeeler: prebuilding is just about baking a stack definition into a jeos isn't it?
20:07:58 <asalkeld> delete the github page
20:07:59 <shardy> Or an instace from a stack definition
20:08:17 <asalkeld> shardy, can run it
20:08:24 <stevebake> #chair stevebake asalkeld zaneb
20:08:25 <openstack> Current chairs: asalkeld stevebake zaneb
20:08:40 <jpeeler> originally i was thinking of it being a more of a hands off thing
20:08:41 <stevebake> #link https://github.com/heat-api/heat/wiki/Image-caching-for-multiple-instantiations-of-the-same-stack
20:08:50 <stevebake> #link http://wiki.openstack.org/Heat/Prebuilding-Images-From-Templates
20:09:01 <jpeeler> but that's probably way harder, so if we want to do the latter that's fine
20:10:24 <asalkeld> so jpeeler have you prototyped so options?
20:10:30 <asalkeld> so jpeeler have you prototyped some options?
20:10:45 <asalkeld> what do you feel is the most practical option
20:11:11 <jpeeler> practical to the user?
20:11:21 <asalkeld> to implement
20:12:05 <shardy> I thought tomas got a basic heat-prebuild already working, but it's much more limited/manual/simple than what you're proposing with snapshots
20:12:11 <jpeeler> heh, the second one is no doubt easier
20:13:01 <asalkeld> well another option could be a shardy type image building service
20:13:02 <jpeeler> i have not prototyped beyond checking image copying to make sure the timing is feasible
20:13:12 <zaneb> there is a third option perhaps
20:13:14 <asalkeld> that takes launch configes
20:13:44 <zaneb> have the user explicitly create a snapshot (with a template) and allow them to instantiate copies of it using a new resource type
20:14:45 <asalkeld> or it could be a manual cfn-snapshot call from in the userdata
20:15:19 <asalkeld> and save some state "already-snapshotted" so it doesn't keep doing it
20:16:05 <asalkeld> well we should move on if thomas isn't here
20:16:17 <asalkeld> maybe discuss on ml
20:16:29 <shardy> what's driving the use-case btw?
20:16:29 <shardy> other than fast==good?
20:16:41 <asalkeld> well steve was driving it
20:16:43 <jpeeler> pretty sure that's it?
20:16:51 <zaneb> shardy: what more do you want? ;)
20:16:57 <jpeeler> make demos look super awesome
20:17:06 <asalkeld> mostly after trying the openshift template
20:17:19 <asalkeld> which is super slow
20:17:25 <asalkeld> 30min+
20:17:26 <shardy> The problem with openshift was building everything from source
20:17:42 <shardy> Check out my screecast, it launches openshift in 30s
20:17:51 <asalkeld> ooo
20:18:15 <asalkeld> lets move on
20:18:20 <shardy> If their install-from RPM stuff was better documented, we could do that from a template (or via heat-prebuild or heat-jeos)
20:18:50 <asalkeld> #topic native resource types
20:19:02 <asalkeld> zaneb, ?
20:19:11 <zaneb> shardy: ? ;)
20:19:17 <asalkeld> ok
20:19:23 <zaneb> so, the question was
20:19:37 <stevebake> So, quantum resource type implementation are small and clean, since they are just thin wrappers around api
20:19:43 <zaneb> whether we should introduce stuff like OpenStack::Nova::Instance
20:20:01 <zaneb> and if so should it be an extension of AWS::EC2::Instance
20:20:03 <stevebake> I'd like to at least try a nova instance resource type doing the same thing
20:20:15 <zaneb> or should it be something completely new and more OpenStack-y
20:20:17 <asalkeld> well if there is new value sure
20:20:43 <stevebake> zaneb: right now I'm thinking separate implementations, with shared code refactored somewhere else
20:20:49 <zaneb> this was in the context of jpeeler wanted to do something that was best implemented by adding some properties to the Instance type
20:21:08 <shardy> I think we should keep non AWS resource stuff separate, in a separate OS:: namespace or something
20:21:33 <asalkeld> there is also min_count and max_count that would be neat
20:21:52 <asalkeld> (for multiple creates)
20:22:02 <stevebake> If the resource_ids match then we could mix and match resources in a template, but probably not recommended
20:22:07 <asalkeld> I think in a seperate resource
20:22:36 <asalkeld> not reason not to work together
20:22:50 <stevebake> if the schema properties exactly match the underlying api that will ease the documentation burden
20:22:54 <asalkeld> also would be good to get the new format sometime
20:23:12 <stevebake> I might start playing with new format next
20:23:23 <asalkeld> cool stevebake
20:24:08 <zaneb> so, that approach has merits: it means we're not stuck with the AWS schemas forever
20:24:11 <stevebake> file extension bikeshedding, *.hml (Heat Markup Language) *.homl (Heat's Own Markup Language) ?
20:24:32 <zaneb> the embrace-and-extend option also has merits though: it's a much easier transition path for users
20:24:34 <asalkeld> why not just the actual type
20:25:04 <shardy> +1, why not just use the extension (.yml?) which best describes the format?
20:25:20 <zaneb> mime type should be application/json, so I vote for .json (or .yml)
20:25:35 <radez> +1
20:25:39 <zaneb> that way web servers can infer the mime type
20:25:47 <asalkeld> +1
20:25:50 <stevebake> ok
20:25:52 <asalkeld> .yml
20:26:34 <zaneb> .yaml
20:26:36 <shardy> Can't be json, cos it's not, erm, json?
20:26:44 <zaneb> #link http://www.yaml.org/faq.html
20:27:03 <zaneb> shardy: ?
20:27:20 <asalkeld> zaneb, where the implementation starts diverging you will have to start a new resource
20:27:28 <shardy> zaneb: You said "so I vote for .json"
20:27:41 <shardy> +1 re .yaml
20:27:52 <zaneb> shardy: yeah, that's before I remembered we were moving to YAML
20:28:05 <stevebake> back to native types, we could write tools which transform cfn <-> native types in templates
20:28:08 <shardy> Well, still be json for CFN API
20:28:39 <asalkeld> stevebake, yea could be done in the api server
20:28:42 <zaneb> right, either is fine for templates that are actually in the JSON subset of YAML
20:29:28 <asalkeld> we better speed up 30min down
20:29:49 <stevebake> #topic release date
20:30:16 <asalkeld> ok anyone got a link to the next release date?
20:30:50 <stevebake> Our next release could be a late grizzly-1 release, or a non-aligned one, or wait until grizzly-2
20:31:03 <asalkeld> 2
20:31:06 <asalkeld> I recon
20:31:11 <asalkeld> we could vote
20:31:16 <asalkeld> what are the dates?
20:31:16 <zaneb> stevebake: what are the dates for those?
20:31:47 <asalkeld> https://launchpad.net/heat/+milestones
20:31:52 <asalkeld> #link https://launchpad.net/heat/+milestones
20:32:07 <zaneb> in 3 hours!
20:32:11 <asalkeld> lol
20:32:26 <stevebake> #link http://wiki.openstack.org/GrizzlyReleaseSchedule
20:32:27 <asalkeld> lets shoot for g2 :)
20:32:55 <zaneb> I think it makes sense to wait for the API stuff I am working on, and the cloudwatch stuff shardy is working on
20:33:11 <asalkeld> sure
20:33:17 <zaneb> I don't think that precludes us from doing a late g1 though
20:33:23 <stevebake> then do an interim December release?
20:33:31 <zaneb> Thierry said that was ok
20:33:41 <asalkeld> not sure there is a point tho'
20:33:49 <asalkeld> takes up time
20:33:54 <shardy> agree
20:33:56 <asalkeld> and holidays
20:34:01 <stevebake> waiting for g-2 could make it a painful release
20:34:17 <zaneb> we do have to sort out the version numbering stuff before doing any more releases though
20:34:19 <shardy> stevebake: any particular reason why?
20:34:29 <asalkeld> I think so zaneb
20:35:17 <stevebake> shardy: g-2 is a hard date, doing a release before could shake out issues which take a long time to fix, like functional tests
20:35:28 <asalkeld> well we could start in say 2 weeks to do bug fixing/testing
20:35:40 <zaneb> I'm ok with holding off until g2
20:35:52 <shardy> Well, we have the functional tests already, it's just none of us are looking at the results or running them ;)
20:36:28 <stevebake> ok, lets tell the Project Meeting our next release is g-2
20:36:30 <asalkeld> how long does a run take?
20:36:40 <zaneb> is there any way we can contribute those tests to tempest?
20:36:42 <zaneb> asalkeld: forever
20:36:48 <zaneb> give or take
20:36:49 <asalkeld> overnight?
20:37:08 <shardy> I think we really really need a way to get better visibility of the status
20:37:09 <asalkeld> maybe we could take turns running overnight
20:37:29 <zaneb> asalkeld: depends if they all pass
20:37:29 <zaneb> if they do, it's not too bad
20:37:29 <shardy> we put so much effort into writing them and not really benefiting atm
20:37:39 <asalkeld> yip
20:37:41 <zaneb> failures can take a couple of hours to detect
20:37:53 <stevebake> #agreed Next release of Heat is January 10th, 2013
20:38:17 <asalkeld> can you run them the tests separately?
20:38:25 <asalkeld> so one test?
20:38:29 <zaneb> yes
20:38:36 <asalkeld> just thinking if we each run one
20:38:36 <shardy> asalkeld: yes, just nosetest -s
20:38:44 <asalkeld> it will share the burden
20:38:48 <stevebake> #topic better visibility of functional tests
20:39:09 <shardy> asalkeld: zaneb set up a fully automated test environment, why run them manually?!
20:39:15 <stevebake> who/when/what runs tempest currently?
20:39:21 <shardy> we just need better visibility of the results
20:39:24 <asalkeld> ok, well lets do that then
20:39:59 <zaneb> the test environment is broke at the moment
20:40:10 <asalkeld> we can't just post them somewhere and have a link from https://bugs.launchpad.net/heat
20:40:58 <stevebake> Email and bot notifications would be nice. And a pony
20:41:00 <asalkeld> zaneb, major pita maintaining function tests
20:41:06 <zaneb> but we can't continue to have this stuff behind a firewall. we need to move it into tempest
20:41:22 <zaneb> yep, sure is
20:41:25 <asalkeld> yip
20:42:00 <asalkeld> that's why I suggested we all just run one
20:42:02 <zaneb> biggest problem with that imo is that the heat-jeos image we need is unstable
20:42:26 <stevebake> Quantum recently did something with their devstack gating, maybe that is worth looking into
20:42:28 <asalkeld> I see, that's not good
20:42:56 <zaneb> not unstable as in bad, unstable as in the cfn-tools are changing all the time
20:42:57 <asalkeld> well we need to fix this somehow
20:43:01 <shardy> zaneb: Latest jeos should always work with latest master tho, which I presume is what the automated tests use?
20:43:20 <zaneb> so we can't just build an image once for tempest and always test against that
20:43:39 <zaneb> shardy: automated tests do, but that's a PITA for tempest
20:43:49 <asalkeld> zaneb,  fix is cfn tools reinstall themselves
20:43:51 <zaneb> since it runs on VMs
20:43:53 <shardy> the cfntools churn should stop soon anyway, but then we'll probably want some ostools variant, so more churn
20:44:20 <shardy> asalkeld: We should package the cfntools as an RPM
20:44:26 <asalkeld> na
20:44:36 <zaneb> I like the idea of installing the tools at launch time
20:44:37 <asalkeld> just do a github install
20:44:55 <asalkeld> so once that is in, no problem
20:44:57 <zaneb> What Would Amazon Do?
20:45:07 <asalkeld> rpm update <cfn>
20:45:18 <shardy> zaneb: they install cfn-bootstrap RPM from their repo
20:45:30 <zaneb> let's do that
20:45:34 <asalkeld> +1
20:45:35 <shardy> +1
20:46:00 <asalkeld> still need to run the pesky test tho'
20:46:12 <asalkeld> 13min left
20:46:28 <stevebake> #topic webui
20:46:32 <radez> The conversion to python-heatclient is essentially done.
20:46:35 <radez> I've just been waiting for the events command to be exposed before I screencast the latest.
20:46:37 <radez> I have some ui functionality that displays events that will be pretty easy to convert, and that's all that's pending.
20:46:47 <radez> In the mean time I've been working on a couple concepts for new features.
20:46:50 <radez> 1. template catalogues (pulling already written templates from multiple sources, github and aws atm)
20:46:52 <radez> 2. eye candy enabled template designer (drag and drop and forms that render to a template)
20:46:58 <radez> both are coming along very well and are just about ready to do an inital screencast of them to show where they are in concept/development
20:47:11 <radez> other thoughts on my plate
20:47:13 <radez> 1. moving onto LP (can I just do it, or is there a plan of some kind I need to follow?)
20:47:15 <radez> 2. I'm in my first week of trianing to get my RHCA next week (ie, absent from meeting)
20:47:17 <radez> 3. blueprints, kinda need more of a plan on where to go with this. I think this depends on #1 but up for feed back on what folks want to see.
20:47:19 <radez> thoughts? questions?
20:47:26 <stevebake> radez: do you want coding help or users yet?
20:47:28 <zaneb> radez: I'm writing unit tests for events now. as soon as they are done (I expect tomorrow) I will post the patches.
20:47:45 <radez> stevebake: users would be great
20:48:06 <asalkeld> radez, just move to lp
20:48:16 <radez> coding help, I think i'm starting to have enough to use the help
20:48:31 <radez> zaneb: asalkeld: cool thx
20:48:42 <asalkeld> ok
20:48:44 <stevebake> maybe devstack integration would be a good first step
20:48:57 <asalkeld> good idea
20:49:02 <radez> stevebake: good though, I'll put that on my list
20:49:06 <radez> *thought
20:49:17 <asalkeld> radez, awesome work btw
20:49:35 <radez> thx, I look fwd to sharing another screencast
20:49:53 <asalkeld> what about nati_ueno?
20:50:06 <radez> he's been consumed by quantum
20:50:13 <asalkeld> I see
20:50:15 <radez> so he hasn,t been able to code any
20:50:22 <zaneb> sounds painful
20:50:29 <asalkeld> did you look at his code?
20:50:33 <radez> but he had some good work done that went into the template designer
20:50:35 <nati_ueno> yeah, But I got one UX guy, so I may help something. may be
20:50:47 <asalkeld> cool
20:50:51 <radez> so I think we'll benefit from his contribution
20:51:10 <asalkeld> well at least make a blueprint and share ideas
20:51:23 <nati_ueno> sorry I can't promise yet. but may be I can work :)
20:51:27 <radez> nati_ueno: take a look at what I've started when you get a chance
20:51:36 <nati_ueno> radez: gotcha
20:51:41 <radez> I went with jsPlumb for now
20:51:50 <radez> but made good progress
20:52:07 <radez> that's it for me
20:52:16 <asalkeld> next topic?
20:52:51 <stevebake> #topic update on project meeting
20:52:57 <asalkeld> that's it
20:53:07 <asalkeld> so we are moving to openstack/
20:53:15 <asalkeld> github.com/openstack/
20:53:19 <asalkeld> on the 2 dec
20:53:30 <stevebake> should we move thermal too?
20:53:51 <asalkeld> good point, not sure
20:53:53 <asalkeld> https://review.openstack.org/#/c/16593/
20:54:15 <asalkeld> I have made the team  changes
20:54:29 <stevebake> maybe we should just get those in first
20:54:31 <asalkeld> that the ci / project folks wanted
20:54:45 <asalkeld> stevebake, those?
20:54:54 <stevebake> heat and python-heatclient only
20:55:06 <asalkeld> o, yea sure
20:55:06 <zaneb> if & when we were accepted into core, I would expect thermal to be maintained in the horizon tree. but not sure how that should work during incubation?
20:55:29 <asalkeld> might only do that once in core?
20:55:40 <radez> I kinda expect to be consumed by horizon, but I don't know for sure
20:56:04 <asalkeld> yea, github not a bad place for now
20:56:08 <stevebake> are there any outstanding launchpad process changes?
20:56:14 <asalkeld> nope
20:56:24 <asalkeld> all good to go
20:56:40 <asalkeld> note all issues and wiki pages will probably go
20:56:50 <asalkeld> so cleanup you pages
20:56:53 <stevebake> asalkeld: thanks for all that migrating, its a shitty job
20:57:10 <asalkeld> wiki was the most tedious
20:57:17 <asalkeld> no problem
20:57:30 <zaneb> stevebake: did anything come up in yesterday's meeting? I wasn't there this week
20:57:44 <asalkeld> the team stuff
20:57:48 <asalkeld> I was there too
20:57:51 <stevebake> not really. we have a release date for them now
20:58:04 <asalkeld> that's right
20:58:10 <zaneb> cool
20:58:14 <asalkeld> wrapup?
20:58:29 <asalkeld> #endmeeting