Folks, in our implementation efforts of building an OCCI service frontend to libvirt, Sebastian and Ediz had a problem in supporting the "occi.compute.speed" attribute towards the libvirt backend -- there seems to be no way of setting this. Glancing at the libvirt docs, I couldn't find explicit support for this either. The question is: am I too stupid, and --- if not --- shall we change the multiplicity of "occi.compute.speed" from "1" to "0..1", since the speed might not be supported everywhere. Another thing that came up to my mind is: how shall we cope with this in the implementation via HTTP: if I POST a new compute, with a speed attribute set, and the backend builds upon libvirt (effectively not supporting it), can I give back a 20* status code and create _some_ resource (and corresponding VM), or is this a bad request? It also seems to me that this special case is something that makes resource templates important -- are we moving into the right direction here? Best, Alexander
Regarding libvirt you can set scheduling parameters which sort of emulate
the "speed" attribute. This is however backend dependent afaik. Have a
look at "virsh schedinfo".
Regarding attributes in Compute/Storage maybe we should change the lot of
them to 0..1? There are always some use-cases where something doesn't
apply. For example I do not currently allow users to set the cpu_cores
attribute, i.e. I use it as an immutable attribute only.
I guess this boils down to whether a POST missing a (according to OCCI
Infrastructure) required attribute should return OK or BAD Request. So far
I have taken the easy way out and return OK but I guess that is not fully
OCCI compliant or?
The Kind instance of Compute tells a client which attribute names are
present. Can it be allowed to reduce that set in an implementation? That
would effectively make all attribs 0..1 (or 0..whatever). Using this
approach the Infrastructure types can be used even if all attributes do
not apply. If we refuse this the only way would be to create a new custom
my_compute type directly from Resource. Not sure which solution has the
smallest impact on interoperability.
Andy has put in resource templates in Infra, they still need a bit of
polishing though. A template is just a Mixin instance btw.
regards, Ralf
On Thu, 11 Nov 2010 15:07:44 +0100,
Folks,
in our implementation efforts of building an OCCI service frontend to libvirt, Sebastian and Ediz had a problem in supporting the "occi.compute.speed" attribute towards the libvirt backend -- there seems to be no way of setting this.
Glancing at the libvirt docs, I couldn't find explicit support for this either. The question is: am I too stupid, and --- if not --- shall we change the multiplicity of "occi.compute.speed" from "1" to "0..1", since the speed might not be supported everywhere.
Another thing that came up to my mind is: how shall we cope with this in the implementation via HTTP: if I POST a new compute, with a speed attribute set, and the backend builds upon libvirt (effectively not supporting it), can I give back a 20* status code and create _some_ resource (and corresponding VM), or is this a bad request?
It also seems to me that this special case is something that makes resource templates important -- are we moving into the right direction here?
Best, Alexander _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (2)
-
alexander.papaspyrou@tu-dortmund.de
-
Ralf Nyren