19:59:30 <sdake> #startmeeting heat
19:59:31 <openstack> Meeting started Wed Mar  6 19:59:30 2013 UTC.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:34 <openstack> The meeting name has been set to 'heat'
19:59:36 <sdake> #topic rollcall
19:59:42 <sdake> steak here
19:59:53 <shardy> shardy here
19:59:58 <SpamapS> spam here
20:00:00 <asalkeld> here
20:00:08 <jpeeler> here
20:00:51 <zbitter> o/
20:01:09 <sdake> ok lets get rolling
20:01:13 <sdake> #topic bugs
20:01:40 <sdake> on the project planning meeting, got the message that we need to have our buglist at zero
20:01:43 <sdake> then we release rc1
20:02:08 <sdake> so i'll go through the bugs that don't have activity on them
20:02:33 <sdake> https://bugs.launchpad.net/bugs/1128486
20:02:34 <uvirtbot> Launchpad bug 1128486 in heat/grizzly "creating a stack without a required param, fails correctly but leaves the stack created" [High,New]
20:02:58 <sdake> this almost seems critical to me...
20:03:17 <asalkeld> that was mine
20:03:29 <sdake> okie i'll assign you
20:03:43 <zaneb> is this just due to rollback not being the default any more?
20:04:08 <asalkeld> it was a while back
20:04:19 <asalkeld> I'll need to retest
20:04:20 <stevebaker> here!
20:04:23 <SpamapS> If anybody is overwhelmed I have cycles for bug fixes
20:04:48 <SpamapS> Just been focused on testing and planning lately.
20:05:03 <sdake> https://bugs.launchpad.net/bugs/1072949
20:05:04 <uvirtbot> Launchpad bug 1072949 in heat/grizzly "Reset DB migrations" [Critical,Triaged]
20:05:22 <zaneb> started investigating
20:05:30 <sdake> spamaps we can use help in reviews ;)
20:05:31 <SpamapS> Seems to me like the Low's should just be dropped from rc1
20:05:36 <sdake> reviews piling up
20:05:44 <SpamapS> sdake: roger that
20:06:09 <zaneb> I actually think DB migrations is not as high a priority as I first thought; it shouldn't break existing users
20:06:19 <sdake> atm we only have 5 bugs and have until 20th
20:06:25 <sdake> suggest high prio then?
20:06:31 <sdake> (rather then critical)
20:06:48 <zaneb> sure
20:07:03 <SpamapS> https://launchpad.net/heat/+milestone/grizzly-rc1 says rc1 is the 14th btw
20:07:19 <zaneb> I see nova have moved to a different tool altogether and I'm kinda envious ;)
20:07:29 <sdake> https://bugs.launchpad.net/bugs/1135970
20:07:30 <uvirtbot> Launchpad bug 1135970 in heat "--timeout doesn't work for heat-boto" [Medium,Triaged]
20:07:32 <zaneb> it can generate the migrations for you
20:07:34 <sdake> ya, i'd like it to be 14th :)
20:07:45 <sdake> but 20th is drop dead date
20:07:47 <shardy> sdake: I'm on that, simple fix
20:08:02 <shardy> probably get it done tomorrow
20:08:04 <sdake> https://bugs.launchpad.net/bugs/1150091
20:08:05 <uvirtbot> Launchpad bug 1150091 in heat "API policy debug logging is too noisy" [Low,Triaged]
20:08:11 <shardy> ditto
20:08:45 <sdake> https://bugs.launchpad.net/bugs/1102101
20:08:46 <uvirtbot> Launchpad bug 1102101 in heat/grizzly "--host option to heat-boto is ignored" [Low,Triaged]
20:08:53 <shardy> likewise.. :)
20:09:00 <sdake> shardy superman for rc1 ;)
20:09:17 <sdake> ok, rest look like they are in progress with patches queued up
20:09:22 <shardy> these ones are really simple fixes, I've just prioritized the more serious problems
20:09:32 <sdake> remember, put a bug and the bug number for fixes for rc1 in the changelogs
20:10:03 <sdake> are there any outstanding bugs not in the bug tracker people are aware of?
20:10:27 <shardy> sdake: I found an issue with update today, bug pending
20:10:42 <sdake> ok
20:10:52 <SpamapS> I've been testing a lot, spinning up nested stacks and stuff.. it all seems to be working quite well.
20:11:15 <sdake> for the next week if your not working on bugs recommend running heat manually make sure there aren't bugs our test cases don't catch
20:11:31 <sdake> and once bug count hits zero, i'll do rc1 release
20:11:45 <sdake> #topic new core members
20:12:03 <sdake> every 6 months, we should select new core members for heat
20:12:08 <sdake> (ie before summit)
20:12:23 <sdake> core gives folks the rights to +2 a patch or approve a patch
20:12:27 <asalkeld> hopefully a bit more dynamic than that
20:12:39 <sdake> well atleast every 6 months ;)
20:13:05 <asalkeld> if I get stuck into heat, I might have to wait 5 months to get into core?
20:13:05 <sdake> let me rephrase, few weeks prior to summit, we should consider the candidates
20:13:23 <asalkeld> I think it shoud be continous
20:13:24 <sdake> think a few months wfm
20:13:41 <sdake> wan't to make sure core members are really ready to commit to that
20:13:47 <sdake> in my mind the criteria are
20:13:50 <sdake> 1) understand code base
20:13:58 <sdake> 2) have some level of reviews in the system
20:14:06 <sdake> 3) participate in irc on #heat channel
20:14:13 <sdake> 4) submit patches
20:14:18 <asalkeld> but none of that takes 6 months to prove
20:14:20 <sdake> with #4 being less of a concern then others
20:14:24 <sdake> i agree
20:14:29 <sdake> I said few months..
20:14:40 <asalkeld> weeding out could be every 6 months
20:14:50 <asalkeld> (removing from core)
20:14:54 <SpamapS> Perhaps its just something people can bring up at any meeting if they feel a candidate is ready for core status?
20:15:02 <asalkeld> +1
20:15:16 <sdake> ya, if you have a candidate for submission and your core send it my way and I'll put on submission
20:15:28 <sdake> for this cycle Spamaps seems like a good core candidate
20:15:35 <SpamapS> If there's a quorum of core people, a vote can be taken, and done in any meeting, right?
20:15:43 <sdake> so I'll send his name to the list and get a +1/0/-1 vote from folks in core
20:15:47 <SpamapS> sdake: :) thank you.
20:15:54 <sdake> would rather do on mailing list
20:16:00 <sdake> anyone have suggestions for other core members
20:16:04 <SpamapS> sure, ML is even more dynamic actually :)
20:16:48 <sdake> we have a few patches from other folks but not much patch review or irc participation
20:17:00 <sdake> so unless I'm missing someone I'll move on ;)
20:17:29 <sdake> #topic plugin interface
20:17:53 <sdake> there was a review that zaneb spawned which generated some controversy around plugin api lockdown
20:18:07 <sdake> i think we had some disjointed conversations about it but it is worth discussing in one place
20:18:19 <sdake> zaneb care to restate your thoughts on that
20:19:01 <zaneb> I think the conclusion we came to is that we would not freeze the plugin api until Havana?
20:19:10 <asalkeld> what is the "policy" with drivers in say quantum
20:19:24 <asalkeld> re: stability
20:19:25 <sdake> good question
20:19:25 <SpamapS> +1 from me, there aren't very many plugins, and if there are, they're likely nascent
20:19:53 <asalkeld> I suspect only on stable branches
20:19:59 <SpamapS> so freezing this early would possibly miss some needs that early plugin devs will find as grizzly sees use
20:20:43 <sdake> ok well seems to me freezing in havana makes sense
20:20:57 <asalkeld> (on the stable branch)
20:20:59 <asalkeld> ?
20:21:02 <sdake> after we have sorted out parallel launch
20:21:06 <stevebaker> I think we should encourage plugins to be developed in tree at this point, the carrot is that we will take the burden of updating for api changes
20:21:15 <SpamapS> It would be great to make an effort to not break backward compatability w/ grizzly if at all possible... but better to break it in Havana and never again than miss important pieces
20:21:20 <shardy> Yeah, only freeze the stable branch, versioned per major release IMO
20:21:37 <sdake> yes we had talked about adding a version to the plugins
20:21:44 <sdake> so the engine could work with older plugins
20:21:55 <sdake> if ver = 1 do x if ver =2 do y
20:21:55 <zaneb> versioning sounds like a bag of hurt to me
20:22:07 <zaneb> do people have suggestions of how to do it?
20:22:33 <asalkeld> -1 to versioning
20:22:41 <sdake> theoretically heat is perfect so no need to update the version :)
20:22:52 <SpamapS> :)
20:23:13 <SpamapS> I prefer API's that only move forward with new aspects, rather than version themselves aggressively
20:23:21 <shardy> I don't really get why we're making plans to freeze this interface now, I mean we've had very few users asking about custom resources in #heat
20:23:36 <sdake> well we are not freezing in g
20:24:00 <sdake> the proposal was to freeze in h
20:24:05 <shardy> which I assume means most people are only using the internally defined resources, so we can keep changing it until people start making significant use of the plugin capability
20:24:41 <asalkeld> shardy, not everyone will tell us
20:24:41 <SpamapS> shardy: I look at what will happen if, say, HP Cloud or Rackspace deploy heat.. they'll want to plugin to things that are specific to their clouds with plugins that are not public at all.
20:24:58 <shardy> sdake: I guess I'm saying I don't see the motivation behind committing to that, when the interface is still maturing (as evidenced by the discussion today re zaneb's patch)
20:25:37 <sdake> i'll shoot a mail to Dan ask him what they are doing with quantum
20:25:41 <SpamapS> shardy: if the API is unversioned but also stays backward compatible with havana's API.. there will be nothing but happy heat users. If old versions start getting dropped.. there will be sad heat users.
20:25:48 <zaneb> shardy: people will stop following trunk once we have a proper grizzly release out there
20:25:57 <shardy> SpamapS: Yep, but they will have to re-test those in-house plugins every major release anyway, so would it be a huge problem if there are clearly documented interface tweaks between major releases occasionally?
20:26:03 <zaneb> shardy: we may not have time to react
20:26:18 <zaneb> but I am still find with holding off until havana
20:26:36 <SpamapS> shardy: no its not a problem at all. I'm suggesting simply that the less backward compatibility breakage allowed, the less important versioning becomes.
20:26:45 <sdake> in h3 we will have to make a decision about versioning the api
20:26:47 <SpamapS> and yes, I think we can table this until havan
20:26:48 <SpamapS> a
20:26:57 <SpamapS> hrm
20:27:06 <SpamapS> perhaps we should start a discussion before h3?
20:27:06 <shardy> Ok, I guess I'm saying I support stability of the interface, but not at the expense of subsequent innovation (implied by the "frozen forever" idea)
20:27:07 <sdake> so lets put it off until then
20:27:32 <zaneb> shardy: +1
20:28:06 <zaneb> I don't think anyone is talking about frozen forever
20:28:23 <asalkeld> zaneb, converting instanceGroups into a stackedResource would make that change large not needed
20:28:24 <SpamapS> no not frozen forever. "BC breaks discouraged".
20:28:48 <zaneb> the discussion was sparked by "breaking changes that we know already might be on the horizon"... it's always good to get those in early
20:29:08 <SpamapS> Right, especially when the impact will be almost nil.
20:29:13 <shardy> Ok, provided we have some flexibility for future changes then all good :)
20:29:18 <sdake> yes, I think we don't know what that should be tho from the debate on the patch in question
20:29:55 <zaneb> so, for the patch in question, the breaking change was adding a parameter to check_active()
20:30:04 <zaneb> there are a bunch of ways to fix that
20:30:26 <zaneb> 1) just document now that people should expect there may be parameters in the future
20:30:38 <sdake> i'd rather not change the api at this point in the release
20:30:45 <zaneb> 2) do introspection on the method before calling it to see how many parameters it takes
20:30:52 <asalkeld> urg
20:31:00 <asalkeld> more complexity
20:31:14 <zaneb> but if we _know_ we want to change it, better to do so now
20:31:27 <zaneb> there's no consensus for change though, so I'm happy to delay
20:31:28 <sdake> i'm not convinced we know *how* we want to change it
20:31:39 <zaneb> right
20:31:55 <zaneb> I know how I want to change it, and everybody else disagrees ;)
20:31:58 <asalkeld> also when/if the rackspace get stuck in
20:32:05 <zaneb> but that's fine
20:32:19 <sdake> ok all done with that topic then ?
20:32:27 <asalkeld> ya
20:32:33 <sdake> #topic open items
20:33:04 <sdake> summit proposals for heat
20:33:06 <stevebaker> heat-cfntools should be in gerrit any second now, so expect some review requests
20:33:10 <sdake> if you have them, submit them ;)
20:33:31 <sdake> nice work there stevebaker
20:33:34 <SpamapS> cool
20:33:39 <shardy> stevebaker: I made a pull request today, do I need to gerrit-ify it?
20:33:59 <stevebaker> shardy: yeah, I've got a pull request that I'll withdraw too
20:34:06 <shardy> ok, cool
20:34:43 <shardy> sdake: re summit, I was going to propose a design session to revisit the in-instance credentials issue
20:34:49 <shardy> where do I propose it?
20:34:56 <sdake> shardy sounds good
20:34:59 <SpamapS> shardy: +1
20:35:12 <sdake> http://summit.openstack.org/
20:35:15 <SpamapS> I'm also keenly interested in the possiblity of per-instance metadata for instance groups
20:35:17 <sdake> push the suggest ession button
20:35:24 <SpamapS> something I've only recently figured out I probably need
20:35:39 <asalkeld> so trusts are in, do we want to make use of them now?
20:35:53 <SpamapS> can perhaps fold it into the rolling updates session, but that seems like it will be quite a full discussion
20:36:01 <shardy> sdake: ok, I'll add a suggestion, thanks
20:36:03 <sdake> if by now, you mean havana, possibly
20:36:11 <asalkeld> since they were put in for us
20:36:17 <SpamapS> asalkeld: probably worth investigation in that session yeah
20:36:32 <shardy> asalkeld: they don't solve the in-instance problem, but might help with the stored context problem
20:36:40 <asalkeld> agree
20:36:50 <asalkeld> but for the cloud watch poller
20:36:55 <sdake> one thing that came up re openshift integration that kraman is doing
20:37:04 <sdake> is a method for autoscaling to be triggered by the application itself
20:37:07 <SpamapS> do people feel like per-instance metadata for groups is a thing we can discuss? I'll put together a proposal spec and everything.
20:37:09 <sdake> rather then infrastructure outside
20:37:09 <shardy> Yep, I'll add usage of trusts to the authentication-way-forward session proposal
20:37:16 <sdake> spamaps ack
20:37:44 <sdake> asalkeld you have any thoughts on app triggered scaling
20:37:49 <zaneb> SpamapS: AutoscalingGroups or InstanceGroups?
20:37:56 <SpamapS> zaneb: InstanceGroups
20:38:12 <zaneb> cool
20:38:24 <SpamapS> zaneb: specifically, I want to provide them with per-instance credentials to a database and a queue system.
20:38:25 <asalkeld> zaneb, SpamapS just use nested stacks
20:38:31 <shardy> SpamapS: The main thing I'm not sure on is the interface, since the interfaces share a launch configuration, meaning you can't define the metadata update via UpdateStack
20:38:42 <shardy> but happy to discuss it so we can work out a solution ;)
20:38:56 <SpamapS> shardy: yeah thats the bit that needs some thought, and I'm willing to design that if you guys think its not totally insane. :)
20:39:16 <asalkeld> sdake I'll need to think that through
20:39:27 <SpamapS> I do have some ideas for combining LaunchConfiguration with WaitCondition
20:39:32 <sdake> asalkeld can you think about it and shoot me an email ;)
20:39:34 <SpamapS> but, lets not design it in here :)
20:39:42 <shardy> SpamapS: As asalkeld says, a possibly easier solution would be nested stacks, with the nested template effectively defining the InstanceGroup
20:40:02 <asalkeld> yip
20:40:09 <SpamapS> hm
20:40:22 <SpamapS> you're basically saying give each one an Instance resource?
20:40:30 <asalkeld> yes
20:40:31 <SpamapS> thats my workaround currently.
20:40:33 <shardy> yep
20:40:40 <SpamapS> but then that plays poorly with rolling updates.
20:40:40 <shardy> but in a nested template
20:41:02 <asalkeld> how so
20:41:12 <SpamapS> as I end up having to build rolling updates using WaitConditions.. which.. will work, but seems inelegant and crude.
20:41:51 <asalkeld> well we can talk at summit about that
20:42:01 <SpamapS> exactly
20:42:03 <zaneb> idea of per-instance metadata sounds fine for InstanceGroups if you can find a sane interface
20:42:10 <shardy> +1
20:42:24 * SpamapS will propose a session and send a ML post with a draft proposal
20:42:32 <zaneb> for AutoscalingGroups we should stick to the AWS interface IMO
20:42:55 <SpamapS> zaneb: +1, lets not break AWS for my crazy use cases. :)
20:43:11 <asalkeld> zaneb, for sure - more ment to use the resourcestack class
20:43:16 <SpamapS> btw CloudFormation added rolling updates to autoscaling groups in case anybodymissed that
20:43:56 <asalkeld> yea, they are sneaking features out all the time
20:44:05 <asalkeld> (just like us)
20:44:33 <sdake> ok anything else?
20:44:48 <shardy> I have another item re template format
20:44:54 <sdake> shoot
20:45:23 <shardy> I was asked if we plan to stick with the AWS templates, or if we are working towards supporting some "openstack blessed" more open template syntax
20:45:33 <sdake> asked by who?
20:45:43 <asalkeld> many ask that
20:46:05 <sdake> nobody has proposed a new template format
20:46:08 <shardy> I know near-term we'll stick to CFN/yaml, but do we have a longer term objective to support something else, if so is there a viable alternative?
20:46:16 <sdake> that is what summit submissions are for
20:46:52 <SpamapS> http://summit.openstack.org/cfp/details/78  btw
20:47:16 <zaneb> different != better
20:47:29 <SpamapS> shardy: I think it would be a fundamental change for little gain.
20:47:33 <zaneb> I would happily entertain any suggestions for a better template format
20:47:37 <shardy> Ok, I just wanted to see if anyone had any thoughts on the matter
20:47:42 <stevebaker> I'm thinking incremental improvements at the moment
20:47:50 <SpamapS> I definitely can see wanting to get away from potential trademark infringement by removing AWS/EC2/S3/etc. though
20:48:02 <sdake> my thought is if someone wants to add a new template format, they will submit a talk at openstack summit
20:48:13 <zaneb> all I hear is suggestions for a different template format, with no justification except that it can be incompatible
20:48:14 <stevebaker> SpamapS: yes, a full suite of native resources should be on the plan
20:48:26 <zaneb> as if that were a good thing
20:48:30 * stevebaker ponders ansible integration
20:48:44 <sdake> new shinies !
20:48:46 <sdake> ok
20:48:51 <sdake> well I'd like to wrap up
20:48:54 <sdake> #topic agenda setting
20:48:55 <SpamapS> The template format, sans amazon trademarks, is up for discussion as a way to express the full deployment of OpenStack
20:49:15 <sdake> we have alot of stuff in the open discussoin session that should be on the agenda
20:49:18 <sdake> I'm guilty as everyone else ;)
20:49:23 <SpamapS> good point sdake
20:49:43 <sdake> but in the future, if you could add your topics to the agenda it may help the meeting avoid some crosstalk
20:49:49 <sdake> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:49:56 <sdake> add right under "Open Discussion"
20:50:07 <sdake> sorry right above
20:50:09 <shardy> sdake: yeah, sorry, my topic came up late in the day
20:50:12 <sdake> np
20:50:16 <shardy> s/topic/question
20:50:28 <sdake> feel free to add before meeting and if we can get to it we will
20:50:39 <sdake> ok thanks
20:50:54 <sdake> remember, march 14th would like all the buggies fixed 20th latest
20:51:00 <sdake> #endmeeting