On Tue, Jun 5, 2012 at 9:36 AM, Jason Kölker <ja...@koelker.net> wrote:
> On Tue, 2012-06-05 at 09:08 -0700, Dan Wendlandt wrote: > > > 1) making the tags attribute a simple dict. > > > > > > tags = { "key1" : "value1", "key2": "value2" } > > > > > > This is similar to what the nova API does for the "metadata" attribute > > of servers (which makes me wonder if we should be calling tags > > "metadata" to be consistent. > > > > > > 2) make a list of pairs: > > > > > > tags = [ { "association" : "key1", "tag" : "tag1" }, { "association": > > "key2", "tag" : "tag2" } ] > > I'd like to thow a 3rd option in the ring! > > tags = ['tag1', 'tag2'] > > After much discussion here, we came to the conclusion that we don't want > people to store data in quantum, but be able to key off a tag to lookup > data in their own datastore. > Adding netstack. I was thinking that there are really two different use cases here for tags: 1) a lightweight client with no database (i.e., a tenant writing a script against the quantum API) wants to store metadata about an object for later use. In this case, Quantum would need to be the authoritative store of data. 2) a heavyweight client with a database, who wants to associate an ID in their system (e.g., Nova) with an object in the Quantum API. In this case, Quantum is not the authoritative store of any data, it just stores a linkage between IDs. My thinking is that for #2, the user already has a database and thus can store the mapping between the Quantum entity UUID and their internal UUID in that database. So the need seems stronger for use case #1. In either case, my thinking was that having key-value pair format (to scope tags in a way that describes their use) would be valuable. Can you describe more behind the reasoning you all had in your discussions on the topic? Thanks, Dan > > Happy Hacking! > > 7-11 > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp