[occi-wg] Infrastructure Document

[Gary Mazz]

Hi,

Let me "but in" here for a second and share my approach to occi 
attribute partitioning, whether its a core element or an extension.

I like to use the VM as a rough tool to gauge capabilities. If the 
attribute pertains to a definition between "OCCI Resources", core 
functionality of the Resource or the Identification of the Resource it 
should be part of the infrastructure.

If the attribute pertains to organizing multiple VMs, the binding 
between the VMs and hosts, bindings between VMs and Operating systems or 
bindings between VMs and external systems, should be considered an "OCCI 
extension".

Dogmatically adhering  to this guideline could detrimentally affect the 
usability of OCCI. With the exception of some roles for collections,  we 
have executed this guideline concisely and still have a usable  design 
and specification.  We do know that extensions will be adopted for 
infrastructure and may impact the core model. How we frame and approach 
the definition of extensions can help us managing specification change.

I hope this guideline can help with this discussion.

cheers,
gary


On 11/5/2010 10:14 AM, Ralf Nyren wrote:
>> 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
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg