20:00:07 <asalkeld> #startmeeting heat
20:00:08 <openstack> Meeting started Wed Nov 19 20:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:12 <openstack> The meeting name has been set to 'heat'
20:00:20 <asalkeld> #topic rollcall
20:00:31 <shardy> o/
20:00:36 <jasond`> o/
20:00:38 <ryansb> \o
20:00:45 <stevebaker> \o
20:00:46 <inc0> o//
20:00:50 <tspatzier> hi
20:01:04 <cutforth> hello
20:01:19 <zaneb> o/
20:01:21 <skraynev_> hello all
20:01:36 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:02:20 <asalkeld> #topic review last actions
20:02:43 <stevebaker> that would be pre-summit actions
20:02:52 <asalkeld> egh, it's been such a long time - not sure this is relervant
20:03:05 <asalkeld> lets moveon
20:03:23 <asalkeld> #topic add items to the agenda
20:03:41 <asalkeld> anything new?
20:04:08 <inc0> convergence syncup is scheduled after meeting right?
20:04:14 <asalkeld> yip
20:04:15 <stevebaker> asalkeld: RPC exceptions
20:04:25 <asalkeld> ok
20:04:49 <asalkeld> #topic Critical issues sync
20:04:56 <shardy> stevebaker: Ah, also the plan re RPC versioning and versioned objects would be good to clarify
20:05:03 <stevebaker> +1
20:05:11 <asalkeld> sure shardy
20:05:17 <skraynev_> inc0: syncup will be on this channel?
20:05:30 <inc0> skraynev_, I think #heat
20:05:39 <asalkeld> skraynev_ #heat
20:05:48 <asalkeld> no critical bugs?
20:06:03 <skraynev_> got it, thx
20:06:22 <pas-ha> o/
20:06:27 <asalkeld> ok moving on
20:06:45 <asalkeld> #topic  Organize a bug cleanup day
20:06:59 <asalkeld> therve raised this at summit
20:07:21 <stevebaker> seems like a good idea
20:07:23 <asalkeld> this is more cleaning up old bugs that are not relervent
20:07:26 <inc0> let me jump in a bit please, in glance there was bug cleanup day
20:07:30 <ryansb> does cleanup == triage ?
20:07:36 <shardy> There's a huge number of old blueprints too
20:07:36 <asalkeld> yeah
20:07:48 <inc0> its about tagging, triaging, confirming, setting priority
20:07:55 <stevebaker> could we use this chance to abandon ancient changes too? with a nice message
20:08:10 <asalkeld> sure
20:08:41 <asalkeld> maybe make an entherpad and propose blueprints to die?
20:08:49 <shardy> stevebaker: +1000
20:09:11 <inc0> asalkeld, what about discussing it ad hoc here at irc?
20:09:24 <asalkeld> sure
20:09:37 <stevebaker> How about the 26th to do this? next week
20:09:38 <inc0> if we'll all be focused on this, it should be pretty efficient
20:09:39 <asalkeld> so is one day enough
20:09:54 <zaneb> stevebaker, shardy: what would we want to abandon that isn't auto-abandoned already?
20:10:09 <shardy> zaneb: there is no auto-abandon anymore AFAIK
20:10:10 <inc0> one workday in every tz
20:10:10 <stevebaker> zaneb: auto abandon hasn't been a thing for many months
20:10:18 <zaneb> orly?
20:10:21 <ryansb> Thanksgiving is on the 27th, so many US folks will be travelling, FWIW
20:10:29 <asalkeld> zaneb, we need to do auto abandon's job now
20:10:30 <shardy> so there's stuff sitting there for months with negative feedback and no updates from the owner
20:10:38 <inc0> 3rd dec?
20:10:49 <asalkeld> i'll be traveling
20:10:56 <asalkeld> (3-6
20:11:09 <shardy> zaneb: It's been discussed (again) on the ML recently, some folks like crufty old patches, apparently
20:11:20 <stevebaker> 2nd dec?
20:11:29 <zaneb> weirdos
20:11:35 <asalkeld> i am more in favor of doing this over a week - not sure it can be done in  a day
20:11:45 <inc0> or 1st, monday - everyone hates mondays so will try to get over with this asap;)
20:11:53 <asalkeld> lol
20:11:59 <stevebaker> inc0: that is my Sunday
20:12:10 <mdulko> Why not 24th or 25th?
20:12:10 <asalkeld> ok let's make it the 2nd
20:12:15 <stevebaker> inc0: oh, I mean Tuesday. as you were
20:12:16 <asalkeld> and see how it goes
20:12:39 <stevebaker> asalkeld: want to send out an announcement?
20:13:05 <asalkeld> #action asalkeld to send out an announcement about the bug cleanup day
20:13:19 <asalkeld> #topic https://wiki.openstack.org/wiki/CrossProjectLiaisons
20:13:33 <asalkeld> please have a look ^
20:14:05 <asalkeld> is randall about?
20:14:15 <skraynev_> I still think about API :)
20:14:32 <asalkeld> we need a stable branch liaison
20:14:36 <zaneb> asalkeld: I can take stable branch if you like
20:14:55 <asalkeld> cool, just put your name there
20:14:57 <asalkeld> Vulnerability management
20:15:12 <asalkeld> any takers?
20:15:23 <shardy> asalkeld: Why do we need a liason for that when there's already a dedicated sub-team?
20:15:45 <skraynev_> shardy: I supppose it's just contanc person
20:15:45 <asalkeld> shardy, cos' it's on the page and someone is asking?
20:15:59 <pas-ha> shardy, laison maintains the members of the $PROJECT-coresec team i
20:16:03 <stevebaker> someone involved in running a public heat endpoint would be ideal for vuln management
20:16:26 <asalkeld> agree, anyone from rax here?
20:16:32 <jasond`> asalkeld: me
20:16:32 <shardy> asalkeld: Sure, I'm just saying it doesn't make much sense, beyond the fashion for liason-al-the-things ;)
20:16:42 <asalkeld> jasond`, you keen?
20:17:03 <asalkeld> shardy, you want to take an action to fight it?
20:17:07 <jasond`> asalkeld: let me talk to randall about that and get back to you
20:17:12 <shardy> asalkeld: Not really
20:17:17 <stevebaker> presumably the PTL is the default liaison for all the things
20:17:18 <zaneb> who are the current members of the VM team?
20:17:18 <asalkeld> :)
20:17:23 <jasond`> asalkeld: he stepped away for a minute
20:17:29 <zaneb> iirc it's me, shardy and jasond`?
20:17:35 <asalkeld> jasond`, no problem
20:17:43 <stevebaker> zaneb: I thought I was on it too, can't recall
20:17:49 <shardy> zaneb: I believe I'm on it
20:18:05 <zaneb> oh yeah, I think stevebaker also
20:18:17 <stevebaker> we don't have enough vulnerabilities to have a process
20:18:21 <jasond`> that's right, i am already on it :)
20:18:25 <shardy> stevebaker: \o/ ;)
20:18:33 <asalkeld> cool
20:18:40 <zaneb> so I think it's just a case of one of us being the first contact point
20:19:12 <asalkeld> jasond`, said he would talk to randall about it
20:19:15 <asalkeld> API working group
20:19:28 <asalkeld> that might be a bit more work
20:19:46 <asalkeld> lots of meetings
20:20:14 <asalkeld> skraynev_?
20:20:36 <asalkeld> ryansb, ?
20:20:37 <stevebaker> yr not selling it
20:20:45 <zaneb> lol
20:20:52 <stevebaker> Status! Influence! Parties!
20:20:52 <ryansb> you have to say "lots of meetings WITH BEER"
20:20:58 <skraynev_> stevebaker: thumbs up!
20:21:01 <asalkeld> ryansb, doh
20:21:04 <ryansb> but I'd be interested, thought I'm not core
20:21:11 <ryansb> *though
20:21:15 <asalkeld> i don't think that is a problem
20:21:16 <stevebaker> I assume that is not a requirement
20:21:38 <asalkeld> ryansb, you are it
20:21:38 <zaneb> yeah, I don't see that as a big obstacle
20:21:43 <mdulko> The liaison should be a core reviewer for the project, but does not need to be the PTL
20:21:46 <mdulko> They say
20:21:46 <ryansb> I just wasn't sure how strong the "should" was in their description
20:22:07 <asalkeld> ryansb, is working hard at core - right?
20:22:13 <asalkeld> ;)
20:22:22 <ryansb> :)
20:22:42 <ryansb> I'll put my name in, and see if they kick me out.
20:22:51 <asalkeld> cool
20:22:52 <zaneb> ryansb has a direct line to like half the core reviewers, so he shouldn't have any trouble getting stuff landed ;)
20:23:33 <asalkeld> ok, if anyone want to do release management, that is now also up for grabs
20:23:47 <zaneb> asalkeld: nobody wants to release management
20:23:57 <asalkeld> but i assumed that ^
20:24:01 <asalkeld> :)
20:24:06 <shardy> That's the really "fun" part of being a PTL ;)
20:24:18 <asalkeld> ok, lets move on
20:24:26 <asalkeld> #topic project meetings
20:24:55 <asalkeld> so regarding the cpl's - you are encouraged to now attend the project meeting too
20:25:08 <asalkeld> cpl's == cross project liaisons
20:25:19 <asalkeld> https://wiki.openstack.org/wiki/Meetings/ProjectMeeting
20:25:20 <stevebaker> asalkeld: ah, I didn't know that
20:25:25 <asalkeld> that's new
20:25:37 <asalkeld> optional, but encouraged
20:25:37 <stevebaker> I often lurk anyway
20:25:59 <asalkeld> moving on
20:26:05 <asalkeld> #topic Mid cycle meetup planning
20:26:50 <asalkeld> so the poll is very even
20:26:57 <stevebaker> #link https://doodle.com/b9m4bf8hvm3mna97#table
20:27:13 <inc0> maybe hangouts then?
20:27:14 <asalkeld> which is just saying no one really wants to travel
20:27:22 <asalkeld> inc0, yip
20:27:35 <asalkeld> i propose we don't travel to a midcycle
20:27:36 <inc0> we might have hard time with tz difference then
20:28:05 <inc0> but we can schedule topic sessions in hours convenient with interested people
20:28:05 <asalkeld> inc0 i think the trick is to have topical discussions
20:28:08 <zaneb> I propose we don't use hangouts, because I don't have Google+
20:28:19 <asalkeld> so we don't need everyone
20:28:31 <zaneb> russellb has some sort of WebRTC thing we could use I believe
20:28:33 <skraynev_> zaneb: :)
20:28:40 <asalkeld> zaneb, i am not stressed what we use
20:28:47 <inc0> we can set up mumble server;)
20:28:51 <asalkeld> not really the point, as long as it works
20:29:15 <asalkeld> are people ok with trying this?
20:29:22 <inc0> or whatever works, we all work in huge corpos...I think we can manage to get one teleco bridge or external server;)
20:29:47 <stevebaker> we should give it a decent attempt
20:29:54 <asalkeld> yip
20:29:57 <pas-ha> +1
20:30:03 <tspatzier> +1
20:30:06 <mdulko> +1
20:30:06 <ryansb> Yeah, major plus of remote-midcycle is we can record
20:30:12 <jasond`> +1
20:30:14 <skraynev_> +2
20:30:23 <stevebaker> why not bluejeans?
20:30:25 <shardy> +1
20:30:27 <zaneb> +1, travel was looking more or less impossible to get approved
20:30:30 <asalkeld> #action asalkeld to announce the "remote" midcycle
20:30:32 <stevebaker> +1
20:30:34 <ryansb> +1
20:30:35 <shardy> stevebaker: Yeah I was thinking that might work
20:30:50 <asalkeld> next we can bike shed on the software to use
20:31:00 <stevebaker> and the timezone to sync to
20:31:15 <inc0> we could start getting ideas for sessions too
20:31:18 <stevebaker> going nocturnal would be amusing
20:31:33 <asalkeld> inc0, yeah
20:31:37 <ryansb> we should write oslo.webrtc ;)
20:31:49 <asalkeld> i think if everyone attends it won't work
20:31:55 <inc0> meetup as a service?
20:32:06 <skraynev_> ryansb: as additional plugin for Heat :)
20:32:15 <asalkeld> we need to have topics that apeal to a focused group
20:32:26 <inc0> etherpad?
20:32:41 <asalkeld> inc0, sure
20:32:59 <stevebaker> so this won't be until Feb?
20:33:10 <asalkeld> stevebaker, i guess
20:33:37 <asalkeld> but it's cheap, so we could do it when ever
20:33:52 <asalkeld> i think we just need a process for setting up a discussion
20:34:07 <inc0> we could do it more than once if it would be required
20:34:15 <asalkeld> suer
20:34:36 <asalkeld> ok, lets move on we had some other topics
20:35:01 <asalkeld> #topic rpc versioning
20:35:06 <asalkeld> shardy, ^
20:35:22 <asalkeld> i hope the topic is what you wanted
20:35:28 <shardy> So my question is, what needs to happen so we actually solve the versioning on upgrade problem?
20:35:56 <shardy> stevebaker mentioned bumping versions on a review recently, then it later occurred to me that it doesn't actually solve anything, or does it?
20:36:28 <stevebaker> RPC_API_VERSION looks like it meets a need. Rev it on API changes, then make calls with the requested version. You will end up with an engine that responds with that version
20:36:34 <asalkeld> why don't you think it solves a problem
20:37:16 <asalkeld> one problem is: speaking to an older engine
20:37:18 <shardy> stevebaker: Does something have the retry logic on the client side to keep trying different engines if it hits one with the wrong version?
20:37:18 <pas-ha> stevebaker, what if noone answers? timeout?
20:37:19 <zaneb> I'm guessing it depends a lot on the nature of the change you're making
20:38:28 <inc0> I think horizon has that in config file
20:38:29 <stevebaker> shardy: surely a newer engine will respond first time. Upgrade instructions will need to be 0. upgrade database 1. upgrade some engines, 2. upgrade everything else in any order
20:38:34 <inc0> can't we just mimic this approach?
20:38:58 <zaneb> stevebaker: that's backwards
20:39:04 <inc0> (if I understand problem correctly, which I may not.)
20:39:12 <asalkeld> stevebaker, we agreed at summit we need to support tripelo upgrades
20:39:14 <zaneb> engine(s) have to be upgraded before DB
20:39:32 <stevebaker> inc0: afaik horizon doesn't do rpc calls
20:39:39 <shardy> stevebaker: So in the transition, you have a mixture of engine verions, what happens when an upgraded API hits a too-old engine?
20:39:51 <asalkeld> upgrade all software, then db
20:39:56 <shardy> Is there code in oslo.messaging which round-robins until it gets a match?
20:39:58 <stevebaker> shardy: it doesn't, because the calls request the version they need
20:40:08 <zaneb> and also TripleO is doing this awkward thing where they deploy an API and an engine together, so that they both get upgraded at the same time :/
20:40:16 <asalkeld> shardy, that's on versioned objects
20:40:19 <shardy> stevebaker: But each engine supports exactly one version, doesn't it?
20:40:24 <inc0> how about getting topic excheange on amqp
20:40:27 <asalkeld> s/on/in
20:40:32 <inc0> and have 2 queues for each version
20:40:35 <inc0> for transition?
20:40:56 <inc0> and when calling rpc, we'll specify which queue it should land on?
20:40:56 <stevebaker> shardy: client requesting 1.0 can be serviced by a 1.1 engine
20:41:22 <stevebaker> shardy: the vast majority of our API changes are backwards compatible minor revs
20:41:23 <pas-ha> stevebaker, so 1.x must be backward-compat?
20:41:25 <asalkeld> inc0, that sounds messy for the operator
20:41:41 <stevebaker> zaneb: upgrading in pairs should be fine
20:41:45 <inc0> asalkeld, it might, but we can make that semi-automatic
20:42:16 <shardy> stevebaker: Ok, so if all engine upgrades are backwards compatible, what does the version buy us over documenting the engine must be upgraded first?
20:42:18 <zaneb> stevebaker: well, it's a PITA because it means you have to maintain both backwards and upwards compat
20:43:09 <inc0> zaneb, +1 if we made one mistake, we'd need to live with it forever and ever
20:43:22 <stevebaker> shardy: because engine->engine calls need a new engine. engine 1 does a call requesting 1.2, a 1.2 engine responds.
20:43:30 <asalkeld> shardy, can we go look and see what other projects do?
20:43:43 <asalkeld> seems like this should be a solved problem
20:44:03 <stevebaker> I think we are discussing the solved problem
20:44:24 <shardy> asalkeld: Sure, and if it's solved then great
20:44:51 <mdulko> Is it? Nova guys were discussing it also at the summit.
20:45:04 <stevebaker> we just need to get better at reving RPC_API_VERSION and calling the version required, so keep an eye out for RPC API changes in reviews
20:45:04 <shardy> I was confused because it's not clear how this should work looking at the code, and the discussion of versioned objects sounded like that was required to solve this properly
20:45:09 <zaneb> it's really hard to discuss this in general terms, outside the context of a specific change
20:45:18 <zaneb> because every change is potentially different
20:45:22 <asalkeld> mdulko, yeah - their's is based on the versioned objects
20:45:22 <inc0> mdulko, did they threw any ideas?
20:45:39 <asalkeld> zaneb, +1
20:45:42 <mdulko> inc0, asalkeld already replied
20:45:54 <shardy> zaneb: Well what's triggered my interest is the recently merged decouple-nested RPC additions
20:46:01 <stevebaker> mdulko: they are passing complex objects over RPC, so they need versioned objects. Currently we have only method arguments with simple types
20:46:15 <shardy> zaneb: stevebaker asked for a version bump, but unfortunately the patches got merged anyway
20:46:40 <stevebaker> shardy: can you submit a rev change as a follow up?
20:46:41 <shardy> I'm trying to figure out how big a problem that is, and how we handle RPC changes at reiew time in future
20:46:53 <shardy> stevebaker: Sure, if that fixes a problem
20:47:01 <zaneb> shardy: so that is adding extra parameters, without which it presumably breaks something, so it needs a version bump
20:47:02 <stevebaker> shardy: we can point others at this change "-1, do this"
20:47:15 <asalkeld> shardy, we probably need a javlin test
20:47:19 <pas-ha> may be we should bump the rpc version not with every little change? but "cumulatively", say on milestones?
20:47:41 <asalkeld> pas-ha, but people are doing cd
20:47:41 <zaneb> shardy: or perhaps it just returns an error? in which case maybe it's OK (though not ideal, obvs)
20:47:43 <stevebaker> pas-ha: there is lots of heat CD
20:47:51 <shardy> asalkeld: Yes, if anyone wants to take on getting grenade/javelin working that would be awesome
20:48:08 <shardy> asalkeld: I started but gave up on it as it's hard to get working locally
20:48:18 <shardy> https://review.openstack.org/#/c/86978/
20:48:19 <asalkeld> ok, that sucks
20:49:14 <stevebaker> should we move on?
20:49:22 <shardy> +1
20:49:42 <asalkeld> stevebaker, what was your topic?
20:49:49 <stevebaker> RPC exceptions
20:49:54 <asalkeld> #topic rpc exceptions
20:50:38 <stevebaker> so exceptions on api->engine calls are handled by the fault middleware, but we need some thought on what to do about engine->engine exceptions
20:51:27 <skraynev_> stevebaker: could you give example when it may happen?
20:51:29 <zaneb> catch them?
20:51:39 <asalkeld> ok, so serialising them
20:51:47 <stevebaker> if a NotFound exception is raised the result on the client side has the type heat.common.exception_Remote.NotFound_Remote, which can't be specified in a static except
20:52:55 <zaneb> stevebaker: so your point is that the RPC API doesn't behave enough like the ReST API for the purposes of the client plugins?
20:52:56 <asalkeld> so we need something in the rpc client to map it like middleware does
20:53:19 <stevebaker> which means we either need to change all our error paths to check for these made up remote types, or do some wrapping in the RPC client to raise the real exceptions again. I'd like to discuss which is best
20:53:44 <asalkeld> couldn't we move the fault middleware into the rpc client?
20:53:54 <zaneb> how many error paths are we talking about?
20:53:58 <asalkeld> to have this stuff in one place
20:54:10 <stevebaker> asalkeld: that is just formatting the error for the user, we need something quite different in the engine
20:54:24 <zaneb> what are we doing engine-engine RPC for other than shardy's nested stack changes?
20:54:39 <asalkeld> zaneb, not much now
20:54:47 <asalkeld> soon more
20:54:54 <stevebaker> zaneb: my software-deployment changes. Not much now but eventually all the things
20:55:07 <shardy> zaneb: stevebaker's moved softwareconfig to that model, and in future, won't convergence work in a similar way?
20:55:08 <pas-ha> zaneb, stop, signal
20:55:23 <zaneb> shardy: convergence will never get a reply at all
20:55:33 <stevebaker> zaneb: anything which catches a HeatException or subclass thereof
20:55:34 <zaneb> it's completely async
20:55:59 <zaneb> stevebaker: isn't that localised to a client plugin though? couldn't you do the translation there?
20:56:51 <asalkeld> 4mins
20:57:53 <stevebaker> zaneb: you mean heat.rpc.client.EngineClient? yes. I think it would need every method call to check for every known thrown exception to re-raise it though
20:58:21 <stevebaker> anyway, I've raised the issue, we don't need to solve it now
20:58:39 <asalkeld> #topic open discussion
20:58:45 <asalkeld> (for 2mins)
20:58:59 <asalkeld> not very open ended:-O
20:59:15 <zaneb> stevebaker: no, I mean a client plugin that talks to the RPC client instead of python-heatclient
20:59:31 <ryansb> open, but with a low ttl
21:00:04 <stevebaker> zaneb: there is no such thing. resources are making rpc calls directly
21:00:28 <asalkeld> #endmeeting