20:00:33 <asalkeld> #startmeeting heat
20:00:34 <openstack> Meeting started Wed Feb 11 20:00:33 2015 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:37 <openstack> The meeting name has been set to 'heat'
20:00:58 <asalkeld> #topic rollcall
20:01:00 <tspatzier> hi
20:01:07 <jasond``> o/
20:01:07 <stevebaker> hi
20:01:09 <Tango> hi
20:01:10 <shprotby> hi
20:01:10 <dgonzalez> hi
20:01:11 <shardy> o/
20:01:38 <zaneb> o/
20:02:02 <skraynev_> o/
20:02:06 <asalkeld> #topic Review action items from last meeting
20:02:31 <asalkeld> (no actions)
20:02:44 <asalkeld> #topic Adding items to the agenda
20:03:14 <asalkeld> anything we need to talk about?
20:03:19 <stevebaker> convergence bps
20:03:23 <asalkeld> ok
20:03:24 <pas-ha> o/
20:03:29 * zaneb hides
20:03:34 <stevebaker> lol
20:03:38 <pas-ha> added one to discuss if we have time
20:03:50 <stevebaker> i don't have anything to say, I just figured it should be there :)
20:04:09 <asalkeld> sure
20:04:30 <asalkeld> i'll get started and we can have open discussion at the end
20:04:44 <asalkeld> #topic covergence specs
20:05:11 <asalkeld> so we need to get these in, so the code can start landing
20:05:33 <asalkeld> any major issue any one has seen?
20:05:58 <skraynev_> with convergence or something else?
20:06:05 <asalkeld> convregence specs
20:06:29 <skraynev_> in this case nothing :)
20:06:45 <stevebaker> Reading ryan's formal model email, I wonder if we should use tooz for the resource locking (mysql driver by default)
20:07:31 <stevebaker> since we're locking on a new thing anyway, disruption shouldn't be too bad
20:07:57 <asalkeld> stevebaker: we are only setting the status, seems like over kill
20:08:13 <asalkeld> using update ... where
20:08:23 <asalkeld> afaik
20:08:24 <stevebaker> oh, so its not really a lock
20:08:32 <zaneb> stevebaker: I think we will regret that come phase 2, where we want to get rid of the locks
20:08:34 <asalkeld> logical lock
20:08:56 <stevebaker> sure, ok
20:09:05 <zaneb> arguably there is a mutex on the resource, because we do atomic updates of the status
20:09:17 <zaneb> it's not like we use a mutex to set the status though
20:09:34 <stevebaker> ryansb: http://paste.openstack.org/show/171566/
20:10:06 <ryansb> stevebaker: thank you. Sorry I'm late
20:10:18 <stevebaker> bp
20:10:20 <stevebaker> np
20:11:06 <ryansb> Yeah, didn't mean to make it sound (in my email) like we *needed* a locking service
20:11:24 <ryansb> just that it would be possible to use one, and that the granularity of logical locks we have now is sensible
20:12:03 <asalkeld> ok
20:12:11 <asalkeld> cores: i ask that you prioritise specs now, and in particular the convergence ones
20:12:30 <asalkeld> there is always less time than you expect
20:12:40 <stevebaker> will do
20:12:47 <asalkeld> good to give this a chance of success
20:12:51 <skraynev_> got it
20:12:57 <pas-ha> ok
20:12:57 <stevebaker> for kilo?
20:13:11 <skraynev_> I suppose - yes
20:13:13 <asalkeld> stevebaker: at least to get most of the code in
20:13:30 <asalkeld> moving on
20:13:36 <asalkeld> #topic Bug 1414674 (orphan queues after heat-engine restart)
20:13:37 <openstack> bug 1414674 in oslo.messaging "Number of Rabbitmq queues is growing from failover to failover" [Undecided,New] https://launchpad.net/bugs/1414674 - Assigned to sajuptpm (sajuptpm)
20:13:52 <pas-ha> yes, that's a new one
20:14:16 <stevebaker> clever openstack bot
20:14:17 <pas-ha> after each heat-engine restart we have 2 randomly (engine uuid) message queues left over
20:14:27 <pas-ha> and they live until rabbit cluster is restarted
20:14:44 <stevebaker> is that why I've seen my rabbit memory use grow?
20:15:08 <pas-ha> what implications would be to set amqp_auto_delete = true ?
20:15:08 <asalkeld> pas-ha: do we even use the randomly named one?
20:15:13 <pas-ha> yes
20:15:34 <asalkeld> ok, what's it for?
20:15:36 <zaneb> we use it to check that the engine is still alive if it is holding a lock
20:15:40 <pas-ha> we have 4 queues - engine, engine.hostname, engine-uuid, engine-uuid.hostname
20:15:54 <zaneb> so it should probably be auto_delete=True
20:16:22 <asalkeld> auto_delete seems esp. good for "engine-alive"
20:16:27 <pas-ha> ok, will make a patch and we'll test it then
20:17:04 <zaneb> only risk is we lose connectivity to rabbit, and then locks start getting stolen while work is still in progress
20:17:45 <zaneb> but I think it's low risk - not like we have full-on fencing anyway
20:17:48 <asalkeld> zaneb: we the solution is: if we loose connectivtity we assume that
20:17:57 <asalkeld> and don't do anything
20:18:42 <asalkeld> we could just exit
20:18:53 <pas-ha> what if we gracefuly restart the heat-engine on loosing connectivity? engine-id will change
20:19:21 <asalkeld> sys.exit
20:19:22 <zaneb> pas-ha: that doesn't really help
20:19:34 <zaneb> but anyway, it's not important
20:19:37 <zaneb> we can move on
20:19:56 <asalkeld> #topic open discussion
20:20:10 <asalkeld> (no more "official topics")
20:20:38 <jasond``> i have a question about stack-tags blueprint
20:20:48 <asalkeld> o, good idea
20:21:03 <jasond``> it looks like it's going to be different that we proposed in the spec
20:21:08 <jasond``> https://review.openstack.org/#/c/153390/3/heat/tests/test_sqlalchemy_api.py
20:21:16 <jasond``> do i need to resubmit a spec?
20:21:17 <stevebaker> We need to start thinking about the orderly transition of power from asalkeld's glorious reign (who wants to run for PTL?)
20:21:30 <asalkeld> :-)
20:22:01 <asalkeld> jasond``: i don't think before you do more work
20:22:16 <asalkeld> just update it to show reality
20:22:42 <jasond``> ok, i'll do that.  so everyone is okay if tags are not key/value pairs?
20:22:54 <miguelgrinberg> jasond``: is the spec really going to be that different?
20:23:05 <asalkeld> jasond``: sounds good to me
20:23:07 <zaneb> jasond``: I think just propose a change to the spec (not a new spec)
20:23:15 <jasond``> miguelgrinberg: that's the main difference
20:23:22 <jasond``> ok, will do
20:23:33 <asalkeld> jasond``: are you going to follow the nova api ?
20:23:54 <jasond``> asalkeld: yes, was looking at doing that
20:24:00 <asalkeld> great
20:24:18 <miguelgrinberg> jasond``: so I'm working on a guideline for the api-wg regarding tags, very similar to the nova spec, will let you know what it is ready to be reviewed
20:24:34 <jasond``> miguelgrinberg: ok, thanks
20:24:40 <stevebaker> jasond``: I guess if filtering is the main purpose of our tags then they really need to be simple
20:25:08 <jasond``> stevebaker: agreed
20:25:12 <asalkeld> stevebaker: so i won't run this next cycle, unless there is really no one that wants to run - so up to people to run for it when ptl picking time comes around
20:25:13 <miguelgrinberg> stevebaker: if you want key/value pairs you can make your single-string tags be "key:value" or something like that
20:25:48 <zaneb> I'd be fine with what miguelgrinberg just said, I think
20:25:54 <jasond``> miguelgrinberg: but then a key could have multiple values
20:26:19 <miguelgrinberg> but based on the code that I reviewed you always compare both the key and the value together
20:26:27 <miguelgrinberg> so they really don't need to be separate
20:26:45 <zaneb> jasond``: doctor, doctor! It hurts when I do *this*!
20:26:52 <jasond``> yeah, i like simple tags
20:26:53 <tspatzier> jasond``: for most people a tag is really just a simple value, not key-value. so simple would be fine IMO
20:27:38 <asalkeld> and it does have a worring overlap to metadata as used in other projects
20:27:51 <asalkeld> (having key/values)
20:28:15 <miguelgrinberg> yeah, I think people seem to want to filter by tags, but not by metadata
20:30:19 <asalkeld> jasond``: thanks for being so flexible , things have changed a number of time on you
20:30:37 <asalkeld> i wasn't aware of nova's tags
20:30:51 <asalkeld> it's seems receint
20:31:05 <jasond``> it's no problem
20:31:26 <miguelgrinberg> jasond``: if you need to off-load part of this feel free to let me know, have a couple hours a day I can devote to things like this.
20:31:51 <jasond``> miguelgrinberg: thanks for the offer.  will let you know
20:31:51 <stevebaker> are nova tags simple strings or key/value like nova meta?
20:32:00 <zaneb> asalkeld: pretty sure we were handling Nova tags in Grizzly
20:32:13 <asalkeld> zaneb: that's nova metadata
20:32:20 <stevebaker> nova meta has existed forever
20:32:22 <asalkeld> nova now has actual tags
20:32:32 <asalkeld> list of strings
20:32:46 <stevebaker> yay, something to cargo-cult :)
20:32:54 <miguelgrinberg> the only thing nova tags can't do that I think might be useful for heat is to do negative filtering
20:33:12 <miguelgrinberg> i.e. give me all the stacks that do not have tag "hidden"
20:33:16 <asalkeld> stevebaker: we have an api wg that's job is to make sure api's are consistent :-O
20:33:19 <zaneb> stevebaker: fwiw tags in AWS are key/value
20:33:32 <miguelgrinberg> asalkeld: impossible job, BTW
20:33:48 <zaneb> don't know if keys have to be unique though. I suspect maybe not
20:34:20 <ryansb> the k/v in AWS is super handy for embedding a lot of informations
20:34:31 <asalkeld> #link https://review.openstack.org/#/q/topic:bp/tag-instances,n,z
20:34:47 <stevebaker> ryansb: it sure is
20:34:48 <ryansb> s/informations/information/
20:34:49 <miguelgrinberg> ryansb: that is the purpose of metadata
20:36:02 <stevebaker> miguelgrinberg: its impossible, but I'm sure the api wg can have a positive influence
20:36:06 <shardy> asalkeld: I think nova tags have been around for a while, ref bug #1097430
20:36:06 <openstack> bug 1097430 in heat grizzly "heat: doesn't use EC2 tags API" [Medium,Invalid] https://launchpad.net/bugs/1097430 - Assigned to Stephen Gran (sgran)
20:36:28 <asalkeld> shardy: that was only on ec2 api
20:36:31 <miguelgrinberg> stevebaker: we have some minor successes, yes. But it's really impossible to make everyone happy.
20:36:45 <shardy> asalkeld: ah ok :)
20:36:59 <asalkeld> and i don't think possible to filter on
20:37:11 <asalkeld> i could be wrong there tho'
20:37:23 <stevebaker> I recall someone writing tags-as-a-service so that any openstack resource can have key/value associated with it. Not sure what happened with that
20:37:35 <asalkeld> graffii
20:37:46 <shardy> lol, string-as-a-service ;)
20:37:52 <asalkeld> that is becoming a part of glance
20:37:59 <stevebaker> https://wiki.openstack.org/wiki/Graffiti
20:38:17 <zaneb> it landed in glance I believe
20:38:43 <asalkeld> stevebaker: it's more a repository of known working values for things like flavors
20:38:57 <stevebaker> oh, thats different
20:39:18 <asalkeld> so you can from a ui get a dropdown of actual values that might work
20:39:25 <asalkeld> imagine that
20:40:07 <stevebaker> yep
20:40:12 * stevebaker imagines
20:40:12 <shardy> so nova flavors, get stored in....glance?
20:40:38 <zaneb> shardy: not flavours, it's additional flavour specs
20:40:49 <asalkeld> no the values that might work when you go to create one
20:40:52 <tspatzier> yeah, it's for extra specs
20:41:00 <zaneb> like IntelObscureProcessorFeature=42
20:41:09 <shardy> zaneb: ah, the extra specs associated with images, I see, thanks
20:41:10 <asalkeld> ;)
20:41:13 <tspatzier> that's basically schema-less today but graffiti tries to restrict it
20:41:25 <tspatzier> or bring order to the system
20:41:38 <zaneb> we are so far off topic...
20:41:52 <tspatzier> what was the topic ? :-)
20:41:53 <asalkeld> all infavor of ending early?
20:42:00 <shardy> aye
20:42:02 <zaneb> tspatzier: lol
20:42:06 <stevebaker> errrp
20:42:14 <asalkeld> topic was open discussion
20:42:23 <tspatzier> that we had :-)
20:42:24 <asalkeld> so totally on topic ;)
20:42:37 <asalkeld> #endmeeting