thanks for the notes! Very helpful. I'm currently refactoring the test code. . .Many things on your list where on mine too, will update soon. Thanks again, -Thijs -----Ursprüngliche Nachricht----- Von: occi-wg-bounces@ogf.org im Auftrag von florian.feldhaus@tu-dortmund.de Gesendet: Mo 25.04.2011 15:43 An: occi-wg@ogf.org Betreff: [occi-wg] Cloud Plugfest summary 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