12:01:48 <zaneb> #startmeeting heat
12:01:48 <openstack> Meeting started Wed Jul  9 12:01:48 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:51 <openstack> The meeting name has been set to 'heat'
12:02:07 <zaneb> #topic roll call
12:02:11 <mspreitz> o/
12:02:13 <shardy> o/
12:02:13 <bgorski> 0/
12:02:20 <tspatzier> hi
12:02:22 <andrearosa> hi
12:02:25 <BillArnold_> hi
12:02:28 <shardy> (apologies I missed last week btw..)
12:02:29 <skraynev> hey
12:02:32 <unmeshg> hi
12:03:03 <zaneb> hmm, I forgot to put up an agenda
12:03:57 <shardy> zaneb: probably pretty much the same as last week, with the addition of a plugins discussion?
12:04:08 <mspreitz> I'd like to discuss clean shutdown of servers, but maybe that would be tough because Clint won't be here?
12:04:28 <zaneb> shardy: stevedore, you mean?
12:04:36 <zaneb> agenda is up now btw
12:04:54 <pas-ha> hi
12:04:59 <shardy> zaneb: well, all the stuff you mentioned on the ML, the way forward re waitconditions, and if we are going to stevedore all-the-things
12:05:18 <shardy> I guess we can keep it to the ML, but it's a big topic so some higher-bandwidth discussion might help
12:05:25 <zaneb> ok
12:05:35 <shardy> I suppose we really need asalkeld and stevebaker to do that properly though
12:06:16 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-07-09_1200_UTC.29
12:06:18 <skraynev> agree with shardy
12:06:29 <zaneb> #topic Stevedore
12:06:48 <zaneb> I guess asalkeld and stevebaker are the key guys here
12:06:57 <zaneb> I discussed some with asalkeld last night
12:07:33 <zaneb> there's a possibility we can use stevedore Hooks instead of Extensions and get the best of both worlds
12:07:55 <zaneb> I'll write that up for the ML today
12:08:14 <zaneb> did anyone else want to get their oar in on Stevedore specifically?
12:08:57 <shardy> zaneb: Not other than to say it's somewhat surprising to me we're suddently stevedoring everything
12:09:17 <zaneb> I was surprised also
12:09:20 <shardy> I though it was just getting adopted for clients, to avoid reinventing another mechanism
12:09:44 <shardy> personally I'd prefer to see how that goes before doing a wholesale switchover of everything
12:09:46 <zaneb> I'm not sure what the actual benefit is to breaking the way existing users are doing things
12:10:04 <shardy> but as you say, asalkeld and stevebaker have the knowledge here, so I assume they know what they're doing ;)
12:10:31 <shardy> Also, we've all experienced breakage on upgrade recently - what measures do we need to ensure that doesn't happen for packaged deployments?
12:10:49 <shardy> At least we need to document it and be very sure the necessary post scripts get sync'd into all the distros
12:11:32 <zaneb> yeah, it sounds like an area that is ripe for upgrade bugs
12:12:23 <zaneb> #topic WaitCondition resources and signalling
12:12:30 <shardy> EmilienM got the grenade patch working last week, so perhaps we can push on getting that in to ensure things don't get horribly broken
12:12:41 <zaneb> I shoehorned this into the same ML thread
12:13:16 <zaneb> so far everyone is against what I am suggesting when they first hear it :D
12:13:31 <zaneb> but shardy and therve at least appear to have come around
12:13:46 <zaneb> it's clear that I must be explaining it very badly
12:13:51 <shardy> zaneb: I'm not against it, I'm just cautious of forcing everyone to choose one solution
12:14:12 <shardy> Does anyone know what the billing implications are of forcing everyone to bounce signal data via Swift?
12:14:22 <shardy> I'm not familiar with Swift pricing models at all
12:14:46 <zaneb> the way AWS does it is that the data goes into a bucket owned by CloudFormation
12:14:52 <zaneb> *not* one owned by the user
12:15:01 <zaneb> so there's no charge
12:15:11 <shardy> zaneb: I don't think that's the approach taken in jasond's patch atm though?
12:15:18 <zaneb> we can do it that way - which would probably require a quota
12:15:33 <shardy> Also it does a weird thing moving the data back out of swift and into the heat DB, which seems ... wrong.
12:15:52 <zaneb> or we can do it the other way, which would require the provider to make it known that certain types of resources have a cost associated
12:16:11 <shardy> zaneb: FWIW, I've got no issues focussing on one (swift based if that's what everyone wants) solution
12:16:25 <shardy> but atm, I see value in both solutions for different use-cases
12:16:44 <zaneb> IMO Swift is the "right" way to do it
12:16:50 <shardy> the user-owned swift data approach seems pretty heavyweight for simple "I'm done" signalling requirements
12:16:53 <zaneb> but not every cloud might have Swift
12:17:10 <shardy> zaneb: Yeah that was my next point, can we assume every cloud will always have swift
12:17:16 <zaneb> which is why I think the backend should be pluggable
12:17:22 <shardy> certainly I don't always install it for development usage
12:17:50 <zaneb> DefCore may change that, but atm it looks like probably not
12:18:33 <Qiming> what's swift? :P
12:19:07 <skraynev> Qiming: one of openstack components for storing user-date
12:19:16 <zaneb> Qiming: a dynamic programming language invented by Apple
12:19:23 <tspatzier> Qiming: that new programming language from apple ;)
12:19:36 <zaneb> tspatzier: too slow ;)
12:19:43 <Qiming> cool, many definitions
12:19:57 <tspatzier> zaneb: yeah,  I have to improve :)
12:20:05 <skraynev> zaneb: OMG. I have not known about it!
12:20:24 <shardy> zaneb: Ok, well I'm happy to proceed with your solution, but I'm still somewhat wary of making this a one-time option
12:20:38 <skraynev> zaneb: thx, you opened my eyes  :)
12:20:47 <shardy> I'll rebase my patches on a mildly modified SignalResponder, and we can work out how to make that pluggable
12:21:26 <zaneb> shardy: ok, it may pay to discuss with jasond and randallburt also
12:21:48 <zaneb> I wouldn't go so far as to say that there seems to be a consensus on this yet
12:22:00 <shardy> zaneb: Yes of course, I left some comments on jasond's review yesterday, but I'll try to catch one or both of them later for an IRC chat
12:22:11 <zaneb> cool, sounds good
12:22:35 <zaneb> #action shardy, jasond and randallburt to discuss pluggability of WaitCondition implementations
12:22:48 <andrearosa> can you post the change URL, please?
12:23:10 <shardy> #link https://review.openstack.org/#/c/96947/
12:23:19 <zaneb> andrearosa: https://review.openstack.org/96947 https://review.openstack.org/101354
12:23:25 <andrearosa> thanks
12:23:41 <shardy> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1337772,n,z
12:23:49 <shardy> That's the series I've been working on
12:23:57 <andrearosa> perfect!
12:24:06 <zaneb> #topic Quiescing servers
12:24:13 <zaneb> mspreitz: this is you
12:24:20 <mspreitz> OK...
12:24:28 <mspreitz> I think Clint cares a lot about this too
12:24:37 <mspreitz> But I'm guessing it's 5 AM for him so he won't be here.
12:25:04 <mspreitz> Anyway, I think Thomas' action-aware software config stuff can handle it, by virtue of allowing the template author to write stuff to handle DELETE
12:25:22 <mspreitz> I was wondering if this makes sense to Thomas and others.
12:25:33 <shardy> mspreitz: I was discussing this with stevebaker recently, and he said this should already be possible, even without the action-aware stuff
12:25:34 <tspatzier> mspreitz: yeah, that's my thought as well. stevebaker also mad such comments
12:25:50 <shardy> Just by definining a config which is only run when the action is DELETE in the SoftwareDeployment
12:25:58 <mspreitz> Ah, right
12:26:02 <shardy> tspatzier: is that correct?
12:26:14 <tspatzier> shardy: yes, I think so.
12:26:34 <shardy> tspatzier: And your proposal basically refines the interfaces, right?
12:26:55 <tspatzier> shardy: the action-aware-swconfig stuff will make use cases where you have configs for multiple actions a bit more user friendly
12:27:08 <mspreitz> But I do agree with Thomas' suggestion for allowing one SoftwareConfig/Component to handle multiple actions.
12:27:25 <mspreitz> Yes, I do think that would be an improvement.
12:27:47 <shardy> tspatzier: Ok, thanks for the clarification :)
12:28:24 <mspreitz> I guess I'm done, just wishing to see action aware software config get approved
12:28:29 <tspatzier> shardy, mspreitz: btw, I've been busy in meeting the last two days so could not react on comments on the spec. will review and respond soon
12:28:47 <mspreitz> thanks
12:29:14 <zaneb> #topic Critical issues sync
12:29:22 <zaneb> anybody got critical issues?
12:29:34 <zaneb> try to keep it heat-related ;P
12:30:40 <shardy> Reviews for https://review.openstack.org/#/c/105470/ would be good
12:31:01 <shardy> stops very bad things happening if your stack contains both SoftwareDeployments and WaitConditions, for some reason :)
12:31:30 <zaneb> ouch
12:31:45 <tspatzier> shardy: is this related to the problems the TripleO team saw?
12:31:57 <shardy> zaneb: That was the cause of the TripleO regression on Friday, triggered by my patches
12:32:07 <shardy> tspatzier: yes :)
12:32:18 * zaneb didn't hear about that
12:32:28 <tspatzier> spooky
12:32:44 <zaneb> 4th of July ftw
12:33:55 <zaneb> #topic Open Discussion
12:34:13 <zaneb> y'all will be pleased to hear I already created the agenda for next week's meeting ;)
12:34:40 <zaneb> also, mid-cycle meetup
12:34:59 <mspreitz> IIRC, last week it was mentioned that getting new Tempest tests approved is a months-long wait... that sounds like a problem to me
12:35:22 <zaneb> #info For the mid-cycle meetup, folks will mostly be arriving Sunday night, leaving Wednesday night
12:35:42 <shardy> mspreitz: it is a problem, not specific to Heat unfortunately
12:35:57 <mspreitz> shardy: right about scope.  Is there any movement on it?
12:36:07 <zaneb> #info Red Hatters are mostly staying at the Marriott. The Sheraton is another nearby option.
12:36:14 <skraynev> I have one question/idea. Currently we have a lot of pluggable things and one command is related with it (heat resource-type-list)
12:36:21 <shardy> mspreitz: none :(
12:36:28 <mspreitz> Someone suggested expanding the set of people who can approve new Tempest tests?
12:36:42 <skraynev> how about adding same things for other things (templates, clients)
12:36:45 <shardy> I'll probably propose a session to discuss the problem in Paris
12:36:53 <mspreitz> shardy: thanks
12:37:20 <zaneb> skraynev: clients are not the end user's problem
12:37:22 <mspreitz> Can we have a command to list all plugins?
12:37:24 <shardy> mspreitz: well yeah, the answer is either more tempest cores, or moving the project test-cases into the project trees
12:37:43 <shardy> Relatedly, has anyone had issues with VolumeAttachments on very-recent OpenStack?
12:37:49 <skraynev> zaneb: ok,how about template versions?
12:38:00 <zaneb> skraynev: there's an argument for template formats... but it wouldn't be that useful without docs anyway. So I think the real answer there is docs
12:38:22 <zaneb> open to being persuaded otherwise though ;)
12:38:27 <pas-ha> shardy, what issues?
12:38:51 <shardy> pas-ha: In the gate, my test appears to not always find the device attached in the instance
12:39:27 <shardy> I can't reproduce it locally, but it worked perfectly for the last three months it's been up for review, just recently started failing
12:39:43 <shardy> could be a test issue, just wanted to check nobody was aware of critical cinder/nova issues
12:39:52 <shardy> I couldn't see any relevant rechecks
12:40:09 <shardy> anyway, that's a bit OT for this meeting, sorry ;)
12:40:37 <pas-ha> shardy, could you drop a link on your tempest patch?
12:41:01 <shardy> https://review.openstack.org/#/c/90143/
12:41:10 <skraynev> zaneb: :) I just have couple of reasons: It will be easy to see (if you're lazy to read docs) and if we sometime want to deprecate some versions it will be visible for user.
12:41:19 <shardy> I need to find (yet another) few hours to debug it
12:42:12 <skraynev> zaneb: and there is one "crazy idea", when you want to create you own template format.
12:42:29 <pas-ha> skraynev, zaneb also docs make sense if they are versioned by heat version which currently they seem not
12:43:08 <zaneb> skraynev: if you create your own you are definitely going to need to document it
12:43:18 <pas-ha> so having current list of supported stuff per deplyment seems reasonable
12:44:05 <zaneb> I definitely wouldn't be opposed if you guys submitted patches for that
12:44:22 <skraynev> zaneb: yeah, but it also provide you the easiest way to verify, that you template type is plug-on
12:45:21 <zaneb> skraynev: good point, although that's more of an admin problem than a user problem
12:46:09 <zaneb> skraynev: I'd say submit a spec for it. I don't see any obstacle to it getting approved
12:46:41 <skraynev> zaneb: yeah)) I just wrote previous message before read yours :)
12:46:53 <skraynev> zaneb: thx.
12:47:04 <zaneb> np
12:47:13 <zaneb> ok, let's wrap it up and jump back to #heat
12:47:22 <zaneb> thanks everyone!
12:47:32 <zaneb> #endmeeting