openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Tue, Feb 15, 2011 at 9:30 AM, Dan Prince <dan.prince@xxxxxxxxxxxxx> wrote:
> Hi Justin,
>
> My vote would be to call the table InstanceProperties.

My vote would be to name the model InstanceProperty and the underlying
table instance_properties.

> Regarding the ability of other services to use the table wouldn't it be cleaner if services had their own 'properties' tables (like the Glance registry service does).
>
> In other words services would have control over their own metadata tables. If the volume service needs metadata it should have its own table (or DB), etc.

Yes, I think that's what I prefer as well, and I think Justin had
suggested this as a possible option below.

Cheers!
jay

> Dan
>
> -----Original Message-----
> From: "Justin Santa Barbara" <justin@xxxxxxxxxxxx>
> Sent: Monday, February 14, 2011 1:29pm
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: [Openstack] Metadata schema design
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> I've coded support for metadata on instances.  This is part of the
> CloudServers API, and I needed it for my idea about metadata hints to the
> scheduler.
> https://code.launchpad.net/~justin-fathomdb/nova/justinsb-metadata/+merge/49490
>
> However, Jay Pipes has raised some (very valid) design questions on the
> schema.
>
> I called the table/entity 'Metadata', and it has two main attributes: 'key'
> and 'value'.  There's a foreign key to Instances, and long term I'd expect
> we'd add more foreign keys to other parent entities.  I expect only one of
> those parent foreign keys would be populated per row.
>
> Two questions:
>
>
>   1. Are those words too overloaded?  Jay suggested (Instance)Properties.
>    However, then the question arises about the 'core properties' (zone, image,
>   instance_type for a machine) and why they are not stored in the 'properties'
>   collection.  This is really metadata, and the CloudServers API calls it
>   metadata.  What do people think these should be named?  "Metadata"?
>    "Properties"? "Tags"?
>   2. I imagine that Volumes will also have metadata (long term, probably
>   everything will - networks, images, instance types, network objects).  So
>   should we have one entity/table or multiple entities (one per parent type)?
>    I like the idea of one entity, because I think it will yield better code
>   with less code duplication.  From a SQL viewpoint, one per parent entity is
>   probably more normal though.
>
>
> Justin
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>