[occi-wg] Cloud Plugfest summary

[florian.feldhaus at tu-dortmund.de]

Hi everyone,

during the Cloud Plugfest a few issues came up which I'd like to summarize
here. Quite a few are related to the OCCI verification suite.

General discussion:
- Location:
* Currently there are 2 types of Locations. Once the location of Kinds,
Mixins and Actions and on the other hand the Location of resources. The
latter ones are returned to the OCCI client as absolute URI. This probably
comes from RFC 2616 Sec. 9.5 where HTTP POST is defined. Interestingly,
the creation of a entity should return a 201 (created) status code,
whereas in the OCCI HTTP rendering document always 200 (OK) is returned.
In the RFC for 201 an absolute URI for Location must be returned. This
behaviour should be adapted in the OCCI specs. This applies also to PUT
when a mixin is added or a resource is created. RFC 2616 is even more
specific here and says "If a new resource is created, the origin server
MUST inform the user agent via the 201 (Created) response"
* The Location header field only is used for POST during resource
creation. In all other cases, X-OCCI-Location is returned. At first this
was irritating for me, but after reading RFC 2616 I understood, that
Location can only return one entity and is recommended for POST during
creation of an entity. It may help to clarify this in the OCCI specs.
* As the entity Location returned by the OCCI implementation should be
absolute, it needs to contain the port of the OCCI implementation if the
port is not  default (e.g. 80). Mixing of HTTP and HTTPS is thus not a
good idea, as the namespaces would differ. On the other hand, one could
require, that the client keeps track of the ports and knows if a non
standard port is used. Currently this is an issue for the OCCI
verification suite as it uses the URI returned by POST to do a GET on a
newly created entity. This should be clarified in a best practice guide.

- Namespace:
* It might be a good idea to introduce a namespace discovery mechanism.
Maybe all categories (e.g. kinds/mixins) could have an additional namespace
attribute (e.g. containing "vms" for the compute kind or "disks" for the
storage kind). This becomes more complex if patterns like /vms/$username
are used. What do you think?

OCCI verification suite (see attached patch for all changes applied to
occi_test.py)
- all tests
* class= is missing for scheme in all Category headers. The definition of
Category (3.5.1 of HTTP Rendering document) requires class="action" |
"mixin" | "kind". A server could ommit checking the class parameter, but a
client shouldn't rely on the server being sloppy.
* check recent changes to attributes e.g. "occi.core.source" instead of
"source" (Link). A few last minute changes were made to the Core and
Infrastructure documents with regards to attribute names. These need to be
adopted.
- test_infrastructure_model_for_completness
* Categories of Actions shouldn't be part of GET /-/ (see OCCI HTTP
Rendering 3.4.1)
* Mixins shouldn't be related to links (see OCCI Core 4.4.3 Table 3) - so
the ipnetworking mixing shouldn't have
rel='http://schemas.ogf.org/occi/core#link' and instead rel=''
- test_filter
* heads['Content-Type'] = 'text/occi' is missing, this is a problem if the
test is run standalone
* delete -> location needs to include port? See comment above
- test_links
* source and target must be replaced with occi.core.source and
occi.core.target for Link: link['X-OCCI-Attribute'] = 'occi.core.source='
+ compute_loc + ',occi.core.target=' + network_loc
- test_actions
* after action has been triggered, it should be checked if the status of
the compute entity has been changed
- test_create_kinds
* must be occi.compute.hostname="foo" (with quotes) instead of
occi.compute.hostname=foo (see OCCI HTTP rendering 3.5.4)

OCCI HTTP Rendering document
- Section 3.4.4.: "Triggering an Action on a resource instance": Category
for Action must be "Category: stop; scheme="[...]"; class="action";"
instead of "Category: compute; scheme="[...]"; class="action";" (see OCCI
Infrastructure 3.1 Table 3)
- Section 3.4.1.: Adding a Mixin definition: Must be
rel="http:/example.com/occi/something_else#mixin;" with quotes

OCCI Core document
- 4.4.3 TYPO: "Mixin might by applicable" ->" Mixin might be applicable"

Cheers,

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_occi.patch
Type: application/octet-stream
Size: 8940 bytes
Desc: test_occi.patch
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20110425/c6afab66/attachment.obj