Richard, All the attributes you can give to a non-virtualized network should be available to the private virtualized network. For instance I might want to use DHCP to allocate addresses on a VM attached to it. Others might need a fixed IP address. Chuck Richard Davies wrote:
network: *- start (aka up) *- stop (aka down) others?
Finally to networking!
There are two points here:
1) Customers need to be able to purchase static IP addresses on the public internet. All existing clouds provide this (Amazon Elastic IP, etc) in addition to dynamic IP, and it is essential for webhosting, etc.
So, we need a noun for a static IP address on the public internet which the customer owns.
When the customer configures a server, then can then bind this static IP address onto one of their server's NICs - the static IP itself doesn't need any verbs.
2) As I understand the 'network' objects which Sam was proposing, these were actually specifiers for different virtual ethernet networks into which servers' NICs can be 'plugged' - one would be the internet, one would be the a 'private network' between a customer's servers, etc.
The minimal implementation here is that the 'network' objects are simply an identifier with no verbs and no attributes. If you link several servers to the same 'network' then behaviour is as if they are all plugged into a plain ethernet switch. No additional services (such as DHCP) are provided by the network, so the servers need to either: (a) have static IP addresses configured in their operating systems (b) all invent their own private IPs, as Windows does (c) one of the servers can run a DHCP server tself for the rest (d) in each server's configuration, we can specify an IP address which the cloud manager can DHCP to that individual server
The current API design is heading a different route, in which the 'network' object provides services to the servers plugged into it (e.g. a central DHCP service in the API example, or bridging to a physical Cisco VLAN). I'm wary about this, since it brings a whole world of networking configuration into our cloud API (see 'man dhcpd.conf' to see how complicated full configuration of just a DHCP server can become!).
Perhaps all services (and associated attributes and verbs) on the virtual networks are best considered optional as extensions?
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg