Open Stack

On 08/19/2013 08:27 AM, Sandy Walsh wrote:
>
>
> On 08/19/2013 05:08 AM, Julien Danjou wrote:
>> On Sun, Aug 18 2013, Jay Pipes wrote:
>>
>>> I'm proposing that in these cases, a *new* resource would be added to the
>>> resource table (and its ID inserted in meter) table with the new
>>> flavor/instance's metadata.
>>
>> Ah I see. Considering we're storing metadata as a serialized string
>> (whereas it's a dict), isn't there a chance we fail?
>> I'm not sure about the idempotence of the JSON serialization on dicts.
>
> Yeah, using a json blob should only be for immutable data.

Well, to be perfectly frank, fields that store JSON blobs in a RDBMS 
should be reserved for:

a) Data that never needs to be used in a search filter
b) Data that never needs to aggregated in a group by

If any part of a JSON blob doesn't meet the above, it should be removed 
from the JSON blob and put into its own fields in a table (or 
alternately, put into something like the Trait model)

 > I'm assuming
> metadata can change so we'd need idempotence. I could easily see two
> pipelines altering metadata fields. Last write wins. :(

I actually don't think metadata about resources does change, or at 
least, if it does change, then it describes a new resource.

As an example, if an instance resource is resized from an m1.tiny to an 
m2.xlarge, is it still really the same resource? I would say "no", it 
isn't...at least as far as CM should be concerned, since it consumes an 
entirely different pattern of metered usages now.

Best,
-jay