Open Stack

On 8/20/13 6:47 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>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.

I think it's an awesome idea to extract resource_metadata to the Trait
model (since we can't very well predict the needed columns with the nature
of notification payloads right now). It will allow us to search the
metadata without having to get a bunch of rows, pull the JSON for each,
search it, and so on.

I'm trying to get a better handle on the suggestion for immutable resource
metadata; some questions:

1. I build a server and it goes from a scheduling state to an active state
with ~8 or 9 steps in between each with different old/new tasks and
old/new states (assuming notify_on_task_state_change configured).
According to this definition of a resource, a server build should create
~10 different resources because the metadata changes from step to step,
correct?
2. The audit period in the metadata changes, does that warrant a resource
change (maybe that doesn't belong in resource_metadata from CM's
perspective)?
3. What are you thinking would be the best way to tie them all together
logically as states of a server, image, etc? I'm thinking we'd have to do
something like Sandy had mentioned, instance UUID, image UUID, etc.
4. I suppose the alternate question is: do we want to relate them? =]
5. If not, why?

-Thomas

>
>Best,
>-jay
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>