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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
