We should check for kinds and actions when parsing and validating the
data, since POSTing an action is needed when we are triggering an action
on a resource.
According to OCCI specification, operations on paths that are not
resource instances or location paths, the path must end with "/". We
need to add the rule manually, since otherwise routes will strip out all
the slashes when generating the resources rules.
According to section 3.6.7, to comply with the RFC5785 we should
implement the query interface functionality under the authrority
path "/.well-known/org/ogf/occi/-/".
In section 3.6.5 it is said that a server must indicate the version that
it supports via the Server HTTP header. We have to advertise this even
when a fault is returned.
Everything is now under the same module (wsgi). Request
object includes methods for parsing a validating the
user input.
Fixed the compute method which was still using the old
body for creating the VM.
Added tests for parser.
- New parser and validator for create methods.
- Includes schemes in the mixin class to allow comparisons
- Fix scheme builder in helper (was missing # at the end)
- Update tests
According to the OCCI specification, the accept header MUST be handled
as follows:
- If Accept is empty, the returned content-type should be text/plain
- If Accept is "*/*", the returned content-type should be text/plain
- If Accept cannot be understood, a 406 error should be returned.
We are still missing the handling of the content-type header (that must
indicate the type of the data being sent, if any) that should be checked
against the available parsers (this is still missing).
We are not taking into account the application url (i.e. the
scheme://server:port/application) when we are cheking the responses.
This change sets an application URL that we should check for each of the
expected locations. Moreover, when we were creating the OCCI kinds for
each of the objects we were using absolute locations, so change to
relative ones.
This change creates a new request instead of modifying the original one
when it needs to be modified so as to access OpenStack. Before we were
modifying the original request (i.e. the path, body and content_type)
and this is wrong, since we cannot access those attributes after it has
been modified.
When an action is rendered when it is associated with an instance its
rendering is different than the action object. In the former case it
shall be rendered as a link, whereas in the latter it is rendered as a
category.
We should start handling the OpenStack Faults, in case they exist. The
easiest way is checking if the status code belongs to one of the HTTP
error codes. If this is the case, we convert it back to a webob
exception and raise it so that it is eventually handled in our WSGI
middleware.
Since the rendering of an object may vary depending on what is being
serialized (i.e. if it is only one object or a collection) it is better
to handle the serialization from outside the object.
Instead of constructing each of the responses in each of the tests,
start using a (poor man's) fake application that can be used by all the
controller tests.