[occi-wg] Infrastructure Document

[Michael Behrens]

Interesting that you brought up Solaris (zones).  On a system I worked 
on, we did had zone dependencies and did have to work out a way to 
control their boot order.  Ideally, it would be nice to have been able 
to specify network based service dependencies (i.e. start the web 
service after the database service is on line).

Ralf Nyren wrote:
> 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
>
>
>    


-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)