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.
Ok agreed but no point in differentiating... a network's a network's a network, whether it's completely virtual (e.g. create by a user who has attached some machines to it) or strapped to a physical segment and/or the Internet.
> 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.
Not necessarily - I would much rather see IP addresses advertised to the user in the "network" resource they want to connect to. The user can then specify the IP when POSTing (creating) the machine and it should then vanish from the available pool.
Presumably if they don't specify one then it will be allocated for them either manually (in which case it can be retrieved from the server resource - or more specifically the link between the server and the network) or automatically (via DHCP, in which case it may or may not be visible in the API).
> 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
Right, we're working at the physical layer (as previously agreed), except where we are forced to venture up into the data-link, network and/or transport layers (or else deliver an API that requires the support of another API for networking!)
> 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?
Actually that's not necessarily the case... the intention is just to strap machines together. If the provider chooses to advertise network(s) that they have preconfigured with fancy pants networking such as firewalls, load balances, ssl accelerators, etc. then so be it - and because of the security model (you only see what you have access to) they can do this on a per user basis.
The network resource would be a good starting point for another effort to define a cloud networking API (who?), just like the storage resource would be a good starting point for another effort to define a cloud storage API (e.g. SNIA).
Sam