20:00:22 <zaneb> #startmeeting heat
20:00:23 <openstack> Meeting started Wed May 21 20:00:22 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:26 <openstack> The meeting name has been set to 'heat'
20:00:55 <zaneb> #topic Raise your hand if you're not here
20:00:59 <radix> good afternoon
20:01:02 <randallburt> o/
20:01:07 <pas-ha> o/
20:01:09 <radix> ,o
20:01:12 <jasond> o/
20:01:19 <lsmola2> hello
20:01:24 <shardy> o/
20:01:28 <skraynev> hello all
20:01:34 <spzala> Hi
20:01:39 <tango|2> o/
20:01:39 <therve> Hey there
20:01:46 <erecio> Hi
20:01:59 <iqster> Hello all - nice meeting a big part of the heat dev community at the summit last week.
20:02:08 <radix> yep, it was awesome :)
20:02:15 <kebray> o/ I'm here.
20:02:17 <zaneb> stevebaker: about?
20:02:19 <tspatzier> hi all
20:02:22 <bgorski> o/
20:02:27 <jpeeler> hey
20:02:39 <zaneb> hey jpeeler, welcome back
20:02:50 <stevebaker> o/
20:02:52 <jpeeler> thanks
20:02:57 <zaneb> #topic Adding items to the agenda
20:03:08 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:03:18 <zaneb> big turnout and a full agenda today :)
20:03:37 <zaneb> anybody got anything else?
20:04:37 <zaneb> #topic Alternate meeting time
20:04:47 <wirehead_> Oooh!  Just in time to troll! :)
20:04:47 <zaneb> I sent a mail out to the list about this
20:04:57 <zaneb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035480.html
20:05:18 <zaneb> I want to try having the alternate meeting at 1200 UTC, starting next week
20:05:43 <therve> +1 obviously :)
20:05:44 <zaneb> if anybody wishes to enter into correspondence, let them do so now
20:06:19 <zaneb> #topic Rackspace 3rd-party CI job
20:06:20 <pas-ha> +1 for 1200 UTC
20:06:21 <stevebaker> I shall abstain, this meeting isn't for me
20:06:24 <erecio> +1
20:06:29 <skraynev> +
20:06:37 <SpamapS> o/ just running out the door, but wanted to let everybody know that there's a spec in-progress for Convergence here https://blueprints.launchpad.net/heat/+spec/convergence and https://wiki.openstack.org/wiki/Heat/Blueprints/Convergence .
20:06:38 <shardy> +1
20:06:40 <iqster> +1
20:06:41 * SpamapS disappears
20:06:55 <radix> SpamapS: hooray
20:06:57 <zaneb> thanks SpamapS
20:06:59 <andrew_plunk> hey
20:07:17 <zaneb> andrew_plunk: ah, perfect timing :)
20:07:21 <andrew_plunk> ;)
20:08:02 <zaneb> so, I am strongly biased toward +1 for the Rackspace Jenkins to post 3rd party CI stuff to Gerrit
20:08:09 <zaneb> only one question really
20:08:18 <wirehead_> See, if it was an hour later, I'd totally join in during my morning tea, but I'm mostly here to troll. :)
20:08:30 <andrew_plunk> zaneb, there may be false negatives if downstream services are having problems
20:08:35 <andrew_plunk> is the community ok with that?
20:08:39 <zaneb> what percentage of failures are likely to be upstream problems vs. config problems
20:08:49 <shardy> andrew_plunk: I assume it will be non-voting, at least initially?
20:08:59 <stevebaker> andrew_plunk, that may well be the norm for 3rd-party CI
20:09:04 <randallburt> shardy:  I would hope so
20:09:12 <zaneb> +1 for non-voting
20:09:18 * stevebaker shakes fist at XenServer CI
20:09:25 <andrew_plunk> sounds good to me shardy
20:09:27 <zaneb> otherwise it can block upstream
20:09:27 <shardy> randallburt: then I'm +1 on getting it going and seeing how it works out
20:09:37 <randallburt> failures will most likely be downstream failures, but we could build some padding for that in the tests themselves
20:10:06 <stevebaker> well, it can post a -1 on failure, voting isn't really a thing for 3rd party
20:10:39 <jasond> yeah, it'd be under the Code-Review column
20:10:40 <wirehead_> Yeah, I have the shudder of experience at flaky downstreams causing test failures.  It's a shudder unique to the layer at which we work.
20:10:42 <shardy> stevebaker: Ok, so we can overrule it with +2/+A
20:10:52 <shardy> if it's obviously wrong that is ;)
20:11:10 <randallburt> IIRC its mostly to make sure the v2 shim works, yes?
20:11:16 <stevebaker> shardy, yeah, and some form of recheck triggering would be needed eventually
20:11:19 <randallburt> or are we testing more than that?
20:11:38 <stevebaker> randallburt, what cloud does it test against? a devstack?
20:11:48 <randallburt> Rackspace public cloud currently
20:11:58 <stevebaker> randallburt, in standalone mode?
20:12:19 <randallburt> I don't think so. andrew_plunk?
20:12:21 <andrew_plunk> in normal mode with an admin user stevebaker
20:12:43 <pas-ha> you named your admin user stevebaker? :)
20:12:48 <randallburt> lol
20:12:49 <andrew_plunk> haha
20:12:54 <randallburt> no, just steve.
20:12:58 <stevebaker> why not?
20:12:58 <therve> Are the tests publicly available?
20:13:10 <randallburt> therve:  not currently.
20:13:23 <randallburt> I think one of our QE folks is working on that, though
20:13:40 <therve> Okay. Ultimately it'd be cool to know what's going on if it fails
20:13:47 <randallburt> therve:  agreed
20:13:48 <zaneb> andrew_plunk: I think you mentioned we need an official vote for the infra people to enable this?
20:13:59 <andrew_plunk> to enable voting zaneb
20:14:02 <stevebaker> +1
20:14:09 <andrew_plunk> If our jenkins is going to just comment then I don't think it matters
20:14:22 <andrew_plunk> I will take an action item to get it set up today zaneb
20:15:02 <zaneb> #action andrew_plunk to set up a non-voting Rackspace CI Jenkins job against Heat
20:15:18 <zaneb> capital
20:15:22 <zaneb> thanks andrew_plunk
20:15:34 <andrew_plunk> anytime :)
20:15:41 <radix> indeed, chap
20:15:41 <zaneb> #topic  Blueprint process
20:16:13 <zaneb> most projects seem to be switching away from the wiki and toward a blueprint repo
20:16:22 <zaneb> do we want to follow?
20:16:40 <therve> +0. We do have some horrible outdated stuff in the wiki
20:16:52 <zaneb> launchpad is still peripherally involved btw
20:16:52 <stevebaker> it seems like a good way of collaborating on the specifics of a spec
20:16:53 <radix> it seems that would at least get more scrutiny on the blueprints
20:17:12 <zaneb> but Gerrit is a pretty good tool for collaboration
20:17:23 <therve> *cough*
20:17:41 <zaneb> therve: not *great*
20:17:57 <therve> It make sense to align on the global process, and it seems to have some benefits
20:18:00 <zaneb> but, you know, decent
20:18:05 <shardy> The downside is more reviews though, right?
20:18:06 <stevebaker> better than wiki/etherpad/mailinglist for certain things
20:18:15 * shardy looks at the review queue
20:18:23 <therve> I don't think we were specifically broken on that front, that's all
20:18:34 <stevebaker> shardy, more reviews upfront, which means less reviews when the features land ;)
20:18:39 <therve> shardy, Possibly better future review on features discussed though
20:18:50 <randallburt> therve:  agreed. The bp allows for a spec from the wiki and that's collaboratively edited.
20:18:54 <shardy> I think it definitely makes sense for stuff like API specs and other interfaces
20:19:03 <randallburt> and aren't there comments/discussions on the wiki?
20:19:11 <zaneb> I don't want this to turn into a more formal process like some other projects have
20:19:21 <randallburt> zaneb:  +1
20:19:41 <stevebaker> I don't feel like I'm collaborating when I edit someone elses wiki
20:19:46 <zaneb> but I do think gerrit is a good tool
20:19:48 <erecio> zaneb, +1
20:19:51 <zaneb> I never use the wiki
20:20:45 <jasond> zaneb: +1 i think people are good about asking for feedback on a spec when it's needed and just showing up with code when it's not
20:20:49 <therve> The sad state of our wiki should be handled separately too
20:20:56 <wirehead_> The wiki makes me sad.
20:20:58 <zaneb> jasond: ++
20:21:28 <shardy> sounds like we're mostly +1 on it then
20:21:30 <wirehead_> I am actually a zillion times more fond of wikis than our present blueprint process.  Although I understand that certain aspects — the semantically enabled chain of blueprint relationships, for example — are really awesom
20:21:44 <zaneb> I once saw someone on ask.openstack citing a 2-year-old wiki page as an answer
20:22:08 <therve> We should organize a wiki cleaning day or something
20:22:12 <stevebaker> wirehead_, our present blueprint process is wikis
20:22:22 <stevebaker> wirehead_, and launchpad
20:22:29 <zaneb> wirehead_: launchpad doesn't go away, but basically only I have to deal with it ;)
20:22:35 <randallburt> stevebaker:  there are a lot of bp's without wiki specs, though
20:22:51 <wirehead_> I think the launchpad is the part I like less. :)  It seems to be a home of crushed dreams.
20:23:04 <zaneb> lol
20:23:09 <pas-ha> wirehead_: +1
20:23:23 <therve> Hopefully that'll change soon
20:23:35 <pas-ha> therve: storyboard?
20:23:37 <randallburt> so ML/Wiki and then make zaneb deal with LP if we think its a thing to do?
20:23:40 <stevebaker> zaneb, speaking of which, there are a lot of blueprints which are yet to experience the benign gaze of the PTL
20:23:40 <therve> pas-ha, Yeah
20:24:21 <zaneb> stevebaker: Thierry isn't giving me grief about them until we have resolved this question ;)
20:24:36 <stevebaker> lol, ok
20:24:51 <stevebaker> so who wants to set up the specs repo?
20:25:01 <zaneb> what I'd like to propose is that we move to a specs repo, but keep it extremely lightweight
20:25:13 <stevebaker> zaneb, +1
20:25:20 <wirehead_> Aren't we founded on rough consensus?
20:25:22 <zaneb> ttx is talking about a script to push them into lp
20:25:26 <pas-ha> zaneb: +1
20:25:31 <wirehead_> +1
20:25:33 <radix> that would be handy
20:25:33 <stevebaker> we can crank up the process when we have 400+ developers like nova
20:25:33 <jasond> zaneb: +1
20:25:38 <erecio> zaneb, +1
20:25:39 <zaneb> randallburt: ^ how say you?
20:25:47 <skraynev> zaneb: +1
20:26:04 <randallburt> one sec
20:26:19 <randallburt> oh, ok. +1
20:26:30 <bgorski> z+1
20:26:41 <shardy> +1
20:26:47 <tspatzier> +1
20:26:52 <wirehead_> I think we might have a complete circle of love.  Wow.
20:27:04 <zaneb> #agreed Heat will move to a lightweight blueprint process using a specs repo
20:27:15 <zaneb> ok, and now...
20:27:24 <zaneb> who want to volunteer to set it up? ;)
20:27:53 <therve> ... crickets ...
20:27:57 <stevebaker> tumbleweeds
20:28:03 <zaneb> #info repo name should be orch-specs or orchestration-specs, per decision of the cross-project meeting yesterday
20:28:11 <cyli> what's involved in setting it up?
20:28:36 <therve> cyli, Talking to our lovely infra people I think
20:28:36 <zaneb> cyli: find another project's one, clone it, request that the infra team add it to openstack/
20:28:36 <stevebaker> cyli, probably just a infra config gerrit change
20:29:03 <wirehead_> cyli: I can add a task to our sprint. :)
20:29:09 <zaneb> we also need to decide on what will be validated, I think
20:29:11 <stevebaker> or start with an empty repo and we can all add the initial files
20:29:14 <zaneb> i.e. as little as possible ;)
20:29:26 <cyli> I'll do it, so long as no one minds me asking stupid questions about how to do so here
20:29:48 <zaneb> #action cyli to investigate setting up a specs repo
20:29:51 <stevebaker> cyli, thanks. ask in #heat and #openstack-infra
20:29:54 <zaneb> many thanks cyli
20:30:02 <cyli> :)
20:30:18 <zaneb> #topic Feature proposal freeze
20:30:23 <wirehead_> I just patted cyli on the back.
20:30:35 <zaneb> do we want to do a Feature proposal freeze again?
20:30:38 <zaneb> (IMO we do)
20:30:41 <cyli> stevebaker: will do, thanks
20:30:56 <kebray> hey, I'm late to the party.. .if launchpad stops getting used, how do non technical folks submit feature requests/suggestions?
20:31:10 <radix> kebray: launchpad will still be used with a spec repo
20:31:14 <therve> zaneb, Definitely.
20:31:25 <kebray> radix  ok.. thx.
20:31:35 <zaneb> radix: well, there's a danger that no-one will look at it though
20:31:36 <therve> It went well last time AFAICT
20:31:51 <zaneb> agreed
20:31:54 <randallburt> that danger is very high and very real
20:31:54 <radix> zaneb: well, surely the PTL will continue? ;)
20:31:55 <stevebaker> kebray, launchpad will be used until storyboard is ready. the specs repo is just to collaborate and store the text of the spec
20:31:57 <zaneb> it sets the right expectations
20:32:23 <zaneb> radix: maybe not if a script manages it all ;)
20:32:37 <radix> auto-PTL
20:32:40 <radix> .sh
20:32:57 <iqster> Is it the case that blueprints currently in the New state still have a shot of getting in? Or they need to be in the Approved state?
20:33:16 <zaneb> kebray: blueprints are about implementation, so we'd expect implementers to be able to use Gerrit
20:33:32 <therve> iqster, You mean in for Juno?
20:33:38 <stevebaker> cyli, a single change to http://git.openstack.org/cgit/openstack-infra/config/ should be all that is required
20:34:15 <zaneb> iqster: everything has a shot of getting in if you can write it ;)
20:34:17 <cyli> stevebaker:  thanks
20:34:23 <zaneb> maybe not a good shot...
20:34:25 <iqster> neat :) ty
20:34:53 <zaneb> iqster: but if it's a significant change, you should be looking for early feedback
20:35:32 <stevebaker> zaneb, +1 for continuing the FPF, but it only slightly mitigates the problem of many features landing at once
20:35:39 <zaneb> iqster: i.e. don't do more work than you're prepared to throw away until you think there's consensus
20:36:24 <zaneb> stevebaker: agreed, but I think it does a good job of communicating expectations
20:36:39 <zaneb> is anyone against the FPF?
20:36:43 <stevebaker> yep
20:37:01 <iqster> cool ... we have a patch/blueprint/spec for stack lifecycle plugpoints .. we wanted to get it in today but BillArnold was having some issues with git review
20:37:05 <therve> Your agreement was badly timed I think :)
20:37:13 <radix> heh heh
20:37:23 <shardy> zaneb: I think it's a good idea, we have to draw a line somewhere, although I actually think it makes the late-cycle feature rush worse if anything
20:37:37 <therve> shardy, Worse a bit sooner
20:37:50 <therve> I think it'd be the same without freeze except before the actual release
20:37:52 <shardy> therve: ha, true ;)
20:37:56 <radix> we're discussing a freeze for *proposals* to be accepted, right, not *implementations*?
20:38:06 <tspatzier> iqster: what kind of issues was he having?
20:38:07 <radix> (or proposals to be proposed, perhaps)
20:38:28 <shardy> radix: yes, typically a few weeks before the freeze for implementation to be merged
20:38:29 <stevebaker> we're stuck with something like this until all of openstack moves to a CD
20:38:36 <shardy> so we can review the glut of patches ;)
20:38:37 <stevebaker> based model
20:38:40 <zaneb> radix: proposals means patches proposed to Gerrit
20:38:53 <radix> oh
20:38:54 <zaneb> radix: i.e. implementations, but not necessarily merged yet
20:39:04 <radix> ok, I completely misinterpreted "proposal" to mean something like "blueprint"
20:39:24 <zaneb> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
20:39:32 <zaneb> so that ^ is the release schedule
20:39:38 <stevebaker> the aim of the FPF is to ease the load on the core reviewers at feature freeze time, because some of the reviewing will be done already
20:39:40 <shardy> radix: The blueprints should be proposed much earlier for major stuff, but sometimes minor stuff can be added near FPF if there is code ready
20:39:47 <zaneb> FPF is the week of August 21st
20:39:57 <zaneb> #info FPF is the week of August 21st
20:40:01 <radix> sounds reasonable
20:40:18 <radix> I don't see why FPF would make a rush worse
20:40:19 <erecio> whats FPF?
20:40:25 <radix> erecio: Feature Proposal Freeze
20:40:28 <zaneb> erecio: see #topic
20:40:57 <stevebaker> #link https://wiki.openstack.org/wiki/FeatureProposalFreeze
20:41:13 <zaneb> I think we have a lazy consensus
20:41:21 <zaneb> #agreed Heat will observe the project-wide Feature Proposal Freeze date again in Juno
20:41:48 <wirehead_> Heh.
20:41:53 <zaneb> #topic Autoscaling roadmap
20:42:00 <zaneb> is shadower here?
20:42:01 <zaneb> no
20:42:04 <erecio> thanks.
20:42:08 <shardy> radix: any deadline creates a mad rush when folks realize they've not finished their feature and it's targeted at the next release, which results in attention from release managers and PTLs
20:42:25 <radix> shardy: but wouldn't there be a rush at the actual feature freeze then?
20:42:40 <radix> zaneb: is there a particular question behind this agenda item?
20:42:43 <stevebaker> and god, and ttx
20:42:48 <radix> I have been curious about other use cases  for autoscaling
20:42:54 <zaneb> ok, I'd like to set up a discussion between radix, shadower, shardy and anyone else interested
20:43:01 <radix> who's shadower?
20:43:14 <zaneb> to discuss what our plans are for autoscaling in Juno
20:43:17 <stevebaker> Thomas Sedovic
20:43:26 <radix> ah ok
20:43:34 <zaneb> radix: Tomas Sedovic. ex-Heat and now Tuskaer developer
20:43:38 <zaneb> Tuskar*
20:43:57 <zaneb> moving on...
20:44:04 <radix> *my* plans right now is to just do some refactoring of Heat autoscaling (along with cyli) and also help out with the convergence effort
20:44:13 <radix> which I think plays into practical use of autoscaling
20:44:26 <zaneb> radix: ok
20:44:26 <stevebaker> is a separate API still a thing we're doing?
20:44:44 <zaneb> Tuskar also has some immediate issues with quiescing and victim-selection
20:44:49 <zaneb> on scale-down
20:44:56 <radix> ok, that sounds like some good stuff
20:44:58 <iqster> one shortcoming we have observed in heat autoscaling is that if vms die, the auto-scaling doesn't react to it
20:45:04 <shardy> I discussed with wirehead_ and radix about Tuskar (and other's) requirement for evacuation on scaledown and parameters to choose victims
20:45:15 <radix> iqster: yep, that's what I mean about convergence being necessary for practical autoscaling
20:45:15 <iqster> i presume this is a known defect?
20:45:17 <shardy> I may look at those unless anyone gets to them first
20:45:24 <zaneb> iqster: convergence is the long-term plan to fix that
20:45:26 <radix> iqster: also for practical heat usage in general ;-)
20:45:31 * shardy not planning to get to them anytime soon
20:46:00 <radix> stevebaker: I think... there is less urgency behind that idea
20:46:07 <zaneb> radix: I am also keen to see refactoring continue to happen
20:46:12 <radix> stevebaker: and more behind getting heat to be more usable :)
20:46:15 <zaneb> we can't wait for convergence to come to us
20:46:18 <iqster> at the summit, i didn't get a sense that convergence was defn in Juno
20:46:19 <radix> zaneb: agreed, yeah
20:46:26 <zaneb> we have to start pushing towards it now
20:46:36 <radix> zaneb: cyli and I have a sprint task to work fix up the factoring of AutoScalingResourceGroup
20:46:44 <stevebaker> I'm off to do the school run \o
20:46:45 <zaneb> iqster: convergence will certainly not be complete in Juno
20:47:05 <radix> iqster: but autoscaling isn't going to be able to react to servers randomly dying until convergence happens
20:47:05 <therve> Have some faith!
20:47:15 <iqster> doh!
20:47:29 <zaneb> iqster: maybe in L
20:47:30 <iqster> so ... no reactive autoscaling in Juno it seems :(
20:47:33 <shardy> iqster: It's a huge amount of work, we'll have to take it in several steps and it depends on who shows up to help
20:47:53 <therve> iqster, Please help by reviewing and fixing bugs!
20:47:54 <iqster> That i don't doubt
20:48:07 <zaneb> but things will continue to get better
20:48:18 <zaneb> we're making continuous progress
20:48:30 <iqster> will do ... we'd like to help... speaking for BillArnold and myslef here :)
20:48:42 <radix> zaneb, stevebaker: anyway I don't think there are other big pushers for the autoscaling API other than the rackspace-autoscale team, if there *are* I would love to know about them
20:49:09 <zaneb> radix: I think the API is the icing on the cake
20:49:13 <radix> yep
20:49:17 <stevebaker> radix, ok, lets park it until someone cares enough to do it then
20:49:23 <zaneb> radix: all of the preceding steps are the important ones
20:49:27 <shardy> radix: most folks I've spoken to care primarily about the features, not the API per-se
20:49:31 <zaneb> at that point the API is easy
20:49:33 <radix> right
20:49:53 <zaneb> (also more people would probably be interested if they knew about it)
20:49:56 <radix> I was just confirming that :) it's something we want so we can basically stop maintaining our own service
20:50:46 <zaneb> I'd like to see it happen because autoscaling is useful independently of Heat, just like other OpenStack services
20:51:12 <zaneb> #topic Critical issues sync
20:51:19 <zaneb> lifeless: o/
20:51:31 <zaneb> shardy suggested we add this as a recurring agenda item
20:51:33 * stevebaker *really* goes now. just when its getting interesting
20:51:45 <stevebaker> can it be at the start of the agenda?
20:51:54 <shardy> So I found this yesterday
20:51:56 <zaneb> so that we can all get in sync on critical bugs
20:51:58 <shardy> #link https://bugs.launchpad.net/heat/+bug/1321303
20:52:04 <uvirtbot> Launchpad bug 1321303 in heat "engine broken with multiple workers w/qpid" [High,In progress]
20:52:07 <zaneb> stevebaker: will there be time for anything else if we do that?
20:52:17 <radix> yeah... I gotta run too, sorry ;- )
20:52:18 <shardy> multiple workers are broken with qpid
20:52:48 <zaneb> (this is particularly for the benefit of TripleO)
20:52:51 <randallburt> shardy:  is this just when we fork multiple processes on a box or does it affect multi-engine in general?
20:52:53 <shardy> I *think* I have a fix, but will need review feedback, particularly from jasond as it changes how the EnginListener works
20:53:06 <shardy> randallburt: only forked workers, multi-engine works OK
20:53:09 <stevebaker> zaneb, the meeting nazi can time-limit it
20:53:14 <randallburt> shardy:  k, thanks
20:53:21 <BillArnold> shardy, why heat engine workers and not other workers e.g. nova conductor?
20:53:30 * zaneb looks around for the meeting nazi
20:53:31 <shardy> although see my comment about the watch threads, which I am also looking at fixing
20:54:03 <jasond> shardy: no problem, will keep an eye out for your fix
20:54:06 <shardy> BillArnold: because we wrote it wrong, AFAICT, but I'm still digging into why
20:54:38 <shardy> anyway, any other issues we need to know about, e.g for TripleO or anything else?
20:55:15 <erecio> sdf
20:55:25 <therve> shardy, I wonder how that forking thing will change with oslo.messaging
20:55:57 <therve> We'll see how it goes I guess
20:56:00 <shardy> therve: yeah I was wondering the same thing, not had time to properly look at sdake's patch yet
20:56:12 <zaneb> <lifeless> zaneb: we're still trying to get the bottom of this 2 minute delay between deployments being created
20:56:20 <zaneb> that ^ was posted in #heat
20:56:35 <shardy> therve: my plan it to fix the immediate problem, then potentially look at a bigger refactor
20:56:48 <therve> shardy, The patch has been reverted fwiw
20:57:20 <shardy> therve: I mean the problem that you can't specify multiple workers with qpid
20:57:31 <shardy> zaneb: do we have a bug reference?
20:57:44 <zaneb> not that I know of
20:57:50 <zaneb> but stevebaker might know more
20:58:24 <zaneb> something about large numbers of calls to Nova for get_attr
20:58:46 <zaneb> 2 minutes
20:59:54 <BillArnold> zaneb, is this extra keystone work? using the fake hypervisor driver i'm seeing like a factor of 5 slowdown before the heat engine returns from a create call relative to havana
21:00:12 <BillArnold> and keystone is being hammered
21:00:20 <zaneb> BillArnold: interesting
21:00:32 <shardy> BillArnold: bug with details please :)
21:00:40 <BillArnold> zaneb same problem maybe?
21:00:49 <zaneb> can't be helping
21:00:55 <zaneb> please do raise a bug for that
21:00:59 <BillArnold> k
21:01:09 <zaneb> #endmeeting