[occi-wg] Infrastructure Document

[Ralf Nyren]

> We are using KVM (hw-assisted virt) hence we need to specify both boot  
> and storage device type:)

We are also using KVM. I suggest you do same as us and just extend the  
existing Compute and Storage creating your own sub-types (as nicely  
supported by OCCI). Then you can add the extra attributes needed. Works  
nicely for our KVM setup.

> Regarding dhcp... it was a mistyping, sorry. What I really meant is  
> adding support for separate DHCP IP
> addresses. Rationale:
>
> * There could be situations when the gateway and the DHCP server are  
> different, that is use different
>    IP addresses. Meanwhile:
> * It seems to be a general feature that the cloud manages IP address  
> leasing - it must ensure that
>    the same IP is not used twice, hence in the above situation it must  
> know about the DHCP address.

Not sure I get it still, sorry :)  Could you explain which additional  
attributes you would want to add to the relevant types found in the  
infrastructure doc?

Btw, to support customer's leasing static IP-addresses I choose to create  
a custom IPAddress Resource for that purpose. Not sure if that help your  
case but it is an example of how you can solve different implementation  
specific use cases.

regards, Ralf


> Cheers,
> Gyula
> ________________________________________
> Feladó: Ralf Nyren [ralf at nyren.net]
> Küldve: 2010. november 5. 14:46
> Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg at ogf.org
> Tárgy: Re: [occi-wg] Infrastructure Document
>
> Inline...
>
> On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula <csom at interface.hu> wrote:
>
>> [1] boot
>> It might be useful to provide a boot param (0/1..*) in order to specify
>> the boot order. Something like
>> hd, cdrom, network, fd. Rationale: a system might provide
>> * prebuilt OS images - boot=hd,
>> * raw images with install CD - boot order = hd, cdrom
>> * computes booting/installed through network (like computes in a Rocks
>> Linux cluster) - boot order = hd, network
>>
>> If accepted this could/should be an attribute of the compute.
>
> Nice your brought this up. In the occi implementation I am involved in we
> add a boot-priority attribute in an extension to the Compute type.
>
> Boot priority is relevant when you do "full hw virtualisation" but if you
> virtualise using e.g. Solaris containers or similar boot-priority is
> really not applicable.
>
> So, for the generic case I think it should stay out of Compute and be  
> left
> as an extension. Any other opinions?
>
>> [2] dhcp
>> It might be useful if the IP mixin supported DHCP addresses ie. when
>> using dynamic IP allocation, and the gateway
>> and DHCP server IPs are different.
>
> Not sure what you mean here. The IPNetwork mix-in indeed support dynamic
> address allocation, e.g. dhcp.
>
>> [3] network type
>> The handling of public and private virtual networks might be different.
>> For instance while anti IP spoofing against public
>> IPs is a critical feature it is not relevant against private networks.
>> That is it might be useful to tag networks as either
>> public or private. Support could go to the IP mixin.
>
> I think this would suite better as a separate mixin which adds the
> public/private attribute. But I may be wrong.
>
>> [4] device type
>> It might be useful to tell what type of device the storage represents,
>> for instance hd, cdrom.
>
> Indeed, we do this in an extension of the Storage type in our
> implementation. If you model a block device (from the guest perspective)
> using the Storage type this is indeed needed. However if you represent an
> nfs export through the Storage type media type is not really relevant. So
> again, extension or separate mixin. Well, that's what I think anyway.
>
> regards, Ralf