Open Stack

Copying the list...

On Tue, May 15, 2012 at 10:26 AM, Doug Hellmann <doug.hellmann at dreamhost.com
> wrote:

>
>
> On Tue, May 15, 2012 at 8:21 AM, Julien Danjou <julien.danjou at enovance.com
> > wrote:
>
>> On Tue, May 15 2012, Loic Dachary wrote:
>>
>> > On 05/15/2012 12:05 PM, Julien Danjou wrote:
>> >>
>> >> OTOH I find the metadata proposal in another table too much
>> >> complicated. Why not storing what metadata in the meter.payload field
>> >> in the same table (e.g. as a JSON string)?
>> > I would be much simpler to store the metadata in the resource_id field
>> > which could be renamed into resource field.
>>
>> That'd be even more radical.
>>
>
> I like it because it would simplify the messaging. We can leave the
> storage optimization question to the daemon that stores the data.
>
>
>>
>> > Instead of resource_id=134123 we could have resource={ 'id': 134123,
>> > 'name': 'foobar', 'flavor': 'm1.small' etc.. } There would be no need
>> > for versioning, format, separate table, etc. etc. The only convention
>> > would be that it's a hash with at least one field : the id of the
>> > resource. The rest is metadata.
>> >
>> > It will use a lot of disk space with highly redundant information.
>>
>> Ok, so the current proposal is just early optimization, as I understood.
>>
>> If you want to optimize the storage, why not use resource_id as a
>> foreign key to the metatable table which would contains unique records
>> of metadata?
>>
>> That would allow to store identical metadata once (and therefore
>> optimize space) and will be much simpler. There would not be any need of
>> version, timestamp, or whatever on metadata.
>>
>> --
>> Julien Danjou
>> // eNovance                      http://enovance.com
>> // ✉ julien.danjou at enovance.com  ☎ +33 1 49 70 99 81
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120515/16d2c70b/attachment.html>