Hi Justin, My vote would be to call the table InstanceProperties.
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. Dan -----Original Message----- From: "Justin Santa Barbara" <jus...@fathomdb.com> Sent: Monday, February 14, 2011 1:29pm To: openstack@lists.launchpad.net Subject: [Openstack] Metadata schema design _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
