12:00:36 <zaneb> #startmeeting heat
12:00:37 <openstack> Meeting started Wed Jun 11 12:00:36 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:40 <openstack> The meeting name has been set to 'heat'
12:01:04 <mspreitz> o/
12:01:08 <zaneb> who is here?
12:01:11 <sorantis> hi
12:01:13 <skraynev> good day all
12:01:13 <shardy> o/
12:01:20 <BillArnold_> hi
12:01:28 <therve> /o/
12:01:44 <tspatzier> hi all
12:01:56 <kirankv> hi
12:04:30 <pas-ha> hi all
12:05:09 <zb> sorry guys, unplanned reboot
12:05:29 <zb> I guess gnome shell doesn't like mornings either
12:05:55 <shardy> xfce ftw ;)
12:06:02 <zb> lol
12:06:24 <zb> just have to wait for zaneb to timeout so I can reclaim that username and use meetingbot
12:06:29 <zb> sigh
12:06:58 <tspatzier> go
12:07:01 <zb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:07:34 <zaneb> #topic Review last meeting's actions
12:08:16 <zaneb> #link http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-06-04-20.00.html
12:08:33 <zaneb> andrew_plunk is presumably not here
12:08:50 <zaneb> #action zaneb sync with andrew_plunk on rackspace CI job
12:09:02 <skraynev> same for stevebaker, I suppose
12:09:08 <zaneb> yep
12:09:27 <zaneb> #action zaneb sync with stevebaker on heat-slow job & making it voting
12:09:56 <shardy> That's been looking pretty good lately
12:10:02 <zaneb> #action zaneb sync with stevebaker on metadata api compat patch
12:10:14 <zaneb> yeah, the gate is looking remarkably stable atm
12:10:33 <zaneb> #topic Adding items to the agenda
12:10:37 <zaneb> anybody?
12:10:46 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:11:12 <pas-ha> not really stable, getting this quite often http://logs.openstack.org/13/99113/1/check/check-tempest-dsvm-full/e6eeb2c/logs/screen-h-eng.txt.gz?level=TRACE
12:11:15 <mspreitz> ResourceDefinition and plugin API stability
12:11:40 <mspreitz> and identifying the plugin API
12:11:58 <zaneb> mspreitz: ok
12:12:13 <zaneb> pas-ha: that looks worrying
12:12:24 <zaneb> #topic Mid-cycle meetup
12:12:30 <pas-ha> at least two time in a row in a recheck
12:13:08 <BillArnold_> zaneb i saw that sql problem yesterday, once.
12:13:21 <zaneb> it sounds like there is not a lot of point in holding a mid-cycle meetup in conjunction with TripleO
12:13:38 <zaneb> since key people like SpamapS and shadower can't be there
12:13:40 <shardy> zaneb: Really?  I thought that was the plan?
12:14:24 <zaneb> and tbh I would rather not cancel my holiday if it's not going to be for something useful
12:14:41 <zaneb> SpamapS suggested we split out the Heat one and hold it in August
12:14:47 <zaneb> is there any support for that?
12:14:55 <skraynev> also about gate was such bug https://bugs.launchpad.net/heat/+bug/1328669 , but I have not met it .
12:14:56 <uvirtbot> Launchpad bug 1328669 in heat "Failure in neutron SetUp class during check-tempest-dsvm-neutron-heat-slow" [Undecided,New]
12:15:21 <tspatzier> zaneb: August would be fine for me, but only the first half - and ok with splitting it out if there are enough topics
12:15:35 <shardy> zaneb: If we're not going to be doing a combined meetup, I think we need to work out some other way to improve TripleO-Heat communication
12:15:37 <jcoufal> as the organizer of TripleO meeting, it was very hard to find dates
12:15:59 <shardy> as there still seems to be a lack of regular information flow between the teams re issues and requirements
12:16:01 <jcoufal> SpamapS cand do only second half of August
12:16:23 <jcoufal> and there are other people who can't do it that time
12:16:28 <mspreitz> Does that even qualify as mid-cycle?
12:16:45 <zaneb> shardy: agreed. the idea would be to do it at a time where we could get the key TripleO people like SpamapS and shadower (who understand Heat already) there
12:16:54 <jcoufal> and furthermore late August it is very close to feature freeze which from my point of view doesn't make big sense
12:17:02 <zaneb> mspreitz: it's not at the summit, so yes :)
12:18:15 <shadower_> zaneb: time-wise I'm fine any time in August
12:18:34 <jcoufal> but if you decide to split, it would be great to have people from Heat at TripleO meetup and vice-versa
12:18:51 <zaneb> shardy: would you prefer to go ahead with the combined one?
12:20:19 <shardy> zaneb: I think as jcoufal says, it would be very helpful to have at least a few folks representing heat/tripleo respectively if we do split
12:21:16 <shardy> zaneb: I was just under the impression combined was the way we were headed based on the ML discussion, but provided we can get at least a couple of TripleO representatives along when we meet, I'm flexible
12:21:56 <shardy> zaneb: what I *really* want to avoid is getting to Paris then hearing we're not meeting TripleO requirements because we didn't know about them..
12:22:03 <zaneb> ok, let's discuss with SpamapS when he wakes up
12:22:20 <zaneb> yeah, that would be good to avoid :)
12:23:06 <zaneb> unfortunately there are no really good answers here except to plan the _next_ midcycle meetup _before_ the summit so that everyone can arrange their calendars around it
12:23:25 <jcoufal> also if you think about the split, think about dates, because there wasn't very big agreement on August dates as well
12:23:45 <shardy> Yeah, and trying to orgainize such an event around summer holiday time is always going to be difficult
12:24:27 <zaneb> yeah, the summer one is always going to be harder
12:24:50 <zaneb> and in this case even the idea of having a meetup wasn't on the radar before summit
12:24:55 <zaneb> #topic Plugin API stability
12:25:09 <zaneb> we discussed this a little last week
12:25:19 <zaneb> mspreitz: but I gather you want to continue that
12:25:24 <mspreitz> Perusing the code, it is not obvious to me that there is a well-defined plugin API
12:25:37 <mspreitz> the plugin gets its hands on the Resource, and can poke around any way it wants
12:26:05 <mspreitz> This was inspired by wondering whether ResourceDefinition changes the plugin API
12:26:11 <zaneb> agreed, the boundaries of what is public are not well-defined
12:26:20 <zaneb> mspreitz: it does not
12:26:43 <zaneb> at least, not yet
12:26:54 <mspreitz> The handle_update method gets new snippet, right?
12:26:59 <zaneb> but there is stuff we will want to deprecate and eventually remove
12:27:36 <zaneb> mspreitz: yes, but it's backwards-compatible for now though
12:28:04 <shardy> mspreitz: well, I'd say what we document should stay as stable as possible, e.g http://docs.openstack.org/developer/heat/pluginguide.html
12:28:07 <mspreitz> But the point of ResourceDefinition is to move away from snippets
12:28:17 <zaneb> http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/rsrc_defn.py#n259
12:28:36 <zaneb> it's all explained in that docstring ^
12:30:05 <mspreitz> I'm having trouble understanding it...
12:30:21 <mspreitz> "This class ... will eventually be deprecated and replaced by ResourceDefinition"
12:30:45 <zaneb> ResourceDefinitionCore
12:31:15 <mspreitz> oh, right
12:31:30 <mspreitz> So ResourceDefinition is intended to look like a JSON snippet?
12:31:37 <zaneb> exactly
12:32:14 <zaneb> so at some point we delete it and write ResourceDefinition = ResourceDefinitionCore
12:32:20 <shardy> zaneb: And after we work out plugin interface versioning, we might be able to lose the compatibility shim, right?
12:32:27 <zaneb> but that will only be after a deprecation period
12:32:57 <zaneb> shardy: hopefully
12:33:32 <zaneb> it seems like with this whole convergence business we _may_ end up needing an entirely new plugin api
12:33:43 <mspreitz> OK, so the current plan is there is an API change in the works, and it is to be done with compatability for a while
12:34:02 <zaneb> mspreitz: yeah, I think that's a fair summary
12:34:29 <zaneb> the policy we came up with last week is to deprecate for at least an entire release cycle before removing
12:34:36 <mspreitz> I think ResourceDefinitionCore is at least a move in the right direction for Convergence
12:34:59 <mspreitz> It might be most of what is needed
12:35:06 <zaneb> that's good, because I came up with it before the convergence idea was on the table :)
12:35:28 <mspreitz> Is there any thought about how plugin API versioning might be done?
12:35:53 <zaneb> candidly, no
12:36:29 <zaneb> ideas welcome on that
12:36:40 <mspreitz> The first thought that comes to my mind is this: plugin sports something that identifies API version it likes, engine examines that and calls plugin appropriately
12:37:17 <shardy> yay, problem solved ;)
12:37:35 <skraynev> shardy: lol
12:38:00 <zaneb> the first thought that comes to mind for me is that we have Resource, ResourceV2, &c. classes that plugins can inherit from
12:38:39 <zaneb> seems like it could get messy though
12:39:04 <mspreitz> Different base classes sounds like a particular edition of what I said
12:39:10 <mspreitz> and yes, it can get messy
12:39:56 <mspreitz> But what worries me most is the surface area of the API
12:40:20 <mspreitz> The Guide today says what the plugin must implement, but puts no limit on how much the plugin gets into the Resource guts
12:41:18 <zaneb> yeah, and in retrospect we could have been a bit more explicit with e.g. naming things with a leading underscore to indicate what parts of the api should and should not be considered stable
12:41:47 <shardy> zaneb: I wonder if we can look at existing stuff like stevedore and see if defining the abstract interfaces via that might help
12:42:03 <mspreitz> Could we move towards a naming convention that identifies public part?
12:42:28 <mspreitz> I am not familiar with Stevedore; is there a short sharp summary?
12:42:41 <shardy> http://stevedore.readthedocs.org/
12:43:06 <shardy> ceilometer uses it
12:43:33 <zaneb> shardy: maybe. I like to think that e.g. the parser plugins are a bit more explicit
12:44:01 <zaneb> I don't think it's a matter of using a particular tool so much as designing the API with plugins in mind
12:44:16 <zaneb> our Resource implementation existed before the idea of plugins was even considered
12:44:30 <zaneb> and it's just been hacks on top of hacks ever since ;)
12:45:59 <shardy> zaneb: Yeah, I've not got personal experience with it, just wondering if we can leverage existing stuff instead of too much wheel reinvention
12:46:18 <shardy> probably worth a bit of investigation and/or chatting to the ceilometer folks
12:46:52 <zaneb> shardy: if you look at http://stevedore.readthedocs.org/en/latest/tutorial/creating_plugins.html#a-plugin-base-class
12:47:06 <zaneb> there's nothing stopping us from doing that right now
12:47:21 <zaneb> and in fact the parser plugins look a lot like that
12:47:44 <zaneb> it's nothing to do with stevedore per se
12:48:20 <zaneb> #topic Critical issues sync
12:48:31 <zaneb> shardy: do we have any critical issues?
12:48:54 <tspatzier> BillArnold_: do you want to talk about the performance issue?
12:49:40 <shardy> BillArnold_: was good to hear my auth_token patch helped
12:49:54 <skraynev> tspatzier: you mean performance between havana and icehouse ? or something else?
12:50:12 <tspatzier> yeah, I saw the update to the bug. so is there something else, or is it good now?
12:50:25 <BillArnold_> mspreitz yes, i tried shardys token patch yesterday and it improved performance of stack create rest calls to close to havana levels.
12:50:28 <tspatzier> https://bugs.launchpad.net/heat/+bug/1324102
12:50:29 <uvirtbot> Launchpad bug 1324102 in heat "Slowdown in create stack request between Havana and Icehouse" [Medium,New]
12:50:49 <BillArnold_> shardy i'm wondering if there are simply more calls to keystone
12:50:51 <shardy> tspatzier: well the profiling indicates the auth overhead didn't cause the slowdown, because we were doing it the slow way in Havana as well as Icehouse
12:51:23 <shardy> BillArnold_: actually, there were more calls in Havana, because we created clients for both v2 and v3
12:51:25 <pas-ha> BillArnold_, could that be due to token/request size increase?
12:51:52 <shardy> It *could* be that v3 calls are just more expensive though
12:51:54 <BillArnold_> shardy perhaps. more profiling is in order.
12:52:01 <shardy> BillArnold_: +1
12:52:19 <zaneb> #link https://bugs.launchpad.net/heat/+bug/1324102
12:52:22 <uvirtbot> Launchpad bug 1324102 in heat "Slowdown in create stack request between Havana and Icehouse" [Medium,New]
12:52:32 <BillArnold_> shardy ok. would uuid vs pki make a difference?
12:52:46 <shardy> BillArnold_: quite possibly
12:53:19 <BillArnold_> shardy will do more profiling today then.
12:53:44 <mspreitz> How are UUID and Public Key Infrastructure alternatives?
12:53:50 <BillArnold_> shardy are there any recommended tools for profiling? I was just adding a decorator for entry/exit.
12:55:39 <zaneb> mspreitz: it's more keystone tokens vs. signatures
12:56:32 <shardy> BillArnold_: I don't have any specific reccomendations for python, sorry, I've used oprofile in the past but mostly for profiling C apps.
12:57:38 <BillArnold_> shardy entry/exit logging is sufficient
12:57:56 <shardy> mspreitz: I think the question was, if you were using uuid on Havana, then move to Icehouse while at the same time switching to PKI tokens, does everything keystone related get much more expensive
12:58:04 <shardy> answer is probably yes.
12:58:26 <mspreitz> shardy: thanks
12:59:20 <zaneb> ok, time is about up
12:59:26 <mspreitz> Does anybody here understand Boris' rally?
12:59:53 <mspreitz> it is about performance profiling
13:00:08 <mspreitz> That is about the sum total of my knowledge
13:00:08 <zaneb> #endmeeting