[occi-wg] occi.compute.speed

Ralf Nyren ralf at nyren.net
Thu Nov 11 09:24:52 CST 2010


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, <alexander.papaspyrou at tu-dortmund.de>  
wrote:

> 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg



More information about the occi-wg mailing list