Add free-form JSON field to resource table in heat database

This will add a column for free-form data to the resource table in the heat database. Arbitrary resource-specific data, such as SSH keys, can be stored in this field.

This was discussed in a Heat IRC meeting from 2013-06-19 (http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-06-19-20.00.log.html):

20:28:12 <stevebaker> this raises a good question, *where* can we store heat specific state for running resources?
20:28:23 <andrew_plunk> therve: are you guys talking about storing the lists of instances within a scalinggroup?
20:28:24 <therve> Ah :)
20:28:31 <zaneb> stevebaker: I think we need a new catch-all database column ;)
20:28:40 <zaneb> metadata is being seriously abused atm
20:28:43 <therve> andrew_plunk, Yeah, bug 1189278
20:28:44 <uvirtbot> Launchpad bug 1189278 in heat "Autoscaling max limit is capped by length of resource.nova_instance column" [High,Confirmed] https://launchpad.net/bugs/1189278
20:28:44 <shardy> andrew_plunk: yes, or more precisely how to stop doing it ;)
20:28:52 <asalkeld> runtime_data
20:29:10 <shardy> Yeah, we should stop abusing the metadata column really
20:29:20 <radix> could we create tables as needed for resources?
20:29:30 <stevebaker> maybe a key/value tags table
20:29:49 <asalkeld> radix, isn't that going to get messy
20:30:00 <shardy> for autoscaling groups, can't we just store the instance count, since the prefix is known and consistent?
20:30:09 * asalkeld scared of schema madness
20:30:28 <asalkeld> shardy, there might be holes?
20:30:33 <shardy> oh no, we've got the random suffix now
20:30:37 <radix> asalkeld: well... I donno. It depends how many resources we have
20:30:47 <shardy> asalkeld: would there?
20:30:56 <zaneb> shardy: the random suffix is irrelevant
20:30:59 <radix> asalkeld: I've worked with systems like that, it's not so bad if you have good processes around schema management
20:31:00 <asalkeld> instance failed?
20:31:04 <zaneb> currently we don't support holes
20:31:10 <zaneb> but we'll need to be able to eventually
20:31:16 <radix> the question is, do you need more structure than k/v, or is it okay by itself?
20:31:35 <stevebaker> the value can be json
20:31:36 <shardy> zaneb: Ok, may as well improve the status-quo then
20:31:48 <sdake> o/
20:31:51 <asalkeld> I am in favour of stack'like class that can have proper resource entries
20:31:52 <zaneb> stevebaker: +1
20:32:13 <andrew_plunk> asalkeld: +1
20:32:14 <zaneb> asalkeld: that also sounds like it would work
20:32:20 <jasond> anything to avoid db migration script version hell would be good
20:32:22 <randallburt> asalkeld: +1
20:32:35 <therve> stevebaker, It may be problematic if we want to have concurrency, no?
20:32:47 <therve> (Not that it's possible currently)
20:33:34 <therve> asalkeld, So I guess it links to the other subject we could talk: autoscale API
20:33:36 <stevebaker> therve: that would probably depend on how it is used