On Tue, Jun 5, 2012 at 9:36 AM, Jason Kölker <jason@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~