20:00:28 <stevebaker> #startmeeting heat
20:00:29 <openstack> Meeting started Wed Nov 13 20:00:28 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:33 <openstack> The meeting name has been set to 'heat'
20:00:37 <stevebaker> #topic rollcall
20:00:39 <randallburt> hola
20:00:45 <andrew_plunk> heeey
20:00:50 <stevebaker> booyaa
20:00:52 <mspreitz> here
20:00:59 <jpeeler> hi
20:01:09 <tims> o/
20:01:10 <asalkeld> o/
20:01:11 <sdake> o/
20:01:12 <spzala> Hi
20:01:15 <skraynev_> o/
20:01:16 <andersonvom> o/
20:01:16 <shardy> o/
20:01:29 <zaneb> evening
20:01:35 <arbylee> hello
20:01:46 <adrian_otto> hi
20:02:03 <stevebaker> hope you've all recovered
20:02:17 <stevebaker> no actions last meeting, so
20:02:17 <zaneb> not even close
20:02:24 <randallburt> mostly. more lagged coming back than I was going over.
20:02:26 <tspatzier_> hi
20:02:32 <stevebaker> #topic Adding items to the agenda
20:02:59 <stevebaker> Anything to add, so it doesn't get lost in the rolling-scrum of Open Discussion?
20:03:16 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:03:23 <adrian_otto> do you want to do any ODS retrospective?
20:03:32 <stevebaker> post it here and I will add it
20:03:41 <shardy> adrian_otto: I put an item on the agenda for that
20:03:43 <stevebaker> adrian_otto: we have Summit review, BPs/actions and prioritization
20:03:47 <randallburt> adrian_otto:  I think that's already on the agenda
20:03:50 <shardy> Summit review, BPs/actions and prioritization
20:04:00 <adrian_otto> I see, tx.
20:04:04 <asalkeld> do we want to talk about mistral?
20:04:14 <sdake> Change scope of Orchestration program to "OpenStack Control Program"
20:04:14 <stevebaker> sure
20:04:24 <sdake> can probably cover that there
20:04:46 <randallburt> is there much to talk about at this point? I thought its mostly design/planning stages
20:04:54 <stevebaker> #topic Icehouse API policy (keep adding stuff, or freeze v1 + version bump for new stuff?)
20:05:04 <shardy> So I added this
20:05:29 <sdake> i'm not a big fan of rolling new features into an existing api
20:05:32 <shardy> Wanted to discuss our policy on API additions, and also the possiblity of a new version without the tenant in the path
20:05:35 <sdake> so i'd suggest freeze
20:06:04 <shardy> sdake: I'm tending to agree with you, but we're already seeing patches adding stuff to the existing API
20:06:04 <asalkeld> what's wrong with new features in a version?
20:06:05 <randallburt> +1 for revving the api to remove the tenant so we can have sane management -type calls in Icehouse
20:06:11 <stevebaker> currently we're not planning on any breaking changes, just additions. This suggests v1_1
20:06:11 <shardy> so we need core to agree the review policy
20:06:20 <asalkeld> -1 (until I get a reason)
20:06:24 <shardy> randallburt: That is where I'm headed :)
20:06:29 <zaneb> yeah, I think additions should go in v1_1
20:06:39 <sdake> wfm
20:06:43 <asalkeld> obviously changing an api is really bad
20:06:46 <mspreitz> what's wrong with additions in v1?
20:07:01 <asalkeld> but adding a standalone new thing?
20:07:02 <zaneb> -0 on removing the tenant thing, I am unconvinced by the arguments in favor
20:07:04 <shardy> zaneb: and the removing tenants should be a major bump or also in v1_1?
20:07:09 <stevebaker> however, "Build information API endpoint" is something deployers might want to turn off, which implies we need extensions if we do that
20:07:13 <sdake> mspreitz some people will end up with v1 without additions, some people will end up with v1 wit hadditions
20:07:21 <sdake> how are they to know which additions to use without versioning?
20:07:25 <randallburt> the current url scheme is sub-optimal for the managment/monitoring type stuff we want to pull from the api. that's by def a contract breaking change.
20:07:38 <mspreitz> I thought the API already has a way to query for extensions
20:07:42 <zaneb> shardy: if we did it... dunno, in theory it's manageable by just changing the endpoint?
20:07:45 <asalkeld> sdake not the job of the api for that
20:07:51 <shardy> zaneb: How do you do a request which e.g lists multiple tenants stacks if the path impicitly scopes the request?
20:08:08 <andrew_plunk> new endpoints could potentially break old endpoints, which is why a new version would be safer
20:08:28 <zaneb> shardy: /global/stacks ?
20:08:39 <shardy> zaneb: I'd like the request scope to be purely based on context, not path
20:08:51 <zaneb> why?
20:08:54 <shardy> zaneb: Maybe that would work, seems less clean than GET /stacks
20:09:12 <zaneb> true
20:09:13 <shardy> and the scope is decided by the roles in the request context
20:09:20 <shardy> roles/projects/domains
20:09:37 <zaneb> actually, there's nothing stopping us from adding that alongside the tenant-scoped stuff, since it's just for the management api
20:09:46 <andersonvom> the tenant in the url shouldn't be trusted anyway, so it makes little sense to me that it is there in the first place
20:09:56 <randallburt> andersonvom:  agreed
20:09:57 <shardy> andersonvom: agree
20:10:00 <sdake> agree
20:10:02 <zaneb> "I'd like the request scope to be purely based on context, not path" <- this is the opposite of why HTTP was invented
20:10:02 <stevebaker> GET /stacks?scope=global <- ?
20:10:12 <asalkeld> this needs to be inline with other openstack api
20:10:40 <randallburt> perhaps we need to discuss this with nova et al?
20:10:51 <shardy> zaneb: well we're implicitly tied to scoping the data we return based on the RBAC profile provided by keystone token validation
20:11:05 <shardy> so why encode a subset of the stuff in the path?
20:11:06 <stevebaker> they have different paths for admin actions
20:11:20 <shardy> The *heat specific* stuff should be encoded in the path IMHO
20:11:27 <randallburt> stevebaker:  IIRC everyone wants to move away from that tho
20:11:31 <shardy> not characteristics of the user making the request
20:12:03 <stevebaker> so we're supposed to be talking about API versioning, not designing v2 ;)
20:12:07 <shardy> stevebaker: the keystone devs said "don't do that" re admin specific endpoints
20:12:13 <randallburt> stevebaker:  fair point ;)
20:12:14 <shardy> has caused them pain apparently
20:12:25 <stevebaker> can we get back on topic for a bit?
20:12:49 <shardy> stevebaker: sure, I'll follow up with ML/wiki discussion
20:13:06 <stevebaker> we're going to have minor additions within the scope of a v1_1 *or* extensions
20:13:16 <asalkeld> if every time we add a feature we put it in a new version, we'll have v100 soon
20:13:21 <randallburt> stevebaker:  agreed, but I think it matters as to *why* we'd rev the api. is the question if we *should* in Icehouse?
20:13:34 <stevebaker> asalkeld: we have v1_1 for the duration of icehouse
20:13:48 <shardy> It could be argued that just adding stuff is OK
20:13:58 <asalkeld> since when is the version related to the cycle?
20:14:08 <shardy> and that a bump is only required when existing interfaces change
20:14:21 <randallburt> I think just adding stuff doesn't require a contract revision, as long as all the old calls work
20:14:23 <asalkeld> we have continuous deployers
20:14:43 <stevebaker> shardy: how do API consumers know if the API they are calling has the feature they need?
20:15:04 <shardy> stevebaker: That is a good point, but it's not specific to Heat
20:15:05 <asalkeld> stevebaker, you publish features/capabilties
20:15:07 <sdake> they know via the version #:)
20:15:09 <randallburt> via the version number.
20:15:24 <stevebaker> asalkeld: like an extensions introspection call?
20:15:33 <shardy> well Neutron for example have been adding stuff throughout Havana, haven't they?
20:15:37 <asalkeld> yeah, just not extensions
20:15:55 <randallburt> adding stuff without breaking old stuff doesn't need a new version, though. extensions are different and should be versioned independently IMO.
20:16:05 <asalkeld> +1
20:16:10 <stevebaker> asalkeld: why not extensions?
20:16:32 <asalkeld> well we are not talking about 3rd party extensions
20:16:37 <zbitter> stevebaker: alternate answer: suck it and see
20:16:51 <asalkeld> how do users figure out the features
20:16:54 <randallburt> stevebaker:  I think its a slippery slope of compatibility hell. We see it in nova/cloud servers.
20:16:59 <shardy> zaneb: discovery via 404 ;)
20:17:03 <randallburt> lol
20:17:17 <mspreitz> What about changes in the HOT language?
20:17:27 <mspreitz> not changes in the API signature
20:17:28 <asalkeld> that's template versioning
20:17:31 <randallburt> mspreitz:  define "changes"
20:17:31 <stevebaker> mspreitz: different topic
20:17:41 <mspreitz> OK
20:17:41 <shardy> mspreitz: that is a separate discussion, it's encoded in the template format
20:18:22 <mspreitz> So I'm looking forward to the answer to the question about why extensions are different
20:18:29 <stevebaker> so could a v1.1 rev remain with a /v1/ path or would we have to make it /v1_1/?
20:18:48 <asalkeld> stevebaker, not sure
20:18:51 <randallburt> we'd have to have a /v1.1/ path IMO
20:19:00 <shardy> stevebaker: surely the paths have to differ?
20:19:03 <zaneb> stevebaker: you're supposed to respond to both I believe
20:19:13 <asalkeld> but the version is discoverable (not sure why features can't be)
20:19:22 <zaneb> stevebaker: but luckily there's some middleware that handles it all for you
20:19:27 <zaneb> or something
20:19:39 <asalkeld> seems like abusing the version IMO
20:19:58 <randallburt> the version middleware should sort it so that a call to the root of the service shows you what versions are available and what paths they have.
20:20:28 <asalkeld> so 20min in
20:20:28 <zaneb> yep
20:20:38 <shardy> Maybe we should move this discussion to the ML and document a policy on API revisions for next week
20:20:41 <stevebaker> indeed
20:20:43 <randallburt> I believe the keystone catalog supports different versions as well
20:20:44 <randallburt> agreed
20:20:45 <asalkeld> +1
20:21:05 <stevebaker> I'll do this next, because it is related
20:21:07 <stevebaker> #topic Build information API endpoint (https://review.openstack.org/#/c/55434/)
20:21:29 <shardy> So I'm still not sure what actual value this provides
20:21:45 <sdake> seems like questionable value with potential for abuse
20:21:47 <shardy> other than providing a shortcut which avoids folks querying their CM tools managing Heat
20:21:47 <stevebaker> I would find it useful, as long as the call was at least authenticated
20:21:58 <randallburt> easily identify what version of heat is deployed even if you don't have access to the infra its running on
20:22:13 <randallburt> I believe the latest patch makes it optional as well as authenticated.
20:22:19 <shardy> randallburt: Why do you care, unless you're the deployer or an attacker?
20:22:33 <randallburt> or someone submitting a bug report
20:22:36 <shardy> If you're the deployer, you have the info already, via some means
20:22:36 <sdake> ya, the features are exported via the versioning of the api :)
20:22:40 <stevebaker> I'd like template_guide to document what version resources and their properties were added (or deprecated)
20:22:48 <randallburt> or a support technician
20:23:02 <randallburt> that doesn't have access to the infra
20:23:07 <sdake> stevebaker: in that case, the template would fail to validate with an invalid prop
20:23:22 <sdake> or invalid versioning of the template
20:23:23 <randallburt> stevebaker:  that's a different bp, though
20:23:27 <zaneb> you know, apache used to report it's version number in error pages and stuff
20:23:28 <shardy> randallburt: I'm not saying don't provide the info, I'm saying, why does heat have to provide it?
20:23:28 <stevebaker> the published version should not be too fine-grained - and deployers would often carry their own patches too
20:23:33 <randallburt> and a little off topic ;)
20:23:42 <zaneb> and now they don't do that because people use that info to hack it
20:23:44 <kebray> shardy customers care.
20:23:47 <kebray> they consume the API.
20:23:54 <stevebaker> randallburt: my point is that the version becomes an interesting piece of information that a user will want to know
20:24:10 <kebray> Support employees care, as we put out a new build, they would like to track that. they don't have access to the infrastructure, only the API.
20:24:27 <shardy> kebray: Ok, so what version do you report, if you have a deployement scaled out running multiple versions of things?
20:24:35 <sdake> keybray in this case, the version of the api changes
20:24:42 <randallburt> stevebaker:  agreed. but that sort of supports having it. As a service provider, the information is useful
20:25:06 <randallburt> shardy:  each version of the service would report independently
20:25:08 <arbylee> sdake: the api doesn't necessarily change if you push out deploys with different configuration options
20:25:08 <stevebaker> shardy: the version should be from whatever engine responded to the version rpc call
20:25:21 <kebray> shardy, that's the implementer to decide.  e.g. at Rackspace, we might manually bump a version number in a file.  Others may automate the version from a CI tool.  If we return it as a string, it can have whatever info we want.
20:25:24 <andersonvom> shardy: if you have multiple versions, that would be a useful case to actually find out that different info is being reported.
20:25:53 <sdake> perhaps a different approach is a config option, rather then the git sha
20:26:01 <sdake> to handle arblyee's case
20:26:23 <mspreitz> OpenStack is not monolithic, so the version is not monolithic
20:26:32 <asalkeld> I think it's ok if the deployer wants it
20:26:33 <randallburt> sdake:  that would also be acceptable; that way the deployer can define what it meands
20:26:36 <kebray> sdake agreed, I don't want a git sha.  This number needs to be understandable by humans, and for our setup, we may choose to have it be an incrementing number.
20:26:54 <sdake> ok well that approach wfm :)
20:26:54 <randallburt> s/meads/means/
20:26:54 <zaneb> what mspreitz said. I don't see how this can be useful
20:27:05 <stevebaker> asalkeld: how do deployers turn it off if it is not an extension? maybe a config option.
20:27:06 <shardy> andersonvom: but what version do you report, the API you hit, the engine which processes the request, both, versions of the platform it's all running on etc etc?
20:27:22 <asalkeld> yeah, config option
20:27:29 <randallburt> shardy:  yes. when would they be different?
20:27:29 <kebray> zaneb it's useful for us. I promise. API users need to know when our code has changed, even if nothing about the contract has changed.
20:27:30 <zaneb> kebray: if you as a cloud operator don't know what version of Heat you've rolled out, we really can't help you
20:27:51 <lifeless> zaneb: wait, what?
20:27:54 * sdake giggles at zaneb
20:27:58 <kebray> zaneb I know what version.. the other 4000 employees don't know. I want an API call that allows them to get it.
20:28:18 <stevebaker> alright, lets move this to the review/ml
20:28:23 <randallburt> ok.
20:28:25 <shardy> randallburt: you could be running slightly different versions of heat during a live upgrade couldn't you?
20:28:27 <lifeless> zaneb: I think you need to take some anti-troll pills or something :)
20:28:34 <lifeless> shardy: I would totally expect that.
20:28:36 <stevebaker> #topic Summit review, BPs/actions and prioritization
20:28:38 * sdake for once agrees with lifeless
20:28:40 <shardy> randallburt: assume you plan to chase trunk or do rolling updates of some sort
20:28:45 <randallburt> shardy:  fair point, but that's a very small windo
20:28:47 <randallburt> window
20:28:56 <lifeless> depends on the cloud size
20:29:04 <lifeless> and update frequency
20:29:12 <randallburt> new topic, lets move on
20:29:19 <lifeless> versions are useful, they can get captured in logs for automated post mortems - fin.
20:29:21 <shardy> randallburt: but it's that window when things are most likely to break
20:29:55 <stevebaker> I need to triage the blueprint list, but here is where we are at https://launchpad.net/heat/+milestone/icehouse-1
20:29:59 <shardy> lifeless: +1, capture in logs, return in error message to (authenticated) users
20:30:46 <stevebaker> any general thoughts on summit?
20:30:55 <asalkeld> too many
20:31:00 <randallburt> indeed.
20:31:25 <sdake> maybe best to let them filter out into the implementation over the next 6 mo
20:31:40 <asalkeld> we need to go through the etherpads
20:31:53 <asalkeld> and make blueprint / fill in current ones
20:32:00 <stevebaker> I'm a little worried that options for software config have expanded, not reduced. But I still think that arguments need to be augmented with actual code from this point
20:32:16 <randallburt> stevebaker:  +9001
20:32:28 <shardy> stevebaker: do we have an umbrella BP showing the dependent BPs for software-config to happen?
20:33:06 <stevebaker> shardy: I think the blueprints need to be completely rejigged to reflect our refined understanding
20:33:34 <asalkeld> yeah, time consuming stuff
20:33:43 <stevebaker> #action stevebaker re-organise software config blueprints
20:33:48 <randallburt> heavy is the head...
20:33:49 <shardy> stevebaker: Ok, cool, just wondered if we've started a task breakdown for that in particular, since it seems the biggest chunk of work
20:34:30 <shardy> stevebaker: I'll raise some and do a wiki related to the request scoping, trusts, admin, in-instance auth related stuff
20:34:37 <stevebaker> shardy:
20:34:47 <stevebaker> shardy: thanks
20:35:22 <asalkeld> stevebaker, I can help with bp pruning too
20:35:26 <shardy> What are the other big items, autoscaling, ...?
20:35:30 <tspatzier> stevebaker, for software config which is the master BP? is it hot-software-config?
20:35:35 <mspreitz> I'm still not clear on how the software config stuff will bootstrap
20:35:54 <shardy> stevebaker: Yeah, get volunteers to help get things into shape or you'll go insane clicking in launchpad :)
20:35:58 <stevebaker> so as per normal, people should be writing their own blueprints, and setting the Milestone Target based on what they think is achievable
20:36:41 <shardy> stevebaker: My concern was taking the big items, breaking them up and getting folks commited to working on the bits
20:36:43 <asalkeld> shardy, there was "stack <action> stop_on_error"
20:37:00 <asalkeld> that enabled debugging, and retry
20:37:04 <stevebaker> and you don't *need* something to be approved to work on it, but you carry the risk of being smacked with a banhammer at the end of the process
20:37:11 <randallburt> we also should consider some of the incoming requirements from trove and savannah
20:37:36 <stevebaker> randallburt: they know to raise blueprints
20:37:37 <randallburt> if sdake will ever let me use the banhammer… :P
20:38:12 <asalkeld> randallburt, yeah we probably need a way of prioritizing those features
20:38:23 <randallburt> stevebaker:  k. I'll ping hub_cap next week when I'm in SFO
20:38:28 <stevebaker> shardy: I think all the big items have owners who can handle that, apart from software config
20:38:50 <stevebaker> shardy: are there others you are aware of that need breaking down and delegating?
20:38:57 <shardy> stevebaker: Ok, cool, as long as you're happy that's the case and know who they are :)
20:39:36 <stevebaker> radix, randallburt, autoscaling is big, let us know if help is needed
20:39:56 <hub_cap> hi lo randallburt ill be around
20:40:01 <sdake> yes we need to get rolling on autoscaling
20:40:04 <shardy> stevebaker: No, we just discussed a lot last week so wanted to make sure we had owners for all the major items
20:40:21 <stevebaker> #action stevebaker to go through summit etherpads and make sure all blueprints are raised https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Heat
20:40:27 <asalkeld> maybe we can blog about summit?
20:40:34 <asalkeld> to clarify ideas
20:40:40 <randallburt> stevebaker:  will do
20:40:58 <stevebaker> moving on?
20:41:02 <asalkeld> yeah
20:41:06 <randallburt> yup
20:41:08 <stevebaker> #topic Change scope of Orchestration program to "OpenStack Control Program"
20:41:23 <randallburt> here there be dragons.
20:41:23 <zaneb> where did this come from?
20:41:26 <sdake> this was mostly SpamapS idea, but since he isn't here, I'll suggest it
20:41:31 <sdake> yes dragons indeed :)
20:41:40 <mspreitz> do tell, why is this a good idea?
20:41:41 <shardy> Why?
20:41:42 <stevebaker> my opinion: Orchestration already means all things to all people, so we just need to redefine what *we* mean by "Orchestration" ;)
20:41:54 <sdake> his argument was mostly of the line that "we are doing autoscaling in heat, and we do orchestration"
20:41:54 <zaneb> stevebaker ++
20:42:07 <randallburt> stevebaker:  +1. Let solum be the new dumping ground
20:42:17 <asalkeld> SpamapS, also was aiming at mistral I think
20:42:19 <sdake> and there are other projects coming online such as qonos and mistral
20:42:37 <sdake> i think his basic idea was to expand our scope to cover all the things ;)
20:42:37 <stevebaker> asalkeld: so you think Mistral should be brought into our programme?
20:42:40 <mspreitz> and "control program" is clearer?
20:43:15 <asalkeld> stevebaker, if we are going to use it for our core flow control
20:43:22 <asalkeld> it would be nice
20:43:22 <sdake> mistral controls workflow
20:43:30 <sdake> autoscaling api controls autoscale
20:43:31 <randallburt> wasn't the longer term goal to move autoscale *out* of heat, though?
20:43:36 <sdake> heat controls the rest of the stack
20:43:46 <sdake> they are all related, in some nebulous way
20:43:55 <asalkeld> I am not sure on this move
20:43:55 <stevebaker> randallburt: autoscaling will still be in the orchestration program though
20:44:03 <kebray> we orchestrate autoscaling.  autoscale doesn't necessarily have to be in orchestration.
20:44:03 <sdake> one problem it would solve is "how to depend on mistral in an integrated program" like heat
20:44:05 <randallburt> stevebaker:  fair point
20:44:29 <stevebaker> #topic Mistral
20:44:33 <zaneb> autoscaling is going to be deeply connected to orchestration, they way we are planning to implement it
20:44:35 <asalkeld> I don't want us to look like we are trying to take over openstack projects
20:45:02 <asalkeld> but if those projects are keen, I have no problem
20:45:07 <stevebaker> asalkeld: if they belong in orchestration we should make the case, like tusker merging with tripleo
20:45:19 <kebray> I'm not convinced Mistral as a solid non-changing clear mission yet.  So, shouldn't spin too many brain cycles on it just yet IMO.
20:45:24 <randallburt> I don't want us to be a shortcut to integrated status though
20:45:45 <shardy> stevebaker: +1, but we shouldn't redefine our scope to include totally non-orchestration related projects
20:45:50 <stevebaker> no that wouldn't be the intent
20:45:54 <asalkeld> I think we can defer this for a while
20:45:54 <sdake> clearly we don't want to present an opportunity to game the system
20:45:57 <stevebaker> shardy: agreed
20:46:20 <sdake> but mistral is related in some way i can't put my finger on to what heat does :)
20:46:33 <stevebaker> asalkeld: anything technical about Mistral you can present yet?
20:46:35 <zaneb> randallburt: in theory new projects have to be incubated, even if part of established programs
20:46:44 <asalkeld> so it's in design
20:46:45 <randallburt> zaneb:  k
20:47:03 <stevebaker> asalkeld: do you want to participate in that, so heat
20:47:06 <asalkeld> we would need to build it (not head devs)
20:47:08 <stevebaker> 's needs are represented
20:47:20 <asalkeld> sure
20:47:33 <asalkeld> I can make sure we get what we need
20:47:44 <asalkeld> not sure of the time line tho'
20:47:48 <stevebaker> #topic Open discussion
20:47:53 <sdake> they ahave a roadmap
20:48:08 <asalkeld> long and winding road<map>
20:48:12 <tims> https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
20:48:21 <randallburt> so, does this latest resolution change our status in any way other than calling ourselve's Openstack Orchestration (™)?
20:48:22 <tims> looking for feedback on namespacing stack-metadata
20:48:36 <sdake> well to do such a change, would require tc approval
20:48:41 <sdake> which would require board approval
20:48:48 <sdake> which means steve baker would have to sell it
20:48:50 <stevebaker> tims: is this for horizion presentation hints?
20:48:57 <sdake> and I assume we would all have to stand together to agree with the apporach
20:48:58 <tims> stevebaker: yes
20:49:06 <kebray> For those interested  https://etherpad.openstack.org/p/MistralRoadmap
20:49:07 <tims> as well as other things
20:49:09 <stevebaker> lets not call it metadata, please! ;)
20:49:12 <zaneb> randallburt: not at all
20:49:15 <randallburt> stevebaker:  lol
20:49:19 <randallburt> zaneb:  k
20:49:23 <tims> I'm not attached to the name :)
20:49:46 <tims> just a place where we can safely put things that Heat should ignore in the template
20:49:47 <shardy> Yeah metadata is already thrice overloaded
20:49:54 <kebray> stevebaker  extra data?
20:50:18 <shardy> tims: Can it just be a comment block?
20:50:30 <shardy> tims: or do you need it parsed and available via the API?
20:50:30 <stevebaker> tims: so maybe a top-level template section which is ignored by heat engine
20:50:34 <randallburt> shardy:  oh the looks tims gave me when I suggested that.
20:50:43 <stevebaker> shardy: it needs to be structured, for things outside heat to parse
20:50:44 <tims> haha randallburt
20:50:52 <shardy> OK
20:50:57 <randallburt> besides, comments are lost when safeloaded
20:51:00 <tims> yeah it should be a top level section
20:51:04 <kebray> metadata is supposed to be overloaded... it means data about other data.  It applies everywhere.
20:51:27 <asalkeld> stack level Metadata?
20:51:37 <stevebaker> imagine a visual template authoring tool, x,y coordinates of where resources are dragged need to be stored somewhere
20:51:44 <asalkeld> to be inline with resource Metadata
20:51:45 <kebray> ok, cube conversations just convinced me.  Just call it data :-)
20:51:46 <randallburt> in the context of Horizon, its actual data though
20:51:50 <shardy> kebray: but the template terminology should be distinct, because we already have metadata blocks which actually do stuff
20:52:10 <zaneb> kebray: if we had 50 sections called 'data', I would complain about that too ;)
20:52:12 <stevebaker> asalkeld: there is no resource metadata in HOT (not exposed anyway)
20:52:29 <asalkeld> stevebaker, cool:)
20:53:08 <tims> soo stack-metadata then?
20:53:11 <kebray> zaneb what should we call it?
20:53:25 <shardy> stevebaker: Are you sure?  We have a Metadata block in CFN templates?
20:53:28 <stevebaker> tims: so, I think the answer is yes, but we need to bikeshed the name. I think I'd prefer something top-level rather than sprinkling data throughout the template
20:53:39 <tims> stevebaker: agreed
20:53:44 <randallburt> stevebaker:  agreed
20:53:58 <kebray> stevebaker agreed
20:54:20 <asalkeld> sounds ok
20:54:26 <stevebaker> omg, we agreed on something!
20:54:36 <asalkeld> :-O
20:54:42 <stevebaker> 6 minute4s
20:54:42 <tims> :)
20:54:52 <shardy> https://github.com/openstack/heat-templates/blob/master/hot/F18/WordPress_NoKey.yaml#L93
20:54:53 <randallburt> tims is a consensus builder
20:54:55 <shardy> stevebaker: ^^
20:55:12 <zaneb> kebray: sorry, that was supposed to be a reply to the earlier comment about 'metadata' being intentionally overloaded
20:55:45 * kebray says no worries zaneb
20:55:48 <stevebaker> shardy: HOT doesn't explicitly ban Metadata yet, but it is not part of the spec and there is no alternative until some bare-bones software config is implemented
20:55:57 <radix> oh no
20:56:12 <radix> *shakefist* time zoooooones! :(
20:56:15 <randallburt> radix: time change getcha didn't it
20:56:22 <radix> yes :(
20:56:33 <stevebaker> DST can die in a fire
20:56:54 <sdake> move to arizona - we roll on UTC :)
20:57:11 <radix> so, I'm prepping a proposed api spec (actually I started it a long time ago but never published it) for autoscaling
20:57:29 <radix> I'll post it to the list when I've put it up for comment
20:57:37 <zaneb> capital
20:58:26 <stevebaker> lets mosey in a relaxed fashion back to #heat and have a friendly conversation
20:58:33 <stevebaker> #endmeeting