12:00:36 #startmeeting heat 12:00:37 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:40 The meeting name has been set to 'heat' 12:01:04 o/ 12:01:08 who is here? 12:01:11 hi 12:01:13 good day all 12:01:13 o/ 12:01:20 hi 12:01:28 /o/ 12:01:44 hi all 12:01:56 hi 12:04:30 hi all 12:05:09 sorry guys, unplanned reboot 12:05:29 I guess gnome shell doesn't like mornings either 12:05:55 xfce ftw ;) 12:06:02 lol 12:06:24 just have to wait for zaneb to timeout so I can reclaim that username and use meetingbot 12:06:29 sigh 12:06:58 go 12:07:01 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda 12:07:34 #topic Review last meeting's actions 12:08:16 #link http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-06-04-20.00.html 12:08:33 andrew_plunk is presumably not here 12:08:50 #action zaneb sync with andrew_plunk on rackspace CI job 12:09:02 same for stevebaker, I suppose 12:09:08 yep 12:09:27 #action zaneb sync with stevebaker on heat-slow job & making it voting 12:09:56 That's been looking pretty good lately 12:10:02 #action zaneb sync with stevebaker on metadata api compat patch 12:10:14 yeah, the gate is looking remarkably stable atm 12:10:33 #topic Adding items to the agenda 12:10:37 anybody? 12:10:46 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda 12:11:12 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 ResourceDefinition and plugin API stability 12:11:40 and identifying the plugin API 12:11:58 mspreitz: ok 12:12:13 pas-ha: that looks worrying 12:12:24 #topic Mid-cycle meetup 12:12:30 at least two time in a row in a recheck 12:13:08 zaneb i saw that sql problem yesterday, once. 12:13:21 it sounds like there is not a lot of point in holding a mid-cycle meetup in conjunction with TripleO 12:13:38 since key people like SpamapS and shadower can't be there 12:13:40 zaneb: Really? I thought that was the plan? 12:14:24 and tbh I would rather not cancel my holiday if it's not going to be for something useful 12:14:41 SpamapS suggested we split out the Heat one and hold it in August 12:14:47 is there any support for that? 12:14:55 also about gate was such bug https://bugs.launchpad.net/heat/+bug/1328669 , but I have not met it . 12:14:56 Launchpad bug 1328669 in heat "Failure in neutron SetUp class during check-tempest-dsvm-neutron-heat-slow" [Undecided,New] 12:15:21 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 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 as the organizer of TripleO meeting, it was very hard to find dates 12:15:59 as there still seems to be a lack of regular information flow between the teams re issues and requirements 12:16:01 SpamapS cand do only second half of August 12:16:23 and there are other people who can't do it that time 12:16:28 Does that even qualify as mid-cycle? 12:16:45 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 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 mspreitz: it's not at the summit, so yes :) 12:18:15 zaneb: time-wise I'm fine any time in August 12:18:34 but if you decide to split, it would be great to have people from Heat at TripleO meetup and vice-versa 12:18:51 shardy: would you prefer to go ahead with the combined one? 12:20:19 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 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 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 ok, let's discuss with SpamapS when he wakes up 12:22:20 yeah, that would be good to avoid :) 12:23:06 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 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 Yeah, and trying to orgainize such an event around summer holiday time is always going to be difficult 12:24:27 yeah, the summer one is always going to be harder 12:24:50 and in this case even the idea of having a meetup wasn't on the radar before summit 12:24:55 #topic Plugin API stability 12:25:09 we discussed this a little last week 12:25:19 mspreitz: but I gather you want to continue that 12:25:24 Perusing the code, it is not obvious to me that there is a well-defined plugin API 12:25:37 the plugin gets its hands on the Resource, and can poke around any way it wants 12:26:05 This was inspired by wondering whether ResourceDefinition changes the plugin API 12:26:11 agreed, the boundaries of what is public are not well-defined 12:26:20 mspreitz: it does not 12:26:43 at least, not yet 12:26:54 The handle_update method gets new snippet, right? 12:26:59 but there is stuff we will want to deprecate and eventually remove 12:27:36 mspreitz: yes, but it's backwards-compatible for now though 12:28:04 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 But the point of ResourceDefinition is to move away from snippets 12:28:17 http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/rsrc_defn.py#n259 12:28:36 it's all explained in that docstring ^ 12:30:05 I'm having trouble understanding it... 12:30:21 "This class ... will eventually be deprecated and replaced by ResourceDefinition" 12:30:45 ResourceDefinitionCore 12:31:15 oh, right 12:31:30 So ResourceDefinition is intended to look like a JSON snippet? 12:31:37 exactly 12:32:14 so at some point we delete it and write ResourceDefinition = ResourceDefinitionCore 12:32:20 zaneb: And after we work out plugin interface versioning, we might be able to lose the compatibility shim, right? 12:32:27 but that will only be after a deprecation period 12:32:57 shardy: hopefully 12:33:32 it seems like with this whole convergence business we _may_ end up needing an entirely new plugin api 12:33:43 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 mspreitz: yeah, I think that's a fair summary 12:34:29 the policy we came up with last week is to deprecate for at least an entire release cycle before removing 12:34:36 I think ResourceDefinitionCore is at least a move in the right direction for Convergence 12:34:59 It might be most of what is needed 12:35:06 that's good, because I came up with it before the convergence idea was on the table :) 12:35:28 Is there any thought about how plugin API versioning might be done? 12:35:53 candidly, no 12:36:29 ideas welcome on that 12:36:40 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 yay, problem solved ;) 12:37:35 shardy: lol 12:38:00 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 seems like it could get messy though 12:39:04 Different base classes sounds like a particular edition of what I said 12:39:10 and yes, it can get messy 12:39:56 But what worries me most is the surface area of the API 12:40:20 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 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 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 Could we move towards a naming convention that identifies public part? 12:42:28 I am not familiar with Stevedore; is there a short sharp summary? 12:42:41 http://stevedore.readthedocs.org/ 12:43:06 ceilometer uses it 12:43:33 shardy: maybe. I like to think that e.g. the parser plugins are a bit more explicit 12:44:01 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 our Resource implementation existed before the idea of plugins was even considered 12:44:30 and it's just been hacks on top of hacks ever since ;) 12:45:59 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 probably worth a bit of investigation and/or chatting to the ceilometer folks 12:46:52 shardy: if you look at http://stevedore.readthedocs.org/en/latest/tutorial/creating_plugins.html#a-plugin-base-class 12:47:06 there's nothing stopping us from doing that right now 12:47:21 and in fact the parser plugins look a lot like that 12:47:44 it's nothing to do with stevedore per se 12:48:20 #topic Critical issues sync 12:48:31 shardy: do we have any critical issues? 12:48:54 BillArnold_: do you want to talk about the performance issue? 12:49:40 BillArnold_: was good to hear my auth_token patch helped 12:49:54 tspatzier: you mean performance between havana and icehouse ? or something else? 12:50:12 yeah, I saw the update to the bug. so is there something else, or is it good now? 12:50:25 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 https://bugs.launchpad.net/heat/+bug/1324102 12:50:29 Launchpad bug 1324102 in heat "Slowdown in create stack request between Havana and Icehouse" [Medium,New] 12:50:49 shardy i'm wondering if there are simply more calls to keystone 12:50:51 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 BillArnold_: actually, there were more calls in Havana, because we created clients for both v2 and v3 12:51:25 BillArnold_, could that be due to token/request size increase? 12:51:52 It *could* be that v3 calls are just more expensive though 12:51:54 shardy perhaps. more profiling is in order. 12:52:01 BillArnold_: +1 12:52:19 #link https://bugs.launchpad.net/heat/+bug/1324102 12:52:22 Launchpad bug 1324102 in heat "Slowdown in create stack request between Havana and Icehouse" [Medium,New] 12:52:32 shardy ok. would uuid vs pki make a difference? 12:52:46 BillArnold_: quite possibly 12:53:19 shardy will do more profiling today then. 12:53:44 How are UUID and Public Key Infrastructure alternatives? 12:53:50 shardy are there any recommended tools for profiling? I was just adding a decorator for entry/exit. 12:55:39 mspreitz: it's more keystone tokens vs. signatures 12:56:32 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 shardy entry/exit logging is sufficient 12:57:56 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 answer is probably yes. 12:58:26 shardy: thanks 12:59:20 ok, time is about up 12:59:26 Does anybody here understand Boris' rally? 12:59:53 it is about performance profiling 13:00:08 That is about the sum total of my knowledge 13:00:08 #endmeeting