20:00:10 #startmeeting heat 20:00:11 Meeting started Wed May 1 20:00:10 2013 UTC. The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:15 The meeting name has been set to 'heat' 20:00:24 o/ 20:00:26 #topic rollcall 20:00:30 hithere 20:00:34 o/ again :) 20:00:39 :) 20:00:48 here 20:00:55 Good afternoon/ evening / morning / night / teatime 20:00:57 howdy 20:01:07 hi 20:01:19 hi 20:01:41 stevebaker, asalkeld? 20:01:50 hi 20:01:57 hello 20:02:09 Ok, cool hi all 20:02:17 #topic Review last week's actions 20:02:41 IIRC stevebaker is on holiday all week 20:02:41 #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-04-24-20.00.html 20:02:52 SpamapS: thanks, forgot that 20:03:00 So there are two actions: 20:03:14 everyone to review havana BPs 20:03:35 Well come to BP discussion in a minute, so perhaps we'll skip that :) 20:03:44 s/Well/We'll 20:03:52 someone to create workflow-library wiki page 20:03:57 Did anyone do that? 20:04:02 https://wiki.openstack.org/wiki/Convection does this count? 20:04:04 no :( 20:04:10 i have some pieces of it 20:04:11 whew 20:04:13 I thought someone was supposed to do it ;) 20:04:14 https://wiki.openstack.org/wiki/StructuredStateManagementDetails 20:04:18 If it's for the library… there is an ether pad started by Josh. 20:04:21 Ah, yes! 20:04:26 Perfect harlowja 20:04:36 #link https://wiki.openstack.org/wiki/Convection 20:04:40 it is slightly nova 'centric' but the general principles apply 20:04:45 #link https://wiki.openstack.org/wiki/StructuredStateManagementDetails 20:04:57 #link https://wiki.openstack.org/wiki/StructuredStateManagement 20:05:06 Ok, looks like we can all start looking at those, thanks harlowja and kebray 20:05:29 also that one, i have started putting some of the base into nova, https://review.openstack.org/#/c/27869/ also 20:05:34 at least pieces of it to get moving 20:05:51 if we can fast-line the move to oslo then this could be put in there 20:06:07 then we can try to make some base objects that work for as many projects as possible 20:06:37 harlowja: sounds good, perhaps we can all start looking at this over the next week 20:06:52 that'd be much appreciated 20:06:54 #action all to take a look at harlowja's wiki page and patch 20:07:14 shardy there are also other workflow libraries that are interested to look at (at least the code/design) 20:07:24 https://wiki.openstack.org/wiki/NovaOrchestration/WorkflowEngines 20:07:44 from previous work, none of them handle the distributed case, but good to get ideas from 20:08:01 harlowja: Ok, there's the wider investigation, and also to see if/how we can consume this stuff in Heat 20:08:14 Let's continue this on the ML or in #heat if that's Okay 20:08:14 shardy agreed, many efforts happening at once :) 20:08:19 kk 20:08:24 tbh I see the distributed thing as the main issue 20:08:37 #topic Blueprint review for Havana, task assignment 20:08:43 zaneb agreed :) 20:08:44 what we have already implemented in heat does the workflow part fine 20:08:58 (for our purposes) 20:09:15 zaneb sure, but the distributed+workflow parts are something all projects can benefit from i think 20:09:38 yes, we need the locking 20:09:45 *and liveness 20:09:52 (for scaling) 20:10:18 my point was that a library that doesn't handle the locking doesn't buy us anything we couldn't write ourselves 20:10:36 anyway, back to the topic :) 20:10:51 well there a fundamental things that change depending on how the locking & livness is done, thats where it gets tricky 20:10:54 #link https://blueprints.launchpad.net/heat/havana 20:10:58 let's move on ;) 20:11:01 :) 20:11:13 So I've been trying to beat the BP plan into shape 20:11:38 We have some new BPs related to the Providers proposal zaneb made 20:11:50 #link https://blueprints.launchpad.net/heat/+spec/provider-resource 20:12:01 #link https://blueprints.launchpad.net/heat/+spec/json-parameters 20:12:09 #link https://blueprints.launchpad.net/heat/+spec/stack-metadata 20:12:25 #link https://blueprints.launchpad.net/heat/+spec/attributes-schema 20:12:35 #link https://blueprints.launchpad.net/heat/+spec/resource-template 20:12:53 zaneb: are youy planning to do this work, or are we looking for volunteers? 20:13:01 volunteers ;) 20:13:09 those look well glued together 20:13:15 I can help though 20:13:25 I think we have some folks that can do those 20:13:36 later this week or early next 20:13:37 I don't have a firm plan for what I want to work on in Havana yet 20:13:44 Ok, so I've made the heat-api-dsl BP depend on these 20:14:07 randallburt: if you can assign some names to these, that would be great, and work with zaneb to define the details of what has to be done 20:14:17 shardy: not sure if its a hard dep, since we're still designing but I can see the point 20:14:24 shardy: will do 20:14:36 I'll start filling in the dependencies between those tasks 20:14:44 randallburt: it was more of a "lets do these first" kind of thing, but feel free to remove if you disagree ;) 20:15:03 shardy: kk. can we get an action for me so I won't forget? 20:15:13 to assign folks, that is 20:15:22 less dependencies = more winning IMO :) 20:15:34 #action randallburt assign names to new BPs linked above 20:15:39 thanks 20:16:07 SpamapS: point is I think we need to get this initial work done before we can sensibly proceed to the next step of the whole DSL discussion 20:16:35 does anyone strongly disagree that we should do what Zane proposed, then see what else we're missing? 20:16:39 also if we have to put our name against a bp, can we try be good about setting the state of the bp 20:16:52 asalkeld: +100 20:17:01 * shardy has done a lot of LP clicking this week ;) 20:17:04 so we can grab other bp if we have time 20:17:12 need to look into ttx's scripts 20:17:35 * asalkeld don't like this idea of sticking names to bp so early 20:18:04 asalkeld: +1 20:18:33 asalkeld: Ok, that's fine, if we want to leave stuff unassigned, but with the high priority stuff I was under the impression people wanted to get started on it 20:19:11 I tend to think the assignee of the BP is its manager, not necessarily the one who will do all the work. 20:19:13 shardy: i think zane's proposal is a good direction but i'd really like to see more in the blueprints to better understand some of the details 20:19:43 alexheneveld: which is exactly why I'm proposing we get some people to take ownership of them and do that work 20:19:49 quid pro quo is we'd like to help ofc :) 20:19:58 I can maybe go through the blueprints and add details 20:20:11 zaneb: that would be excellent :) 20:20:12 shardy: feel free to add an action for me 20:20:32 #action zaneb to add details to Provider BPs 20:20:58 Ok, anything else BP related? 20:21:23 +1 excellent zaneb 20:21:25 shardy: I can't assign bps. do I need to send you a list of names? 20:21:57 randallburt: ping me and we'll work that out 20:22:10 #topic havana-1 milestone - need to target BPs and bugs 20:22:17 will do 20:22:29 #link https://wiki.openstack.org/wiki/Havana_Release_Schedule 20:22:31 shardy, when is h1? 20:22:36 thx 20:22:41 #link https://launchpad.net/heat/+milestone/havana-1 20:22:52 asalkeld: 30th May 20:22:55 not much time :) 20:23:25 yea 20:23:28 So we need to figure out what bugs and BP's we can realistically target, since there's loads of bugs and not many BPs 20:24:05 not many bps? 20:24:18 asalkeld: Only two are targetted to h1 20:24:28 thats pretty normal I think 20:24:45 o, thought you meant in general 20:24:46 early on fix some bugs, reorganize things, etc, before the more intense BP work happens 20:25:00 BPs tend to span several milestones 20:25:07 added a third :) 20:25:19 SpamapS: sure, I just want to get things somewhat representative of what's actually happening 20:25:30 so I don't get in trouble at the release meetings ;) 20:26:11 #action everyone to target bp's likely to land in next 2-3 weeks to havana-1 20:26:19 k 20:26:46 Also if there are bugs which need bumping to h-2, please do (e.g jpeeler you have a big backlog of VPC related stuff) 20:27:04 yeah i'll fix it up 20:27:36 I just realized I missed the first agenda item, oops 20:27:40 let's do it now :) 20:27:53 #topic Stable Branch/update/maintenance policy 20:28:05 So this came from a discussion in #heat 20:28:42 regarding what master should work with, as we've previously done stuff like conditional imports to maintain compatibility with older openstack versions 20:29:48 so is the plan now to rely on stable branch? 20:30:02 asalkeld: that's basically the question 20:30:06 So, I'm not sure that accurately describes the problem. 20:30:22 Whats at question is not maintaining backward compatibility with older openstack versions. 20:30:45 We *must* do that 20:30:58 really? 20:31:00 the issue is whether or not to depend on libraries that exist, but are not necessarily available on older platforms 20:31:22 What I take issue with is that we are treating the presence, or lack thereof, of say, quantumclient, as a signal that we should use quantum or not. 20:31:42 SpamapS: we don't necessarily have to do that in master, that's what the stable branches are for 20:31:58 This is not a stable branch issue yet.... 20:32:04 the issue is how do we allow operators to select optional built-in plugins 20:32:05 well we need to talk to older clients 20:32:18 I'm suggesting that if you can get heat, from master, you can get quantumclient. Even if you're not going to use it. 20:32:47 And this makes Heat more stable, as now it will be able to speak to quantum as soon as the catalog dictates that it do so. 20:33:54 so you want a config option to define the builtin catalog? 20:34:08 zaneb: the catalog dictates what you should be using. 20:34:24 asalkeld: no, keystone tells us "we have a quantum endpoint" or not. 20:35:06 but still maybe the admin doen't want heat to use it 20:35:16 as I said the other day, I am +2 on using keystone endpoint list to figure it out 20:36:06 zaneb: Ok, but that would still require e.g folsom users to install e.g the grizzly client libraries? 20:36:09 asalkeld: I'm not sure there is a scenario where an admin says "use that keystone, but ignore the endpoints available", but I acknowledge that there may be one. 20:36:25 asalkeld: that sounds like an unusual case... they can always delete the plugin(s) 20:36:43 shardy: Why is it controversial to say "if you are installing havana's heat, you must also install havana-heat's dependencies" ? 20:36:50 just saying if we have a catalog idea, use it 20:37:05 so, what's the value of conditionally import clients? 20:37:12 shardy: client libraries are theoretically not versioned on the same cadence as core^W integrated projects 20:37:14 SpamapS: because we know that we have existing users who are (or at least were) using master Heat with older openstack versions 20:37:42 shardy, can they use newer client libraries though? 20:37:47 I am trying to understand the reason Heat wants to use the presence of the software as anything other than an indicator that you can use it. 20:38:08 therve: I guess that is true, it's something we've previously avoided though 20:38:09 the problem is accessing new features when they are not backed 20:38:17 shardy: and we promised to them that we'd never add new dependencies? 20:38:43 new client/old service 20:38:49 SpamapS: This is the point, we've not made any formal promises, or even really discussed it 20:38:50 shardy: by all rights, we are already misrepresenting things by listing quantumclient et. al in tools/pip-requires 20:38:53 until now ;) 20:38:55 I hate pip-installing stuff over/around rpm packages, but I will live with it. What I don't want to do is make all these services show up as resource types even if you can't actually use them 20:39:17 zaneb: +1, and +1 20:39:39 zaneb: right, but thats a problem if you have accidentally installed quantumclient.. isn't it? 20:39:59 other way around 20:40:02 Sounds like the catalog suggestion is the solution to the second problem 20:40:17 so keystone catalog solves second problem, at the expense of first problem which is annoying but not a big deal 20:40:26 SpamapS: well with your prosal everyone will always have to install quantumclient.. 20:40:30 proposal 20:41:00 yes, they will, and so we should provide them means to turn off quantum in their configuration. We already have that means though, in the form of the keystone catalog of endpoints. 20:41:05 I think we need our own version of a catalog 20:41:23 user catalog, builtin catalog 20:41:32 please, no more config options ;) 20:41:33 SpamapS: but our resource visibility isn't currently affected by the keystone catalog 20:41:42 Ok I don't really agree with the need for that, but I don't think it is harmful. 20:42:10 shardy: Actually thats something else I'm confused by. What is listing resources? Is that a client call I haven't run into yet? 20:42:34 listing resources? 20:42:37 we need a resource-type-list 20:42:44 there is an API call to get a list of resource types 20:42:51 really 20:42:53 in the ReST API 20:42:59 asalkeld: added it myself ;) 20:43:05 well done 20:43:14 SpamapS: currently it's about a graceful failure when a resource is not backed by a service, but in the future we've been talking about a resource catalog, ref zane's Provider proposal 20:43:24 asalkeld: stevebaker's idea iirc 20:43:44 nice 20:44:08 Right, so I'm thinking the presence of client libraries is a really inconvenient and inaccurate way to predict whether or not the service is available. 20:44:16 SpamapS, +1 20:44:25 Ok, shall we follow up on this via SpamapS bug #1174005 20:44:26 asalkeld: next step is full schema - https://blueprints.launchpad.net/heat/+spec/resource-properties-schema 20:44:27 Launchpad bug 1174005 in heat "swiftclient, quantumclient, and cinderclient, are not optional" [Undecided,New] https://launchpad.net/bugs/1174005 20:44:31 There are 2 issues, and I think it will help if we can separate them. 20:44:52 right, the bug about the client libs not being optional is just one of maintenance and backward compatibility 20:45:13 the other one is I think unreported and talks about more accurately providing a list of available resources. 20:45:14 don't see why swiftclient is required 20:45:28 SpamapS: sounds like we need another BP ;) 20:45:32 crap 20:45:33 we do 20:45:41 * SpamapS will take it since I'm on about it 20:46:11 #action SpamapS to raise BP re available resources 20:46:18 Ok, should we move on? 20:46:25 15min 20:46:37 #topic Feature proposal deadline 20:46:38 asalkeld: don't see why swiftclient isn't required. The day you add a swift endpoint, your heat servers should be able to talk to it. I see no reason to hold back on a simple python library. :-P 20:46:44 anyway, yes lets move on :) 20:46:50 #link http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html 20:47:20 What do people think about aligning with what nova are doing ref BP proposal deadlines? 20:47:29 seems like a good idea 20:47:37 Maybe not such an issue for us being a smaller project, but seems like a good idea 20:47:47 If anybody proposes a patch so large it will take 2 weeks to review, it should get -2 anyway imho 20:47:56 what do we gain from deciding that now? 20:48:28 kebray: we get to chime in on that thread and say "we'll do that too", so people will know what the plan is 20:48:33 small patches, incremental changes, this issue will never come up 20:48:36 we gain you not making me scrable two weeks before ff kebray ;) 20:48:43 zaneb: +1000 ;) 20:48:49 :-) ok ok 20:49:27 Ok, sounds like most are agreed then, lets go to open disucussion for the last 10mins? 20:49:49 #topic Open discussion 20:49:50 reason to do BP proposal deadlines is also just to keep the work focused on specs early in the cycle, so dev time happens well before FF. 20:49:54 how about "if you propose a feature close to freaze, we might not merge" 20:50:05 so, its fairly insignificant atm, but can I get eyes on https://review.openstack.org/#/c/27934/? 20:50:07 That's almost common-sense. 20:50:07 depending on ... stuff 20:50:26 asalkeld: this is basically just quantifying/documenting that 20:50:58 randallburt: mixes spaces and tabs, -1 ;) 20:51:11 and sorry, didn't mean to publish that one, but based on convo's yesterday, that's how we want to start evolving hot 20:51:18 zaneb: yikes! sorry about that. 20:51:21 will fix 20:51:34 I got not found 20:51:40 asalkeld: remove the ? 20:51:40 randallburt: thanks for posting, I had a quick look, will post comments later 20:51:53 asalkeld: might have forgotten to add you 20:52:10 got it now - "?" 20:52:11 I think refining the syntax through gerrit will be better than etherpad etc 20:52:20 randallburt: great starting this 20:52:22 thanks 20:52:44 I'm still under other commitments for a few more days but hope to have more drafts soon-ish 20:52:54 and with consistent spacing to boot. ;) 20:53:21 #link https://review.openstack.org/#/c/27934/ 20:53:26 randallburt: I had a quick look and will also provide comments soon 20:53:32 * kebray is working diligently to free randallburt's schedule. 20:53:38 randallburt, interesting part is how config/userdata gets into the instance 20:53:53 asalkeld: agreed. starting small, though ;) 20:54:00 yip 20:54:16 5 min left 20:54:21 anything else? 20:54:37 join my orchestration meeting tommorow! 20:54:38 :) 20:54:45 time? 20:54:47 when is the time? 20:54:56 2000UTC, taking over the previous sandy orchestration meeting 20:55:05 #link https://wiki.openstack.org/wiki/Meetings#Orchestration_team_meeting 20:55:06 cool 20:55:39 harlowja: will try to make it :) 20:55:43 cool 20:55:50 to many meetings to go to :-P 20:56:05 anything else from anyone? 20:56:28 Ok, thanks all 20:56:37 #endmeeting