On Tue, 2012-06-05 at 09:52 -0700, Dan Wendlandt wrote:
> 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,
Its been so long, and so many changes ago, I can't remember the
specifics. Originally we were going to propose a metadata field which
would just be an object, but after a call I though we had come to the
conclusion that since quantum wasn't a datastore, that we would allow
users to just associate a list of string tags that would allow them to
either trigger actions on the tag or lookup additional metadata in their
own store.
Re option 1: should someone want to do that there should be nothing
preventing them from storing a json document as a tag. Dirty I know, but
I really think using quantum as a datastore for arbitrary data isn't a
good idea and it shouldn't be made easy to do so.
Happy Hacking!
7-11
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
