12:05:09 <zaneb> #startmeeting heat
12:05:10 <openstack> Meeting started Wed Jul 23 12:05:09 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:05:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:05:13 <openstack> The meeting name has been set to 'heat'
12:05:37 <zaneb> does anybody located where it is not 7am want to chair?
12:06:15 <zaneb> #topic roll call
12:06:24 <tspatzier> hi
12:06:28 <skraynev> o/
12:06:32 <BillArnold> hi
12:06:46 <tspatzier> zaneb: I am in the US this week, so also 7am for me. But I can chair one of the next meetings when I am back in Europe
12:07:12 <zaneb> shardy and stevebaker are at the TripleO meetup, so I don't expect to see them this week
12:07:17 <zaneb> tspatzier: ok, thanks :)
12:07:28 <zaneb> it may be a short meeting
12:08:10 <zaneb> I have been away pretty much since the last meeting, so I have no idea what's been happening
12:08:22 <zaneb> #topic Adding items to the agenda
12:08:37 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-07-23_1200_UTC.29
12:08:43 <zaneb> we have nothing so far
12:10:39 <zaneb> ok, should be an easy one :)
12:10:51 <zaneb> #topic Review action items from last meeting
12:10:52 <skraynev> yeah, just one critical problem :) which is on merging now
12:11:04 <zaneb> zaneb create plan for issues identified in gap analysis
12:11:10 <zaneb> this is done
12:11:17 <shardy> Morning all
12:11:20 <zaneb> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Heat_Gap_Coverage
12:11:22 <shardy> sorry, but late
12:11:25 <zaneb> morning shardy :)
12:11:29 <shardy> s/but/bit
12:11:38 <zaneb> join the club ;)
12:11:42 <tspatzier> ah, shardy might have some short update from the tripleo meetup
12:11:42 <skraynev> good morning shardy :)
12:11:57 <tspatzier> hi shardy
12:12:14 <zaneb> we don't yet have a schedule and owner for the Tempest test stuff above
12:12:16 <shardy> Yep, and we've not yet done the release, planned for this morning so we can have a last sync on that
12:12:27 <zaneb> ok, cool
12:12:56 <zaneb> I'm planning to discuss with the TC what an appropriate schedule for improved testing would look like
12:13:07 <zaneb> it's a bit of a weird one, since that is never "done"
12:13:29 <shardy> zaneb: stevebaker pointed out a ML thread yesterday which did confirm plans to move at least some tests into project trees
12:13:46 <shardy> IMO we should push on that happening soon so we can improve review velocity
12:13:55 <zaneb> shardy: is there a time frame for that to happen?
12:14:04 <shardy> zaneb: not sure, that's what we need to find out
12:14:15 <zaneb> ok
12:14:18 <shardy> the mail was from dkranz so I'll ask him
12:14:56 <zaneb> #info at least some functional tests will move from Tempest into project trees. Need to confirm schedule.
12:15:03 <BillArnold> shardy that movement of tests to project trees would be the single best change.
12:16:06 <shardy> BillArnold: Yup I agree, the current process isn't working at all IMO
12:16:59 <zaneb> #topic juno-2 milestone update
12:17:05 <zaneb> shardy: where are we at?
12:17:26 <shardy> #link https://launchpad.net/heat/+milestone/juno-2
12:17:46 <shardy> zaneb: So, basically done with the exception of your attribute series
12:17:59 <shardy> which got blocked by a new keystoneclient release breaking our tests
12:18:13 <shardy> I posted a fix for that last night, not sure if it merged yet
12:18:26 <shardy> Same thing stopped therve's move to oslo.db landing
12:18:42 <zaneb> ok, I'm relaxed if that doesn't make it
12:18:44 <shardy> zaneb: So unless the gate queue looks bad, I propose we get those in then cut the release
12:18:54 <zaneb> obviously the keystone client fix *needs* to be merged :)
12:19:14 <shardy> https://review.openstack.org/#/c/108875/1
12:19:18 <shardy> Ok that's the test fix
12:19:29 <therve> It's in progress
12:19:36 <therve> The gate is slow for some reasons
12:19:55 <tspatzier> hm, yeah, already hanging around for 4 hours
12:20:01 <shardy> Hmm, yeah yesterday it was really quick :(
12:20:28 <shardy> zaneb, therve: what is your opinion, should we just land the client fix then tag the release?
12:20:33 <zaneb> the gate is slow because it's milestone day ;)
12:20:43 <shardy> then get your changes in immediately after?
12:21:01 <shardy> zaneb: well I expected a rush yesterday but most of the day it was fine :)
12:21:06 <therve> I don't care about the oslo.db change being in -2
12:21:06 <zaneb> I'm fine if my bug doesn't go in
12:21:25 <shardy> Ok, I'll wait for the client test fix to land then ping russellb
12:21:31 <therve> So +1 for making the release
12:22:06 <skraynev> agree with therve, let's do it as soon as possible :)
12:22:50 <shardy> Ok sounds like a plan, I've bumped 1341048 to J3 again
12:24:30 <shardy> zaneb: since the tripleo meetup was mentioned, I have a related question, if we're done with J2 items?
12:24:46 <zaneb> #topic TripleO meetup update
12:24:54 <shardy> zaneb: basically what is the status of fixing updates
12:25:14 <zaneb> in progress :/
12:25:28 <shardy> That, from dicussions here and watching derekh try (and fail) to update a tripleo overcloud seems super high priority
12:25:45 <zaneb> I wanted to have it done by now, but I just got too far behind
12:26:17 <shardy> zaneb: I see a lot of patches have landed already, any feeling for how much more is left?
12:26:20 <therve> What's the specific issue?
12:26:33 <shardy> therve: Not being able to re-try a failed update
12:26:47 <shardy> so any mistake in the template permanently wedges the stack
12:26:53 <therve> Okay
12:27:25 <zaneb> shardy: I'm working on it now, but it's unlikely to be done this week
12:27:52 <shardy> zaneb: Cool, no worries, the question was more are we on target to complete it for Juno really
12:29:10 <zaneb> yeah, I am committed to getting it done for Juno
12:29:29 <shardy> zaneb: Nice, thanks - I know it's a lot of work
12:29:45 <zaneb> hopefully the harder part is done :)
12:29:46 <BillArnold> zaneb this involves tighter tracking of the progress of the stack operstion?
12:29:55 <zaneb> BillArnold: correct
12:30:23 <zaneb> so we have the part where we maintain the template as we go
12:30:33 <shardy> stevebaker and I also had a discussion yesteday about moving nested stacks to creating via an RPC call to the engine, so each nested stack has a different lock and can be distributed over multiple engines
12:30:46 <zaneb> we still need the part where we remember what properties went with that snippet, since parameters can also change
12:30:54 <shardy> I had a look and it looks do-able but non-trivial, any thoughts on that?
12:31:16 <shardy> The idea would be improving scalability with the existing architecture, pre the full convergence move
12:31:36 <shardy> (if that's too OT for here we can take it to #heat after)
12:31:40 <zaneb> shardy: I think that will break stuff like autoscaling, unfortunately
12:31:49 <BillArnold> shardy is scalability for bad enough now for some important use case?
12:32:07 <shardy> BillArnold: Basically yes, for large tripleo deployments
12:32:41 <shardy> zaneb: Ok, I'll have to dig into it more to understand why
12:32:43 <zaneb> shardy: unless by nested stacks you only mean AWS::CloudFormation::Stack?
12:33:02 <shardy> zaneb: well that could be a starting point, but really I meant all nested stacks, eventually
12:33:18 <therve> I don't think tripleo uses that anyway
12:33:21 <zaneb> +1 for AWS::CloudFormation::Stack
12:33:42 <shardy> therve: they are moving to a model where each chunk of functionality will live in a provider resource
12:34:02 <shardy> So making nested stacks more scalable would be a huge win in that case
12:34:05 <zaneb> for all nested stacks, I'm pretty sure there is a lot of code where the parent resource relies on the nested stack being loaded in memory while it is in progress
12:34:36 <shardy> zaneb: Yeah, looking yesterday that is definitely the case, I'm not quite certain how hard it will be to decouple that atm though
12:34:56 <shardy> probably somwhere between "hard" and "extremely hard" ;)
12:34:57 <zaneb> yeah, I couldn't tell you off the top of my head
12:35:09 <zaneb> that sounds like a good first guess ;)
12:35:34 <shardy> I may spend some time looking into it anyway, unless anyone is strongly opposed to at least investigating it :)
12:35:42 <tspatzier> would the RemoteStack resource for multi-region help in any way?
12:35:49 <zaneb> not at all :)
12:36:10 <shardy> tspatzier: well stevebaker made the same point yesterday, I've not had time to find out yet
12:36:22 <tspatzier> ok
12:36:41 <BillArnold> shardy remote resource would actually be local?
12:37:13 <shardy> BillArnold: Yeah, I guess it'd be a non-remote-remote-resource ;)
12:37:21 <tspatzier> lol
12:37:29 <shardy> really I was looking for a more transparent solution that that
12:38:10 <zaneb> shardy, tspatzier: at least for the hard-to-very-hard cases I suspect we will end up needing to pass more data than we want to do through the ReST API, so using the RPC API sounds like a good option
12:38:23 <shardy> like make StackResource pluggable and abstract things there
12:38:39 <shardy> zaneb: Yeah, I think we'd definitely need to add more to the RPC API
12:38:47 <shardy> and the ReST API would use only a subset
12:38:54 <zaneb> +1
12:39:49 <shardy> Nothing more to report re TripleO really, I think update and scalability are the main priorities atm
12:40:10 <therve> shardy, Is work around convergence starting?
12:40:12 <zaneb> shardy: where are they at with scale atm?
12:40:28 <BillArnold> shardy would be best if there were some more tempest tests of nested stacks, to increase the odds of catching regressions
12:40:54 <shardy> zaneb: That is hard to quantify, really we need a benchmark test which doesn't involve having a room full of servers running tripleo
12:41:23 <shardy> BillArnold: Yeah I will write some before proposing any major changes to Heat
12:41:57 <shardy> therve: That's not been discussed here much tbh, and it's only Steve and I from the heat team
12:42:10 <therve> Okay
12:42:13 <shardy> I guess that's the main topic of the heat meetup ;)
12:42:30 <therve> It'd be too late though that point
12:42:33 <zaneb> shardy: tbh, I was surprised that they ran in to performance issues so early, even though we didn't do any premature optimisation at all
12:42:51 * zaneb idly wonders if eventlet is actually doing its job
12:42:51 <shardy> My feeling is we need to focus on getting that work started, but also more immediately landing interim improvements
12:43:29 <shardy> e.g fix update, get stevebaker's client retry logic in, maybe rework for better scalability as previously discussed
12:44:23 <zaneb> I agree, we can't neglect that stuff even though we have bigger plans for the future
12:46:58 <shardy> 15mins, any other items to discuss?
12:47:11 <zaneb> #topic open discussion
12:48:50 <zaneb> shardy: do we believe that we are using eventlet to monkey-patch socket calls?
12:49:11 <shardy> zaneb: Not sure tbh
12:49:58 <shardy> heat-engine does eventlet.monkey_patch() which monkey-patches all-the-things
12:50:09 <shardy> but the API's do os=False
12:50:31 <shardy> So I guess we're probably not?
12:50:45 <zaneb> ah, there
12:51:05 <zaneb> I was looking for the call, but didn't spot it in bin/heat-engine
12:51:17 <shardy> grep ftw ;)
12:51:49 <zaneb> yeah, my grep missed it because it wasn't in a .py file
12:51:59 <shardy> ah
12:52:44 <zaneb> ok, if there's nothing else we can wrap up and I can go get some breakfast :)
12:53:05 <shardy> good plan :)
12:53:22 <zaneb> thanks everyone!
12:53:25 <zaneb> #endmeeting