Hi all, Following the discussions at OGF30, we've refined the infrastructure document and would ask those interested to review and supply comments (I've attached the pdf). We can talk about it at confcall today. Andy ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
This is wonderfully short :-) alexis On Wed, Nov 3, 2010 at 9:47 AM, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi all, Following the discussions at OGF30, we've refined the infrastructure document and would ask those interested to review and supply comments (I've attached the pdf). We can talk about it at confcall today.
Andy
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi! Some notes/questions:) [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. [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. [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. [4] device type It might be useful to tell what type of device the storage represents, for instance hd, cdrom. Gyula ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. november 3. 10:47 Címzett: occi-wg@ogf.org Tárgy: [occi-wg] Infrastructure Document Hi all, Following the discussions at OGF30, we've refined the infrastructure document and would ask those interested to review and supply comments (I've attached the pdf). We can talk about it at confcall today. Andy
Inline... On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula <csom@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
Thanks for your response! We are using KVM (hw-assisted virt) hence we need to specify both boot and storage device type:) 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. Cheers, Gyula ________________________________________ Feladó: Ralf Nyren [ralf@nyren.net] Küldve: 2010. november 5. 14:46 Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Infrastructure Document Inline... On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula <csom@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
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@nyren.net] Küldve: 2010. november 5. 14:46 Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Infrastructure Document
Inline...
On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula <csom@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
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@nyren.net] Küldve: 2010. november 5. 14:46 Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Infrastructure Document
Inline...
On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula<csom@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Extensions would do the home work:) Meanwhile for the long term I would propose the following approach. Some programming languages provides a so called standard library besides the core. I think a similar solution could work here as well. That is typical extensions those applicable to many situations but not all, could be covered by OCCI: maybe not in the core but in a standard "library", maybe not in the next release but in a later one. --- Regarding DHCP... an occi.ipnetwork.dhcp could be the additional attribute. Like occi.ipnetwork.gateway it would hold an IP address, namely the address of the DHCP server. This would support only one goal: to tell the cloud that this address is reserved in the range: available addresses := occi.ipnetwork.address(es) - occi.ipnetwork.gateway - occi.ipnetwork.dhcp But maybe I missunderstood the role of occi.ipnetwork.address: - The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I thought it was something like this: 192.168.1.0/24 would define a C class subnet with 256 addresses. If this is the case than there is a need for a method to specify reserved addresses within the range. Gateway is a sample for such a reserved address but others could be there as wll (like DHCP if it is different from the gw). - The spec also says that multiplicity is 0..* so maybe one can define many addresses, but cannot specify a whole range. That is she should list avalailable addresses one by one. If this is the case then there is no need for the suggested attribute. One could simply exlude the reserved addresses from the range. So my question is: Could you please clarify the occi.ipnetwork.address semantics? in respect of (a) address ranges vs. individual addresses and (b) reserved addresses? Cheers, Gyula ________________________________________ Feladó: Ralf Nyren [ralf@nyren.net] Küldve: 2010. november 5. 17:14 Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Infrastructure Document
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@nyren.net] Küldve: 2010. november 5. 14:46 Címzett: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Infrastructure Document
Inline...
On Thu, 04 Nov 2010 22:57:31 +0100, Csom Gyula <csom@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
inline.. On Sat, 06 Nov 2010 08:23:13 +0100, Csom Gyula <csom@interface.hu> wrote:
Extensions would do the home work:) Meanwhile for the long term I would propose the following approach.
Some programming languages provides a so called standard library besides the core. I think a similar solution could work here as well. That is typical extensions those applicable to many situations but not all, could be covered by OCCI: maybe not in the core but in a standard "library", maybe not in the next release but in a later one.
Yes, good point. The plan is to have multiple extensions available for different use cases etc. However, this will have to wait to a future release of OCCI.
Regarding DHCP... an occi.ipnetwork.dhcp could be the additional attribute. Like occi.ipnetwork.gateway it would hold an IP address, namely the address of the DHCP server. This would support only one goal: to tell the cloud that this address is reserved in the range:
available addresses := occi.ipnetwork.address(es) - occi.ipnetwork.gateway - occi.ipnetwork.dhcp
But maybe I missunderstood the role of occi.ipnetwork.address:
- The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I thought it was something like this: 192.168.1.0/24 would define a C class subnet with 256 addresses. If this is the case than there is a need for a method to specify reserved addresses within the range. Gateway is a sample for such a reserved address but others could be there as wll (like DHCP if it is different from the gw).
- The spec also says that multiplicity is 0..* so maybe one can define many addresses, but cannot specify a whole range. That is she should list avalailable addresses one by one. If this is the case then there is no need for the suggested attribute. One could simply exlude the reserved addresses from the range.
So my question is: Could you please clarify the occi.ipnetwork.address semantics? in respect of (a) address ranges vs. individual addresses and (b) reserved addresses?
Ah, I see your issue now. Hmm... having multiple address ranges and just one gateway does not make sense. Each CIDR range need its own gateway to be useful. Andy, do you remember the reason behind this? Regarding reserved addresses I think this is something for the server side. If you need a dhcp server address just don't make that address available for allocation. I may be wrong but why would the client need to know about reserved addresses? regards, Ralf
Address ranges - good catch on this one Csom :-) - yes this should only be 0...1 On other aspects I would agree with what Ralf has said. Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, November 08, 2010 12:00 PM To: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] Infrastructure Document inline.. On Sat, 06 Nov 2010 08:23:13 +0100, Csom Gyula <csom@interface.hu> wrote:
Extensions would do the home work:) Meanwhile for the long term I would propose the following approach.
Some programming languages provides a so called standard library besides the core. I think a similar solution could work here as well. That is typical extensions those applicable to many situations but not all, could be covered by OCCI: maybe not in the core but in a standard "library", maybe not in the next release but in a later one.
Yes, good point. The plan is to have multiple extensions available for different use cases etc. However, this will have to wait to a future release of OCCI.
Regarding DHCP... an occi.ipnetwork.dhcp could be the additional attribute. Like occi.ipnetwork.gateway it would hold an IP address, namely the address of the DHCP server. This would support only one goal: to tell the cloud that this address is reserved in the range:
available addresses := occi.ipnetwork.address(es) - occi.ipnetwork.gateway - occi.ipnetwork.dhcp
But maybe I missunderstood the role of occi.ipnetwork.address:
- The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I thought it was something like this: 192.168.1.0/24 would define a C class subnet with 256 addresses. If this is the case than there is a need for a method to specify reserved addresses within the range. Gateway is a sample for such a reserved address but others could be there as wll (like DHCP if it is different from the gw).
- The spec also says that multiplicity is 0..* so maybe one can define many addresses, but cannot specify a whole range. That is she should list avalailable addresses one by one. If this is the case then there is no need for the suggested attribute. One could simply exlude the reserved addresses from the range.
So my question is: Could you please clarify the occi.ipnetwork.address semantics? in respect of (a) address ranges vs. individual addresses and (b) reserved addresses?
Ah, I see your issue now. Hmm... having multiple address ranges and just one gateway does not make sense. Each CIDR range need its own gateway to be useful. Andy, do you remember the reason behind this? Regarding reserved addresses I think this is something for the server side. If you need a dhcp server address just don't make that address available for allocation. I may be wrong but why would the client need to know about reserved addresses? regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Agree:) The simplest solution is what Ralf says: "just don't make that address available for allocation". My problem is the "how" when using the CIDR notation. To my understanding CIDR notation cannot specifiy exlcudes. Hence 192.168.0/24 or such address definition will include the DHCP address, and every other reserved addresses within that range as well. But again I could be wrong:) Gyula ________________________________________ Feladó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. november 8. 13:04 Címzett: Ralf Nyren; Csom Gyula; occi-wg@ogf.org Tárgy: RE: [occi-wg] Infrastructure Document Address ranges - good catch on this one Csom :-) - yes this should only be 0...1 On other aspects I would agree with what Ralf has said. Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, November 08, 2010 12:00 PM To: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] Infrastructure Document inline.. On Sat, 06 Nov 2010 08:23:13 +0100, Csom Gyula <csom@interface.hu> wrote:
Extensions would do the home work:) Meanwhile for the long term I would propose the following approach.
Some programming languages provides a so called standard library besides the core. I think a similar solution could work here as well. That is typical extensions those applicable to many situations but not all, could be covered by OCCI: maybe not in the core but in a standard "library", maybe not in the next release but in a later one.
Yes, good point. The plan is to have multiple extensions available for different use cases etc. However, this will have to wait to a future release of OCCI.
Regarding DHCP... an occi.ipnetwork.dhcp could be the additional attribute. Like occi.ipnetwork.gateway it would hold an IP address, namely the address of the DHCP server. This would support only one goal: to tell the cloud that this address is reserved in the range:
available addresses := occi.ipnetwork.address(es) - occi.ipnetwork.gateway - occi.ipnetwork.dhcp
But maybe I missunderstood the role of occi.ipnetwork.address:
- The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I thought it was something like this: 192.168.1.0/24 would define a C class subnet with 256 addresses. If this is the case than there is a need for a method to specify reserved addresses within the range. Gateway is a sample for such a reserved address but others could be there as wll (like DHCP if it is different from the gw).
- The spec also says that multiplicity is 0..* so maybe one can define many addresses, but cannot specify a whole range. That is she should list avalailable addresses one by one. If this is the case then there is no need for the suggested attribute. One could simply exlude the reserved addresses from the range.
So my question is: Could you please clarify the occi.ipnetwork.address semantics? in respect of (a) address ranges vs. individual addresses and (b) reserved addresses?
Ah, I see your issue now. Hmm... having multiple address ranges and just one gateway does not make sense. Each CIDR range need its own gateway to be useful. Andy, do you remember the reason behind this? Regarding reserved addresses I think this is something for the server side. If you need a dhcp server address just don't make that address available for allocation. I may be wrong but why would the client need to know about reserved addresses? regards, Ralf
The network range was put in place to support as part of a provisioning scheme used by some cloud providers. The range was intended to select a subset of a network segment, much like the client auto-configuring DHCP. The provider responds with one arbitrary IP address bounded by the range value. Under this scheme, if you needed a network interface with a different gateway address, you requested a different network Resource (NIC) . -gary On 11/8/2010 5:04 AM, Edmonds, AndrewX wrote:
Address ranges - good catch on this one Csom :-) - yes this should only be 0...1 On other aspects I would agree with what Ralf has said.
Andy
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, November 08, 2010 12:00 PM To: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] Infrastructure Document
inline..
On Sat, 06 Nov 2010 08:23:13 +0100, Csom Gyula<csom@interface.hu> wrote:
Extensions would do the home work:) Meanwhile for the long term I would propose the following approach.
Some programming languages provides a so called standard library besides the core. I think a similar solution could work here as well. That is typical extensions those applicable to many situations but not all, could be covered by OCCI: maybe not in the core but in a standard "library", maybe not in the next release but in a later one. Yes, good point. The plan is to have multiple extensions available for different use cases etc. However, this will have to wait to a future release of OCCI.
Regarding DHCP... an occi.ipnetwork.dhcp could be the additional attribute. Like occi.ipnetwork.gateway it would hold an IP address, namely the address of the DHCP server. This would support only one goal: to tell the cloud that this address is reserved in the range:
available addresses := occi.ipnetwork.address(es) - occi.ipnetwork.gateway - occi.ipnetwork.dhcp
But maybe I missunderstood the role of occi.ipnetwork.address:
- The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I thought it was something like this: 192.168.1.0/24 would define a C class subnet with 256 addresses. If this is the case than there is a need for a method to specify reserved addresses within the range. Gateway is a sample for such a reserved address but others could be there as wll (like DHCP if it is different from the gw).
- The spec also says that multiplicity is 0..* so maybe one can define many addresses, but cannot specify a whole range. That is she should list avalailable addresses one by one. If this is the case then there is no need for the suggested attribute. One could simply exlude the reserved addresses from the range.
So my question is: Could you please clarify the occi.ipnetwork.address semantics? in respect of (a) address ranges vs. individual addresses and (b) reserved addresses? Ah, I see your issue now. Hmm... having multiple address ranges and just one gateway does not make sense. Each CIDR range need its own gateway to be useful. Andy, do you remember the reason behind this?
Regarding reserved addresses I think this is something for the server side. If you need a dhcp server address just don't make that address available for allocation. I may be wrong but why would the client need to know about reserved addresses?
regards, Ralf
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)
Boot order dependencies of different Computes is quite different from single virtual machine boot priority (in terms of boot from CD, harddisk, etc). Service dependencies is an interesting issue though, but I am afraid that Action dependencies will have to wait until a future OCCI release :-D regards, Ralf On Sun, 07 Nov 2010 05:06:29 +0100, Michael Behrens <michael.behrens@r2ad.com> wrote:
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (6)
-
Alexis Richardson -
Csom Gyula -
Edmonds, AndrewX -
Gary Mazz -
Michael Behrens -
Ralf Nyren