[occi-wg] Nouns and Verbs

[Sam Johnston]

On Fri, Apr 17, 2009 at 2:46 PM, <eprparadocs at gmail.com> wrote:


>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/5cd6d02d/attachment.html