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