[occi-wg] Query uniqueness

[Andre Merzky]

Hi Gary, Ralf,

On Mon, Apr 11, 2011 at 7:20 PM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> Hi Andre,
>
> You need to keep a registry of all Categories and Mixins on a per provider
> basis. ie a running occi interface.

Thanks for clarifying to both of you!


> Where we get into trouble is cross provider portability if a provider shares
> named spaces between consumers or if there is named space aliasing between
> provider named spaces.

Yeah, that is what I wondered about, really...  It remains to be seen
if that turns out to be a real problem I guess.


> Mixin and named space reconciliation between consumers and provider as well
> as reconciliation between providers will be an ongoing issue that occi does
> not address. That is why I'm posting these emails picking out details of
> inferred practices so a best practices guide can be compiled from the
> emails. Hopefully the guide will alert implementers to interoperability
> areas not solved with technologies.

I think there are quite a number of places in OCCI where not all
details are fully specified.  OTOH, I don't think it is a weakness of
OCCI, at all, as it helps to maintain OCCI's flexibility to cater to
different usage domains.  But I certainly  agree that it is important
to understand those issues, and to document them - otherwise interop
will be difficult.  So, I'd very much encourage you to publish best
practices - as wiki, or as OGF informational document, or in any other
forms.

For example, it might be worth to propose a naming scheme as best
practice which avoids collisions, like to encourage to use
'/provider-mixin/' as name (e.g. /gary-network/).  Or whatever you
guys consider appropriate :-)

Cheers, Andre.


> -gary
>
>
> On 4/11/2011 9:51 AM, Andre Merzky wrote:
>>
>> On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf at nyren.net>  wrote:
>>>
>>> The only rule is that two Categories cannot map to the same location. So
>>> you
>>> cannot have two different Categories mapping to e.g. /compute/.
>>>
>>> This means that with user-defined Mixins an OCCI service must refuse to
>>> create a Mixin for which the specified location path already is taken.
>>
>> which basically means that you need a registry of valid mixins?
>>
>> A.
>>
>>
>>
>>> /Ralf
>>>
>>> On Sun, 10 Apr 2011 14:34:12 -0600, Gary Mazz<garymazzaferro at gmail.com>
>>> wrote:
>>>
>>> Ok,
>>> In this example:
>>>
>>> Retrieving All Resource Instances Belonging to Mixin or Kind The HTTP
>>> verb
>>> GET must be used to
>>> retrieve all resource instances. The service provider MUST return a
>>> listing
>>> containing all resource
>>> instances which belong to the requested Mixin or Kind:
>>>>
>>>> GET /compute/ HTTP/1.1
>>>> [...]
>>>
>>> <  HTTP/1.1 200 OK
>>> <  [...]
>>> <
>>> <  X-OCCI-Location: http://example.com/vms/user1/vm1
>>> <  X-OCCI-Location: http://example.com/vms/user1/vm2
>>> <  X-OCCI-Location: http://example.com/vms/user2/vm1
>>>
>>> An OCCI implementation MUST support a filtering mechanism. If a HTTP
>>> Category is provided in the
>>> request the server MUST only return the resource instances belonging to
>>> the
>>> provided Kind or Mixin.
>>> The provided HTTP category definition SHOULD be different from the Kind
>>> or
>>> Mixin definition which
>>> defined the location path used in the request.
>>>
>>> If an OCCI Entity attribute (X-OCCI-Attribute) is provided in the request
>>> the server MUST only return
>>> the resource instances which have a matching attribute value.
>>>
>>> We see the the URI path '/compute/'. This name space confusion comes into
>>> the picture.. Is the URI path, indicating the 'location' specified by a
>>> category or is it the 'term' of the category? If it is the "location"
>>> there
>>> is the possibility of returning back multiple categories if the
>>> 'location'
>>> attribute is the same across multiple categories.  If it is the "term",
>>> there can be resources based on categories using the same 'term' but
>>> using
>>> differnt schemes.
>>>
>>> -gary
>>>
>>>
>>>
>>> On 4/10/2011 12:59 PM, Ralf Nyren wrote:
>>>
>>> please see below:
>>>
>>> On Sun, 10 Apr 2011 19:08:44 +0200, Gary Mazz wrote:
>>>
>>> Maybe I'm looking that the specifications too long, but it seems you can
>>> place more than one term in a query named space... for example, a query
>>> named space '/network/'  could refer to both the occi scheme and a
>>> private scheme.
>>>
>>> The namespace for different Category/Kind/Mixin instances is defined by
>>> the
>>> scheme, e.g. http://schemas.ogf.org/occi/core#. In this case we talk
>>> about
>>> the namespace for different types, i.e. Entity, Resource, Link, Compute,
>>> Storage, etc.
>>>
>>> We also talk about the namespace used for Entity IDs, i.e. the IDs of
>>> resource instances in a system. In the case of the HTTP Rendering this
>>> namespace is mapped to the URL namespace of HTTP.
>>>
>>> To further complicate things we have a mechanism of hooking a Kind/Mixin
>>> instances into this HTTP URL namespace by use of the "location"
>>> parameter.
>>> As you know a Kind or Mixin instance represents a collection of all
>>> resource
>>> instances (Entity sub-type instances) associated with the Kind or Mixin.
>>> This collection can be retrieved by querying the "location" URL.
>>>
>>> So to answer your question on the mapping of e.g. the "/network/" HTTP
>>> path
>>> it depends if you have a Kind/Mixin hooked into that path or not. If
>>> there
>>> is such a hook (i.e. you have a Category: ... location=/network/
>>> somewhere
>>> in the query interface) you will find the collection of the Kind/Mixin.
>>> However if you do not have a Kind/Mixin location mapped at /network/ you
>>> must follow the rules in section 3.4.2 "Operation on Paths in the
>>> Name-space".
>>>
>>> hmm... makes sense? :P
>>>
>>> There is no requirement that identical 'terms' used to describe a
>>> resource category to have a similar or the same functional
>>> characteristics as terms defined in the occi scheme.
>>>
>>> You are free to define e.g. Category: compute;
>>> scheme=http://provider.com/blah#  which is represents a coffee machine.
>>> It
>>> might be slightly misleading but as long as you use your own scheme
>>> namespace you can essentially do whatever you want.
>>>
>>> There is a mention of an "entity_type" to "Entity type uniquely
>>> identi%0Cfied by the Kind instance." However it doesn't say "entity_type"
>>> uniquely "identifies" the Kind Instance. The only way to uniquely
>>> identify a Kind is by scheme:term.  And this leads back to the issue
>>> with the query
>>>
>>> The Kind.entity_type is intended to contain a reference to the type (a
>>> class
>>> in most OO langs) which is identified by the Kind. Example (python-ish):
>>>
>>> # Compute is a class which inherits Resource which inherits Entity.
>>>
>>> # Thus is the Kind instance which identifies the Compute type (class)
>>> defined:
>>> compute_kind = Kind()
>>> compute_kind.term = "compute"
>>> compute_kind.scheme = "http://schemas.ogf.org/occi/core#"
>>> compute_kind.entity_type = Compute
>>>
>>> # If you want to create a new Compute instance you could do:
>>> class_ref = compute_kind.entity_type
>>> my_compute = class_ref()
>>>
>>> So Kind.entity_type is a reference to the type which the Kind instance
>>> identifies. This is of course not applicable to all programming languages
>>> but the idea is that given an instance of Kind you should be able to find
>>> out the Entity type it identifies.
>>>
>>> /Ralf
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>>
>>
>
>



-- 
So much time, so little to do...
[Garfield]