[occi-wg] Nouns and Verbs

[eprparadocs at gmail.com]

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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg