All,
For me, the largest gap in the nouns, verbs and attributes is with regards
to networks. Here are some thoughts on capabilities which I believe we need
and options to implement these - feedback please!
Good work so far, thanks.
Basics
------
Networks will be a top level noun, along with servers and storage. Users
will link a server to a network to specify that the server is attached to
that network. There will be one special network presenting the public
internet, and users can create additional private networks for themselves.
Networks and storage can attach to networks remember. +1 for generic links.
Internet could be a well known UUID, but may be better not to specify as there are different "types" of internet (fast, slow, filtered, unfiltered, etc.). I know this was something I suggested myself but i'm not sure it pulls its weight... maybe it does... at least it should be optional (think offline setups).
The open questions are:
Public static IPs
-----------------
On all public clouds, customers can purchase static IPs (e.g. Amazon Elastic
IP) for uses where a constant server location is helpful (e.g. typical web
hosting).
We'll need a means for customers to create, list and destroy the public
static IPs which they own.
Two options:
a) Public static IPs are first-class nouns
b) They are listed inside the public internet network
I'd favour a), which is the case with most public clouds today.
Ok be sure to include IPv6 addresses though. Oh, and IPX/SPX since we've got an old novell server. And appletalk... you get the point. While we're there I guess we should make storage LUNs first class citizens too. How about compute peripherals?
Obviously I'm joking - IPs belong to networks and thus should hang off networks. Need a "type" attribute for ipv4, ipv6, ipx/spx, etc.
Active networks
---------------
At its most basic, a network should behave like a plain ethernet switch - it
provides no services at all, and simply connects all the servers which
attach to it. Servers are free to chose their own IP addresses, etc.
There are a number of active services which are possible on a network:
- Central DHCP server
- Bridge to a physical VLAN (e.g. containing physical dedicated servers in
colocation with the cloud provider)
- Load balancer between several web servers on a private network across to a
single IP on the public internet.
- etc.
Two options:
a) The network object itself can optionally provide these. They are
configured using attributes and verbs on the network.
b) There are separate 'appliance' objects which provide these services, and
are linked onto the network just as a server would be (e.g. a 'DHCP
server' appliance and or 'load balancer' appliance).
a) feels lighter-weight, but I suspect b) is more powerful. As such the
choice depends on how far OCCI wants to go down this route.
I'm happy with a combination... it makes sense to set "dhcp: true" on a network segment but it makes more sense to configure an advanced application level firewall (like a
Netscaler VPX) as a compute resource. Bonus points for being able to supply the device configuration via OCCI (*cough*XML*cough*). Firewall rules should probably be associated with a specific network connection, which may be non-trivial but increasingly relevant/important (devices should have no access by default when introduced and anything from pinholes to application level firewalls applied thereafter).
Linking to a network
--------------------
Finally, there are a few attributes which can specified on the link when a
server is linked to a network:
- The physical interface on the server (nic:0, nic:1, etc.)
Definitely, but this should make sense for the device - your eth0 is my en0 is his "Local Area Connection" and for network devices you have stuff like "1/1". We don't care - add it as an attribute and forget about it.
- Port firewalling rules (e.g. connect server to the internet network, but only
allow port 80 inbound)
We don't need to specify it, but we should consider it something someone will have to implement in due course.
- IP firewalling rules (e.g. connect server to the private network, and
allow it to communicate on 192.168.0.0-23 but no others)
Ditto. This configuration could be arbitrarily complex (specifying HTTP verbs, URL regexps, etc.) and is probably device dependent at least until standardised. Yet another place where embedding/linking arbitrary content types will be required.
- Local DHCP (e.g. the server operating system is internally configured
to DHCP. I am connecting it to the public internet, and want it to appear
with my assigned public static IP. Please send a DHCP response with that
specific IP address).
Hmm... sounds unnecessary. Once you've assigned an IP to a server if you want to make life easier by offering it over DHCP then go right ahead... I don't see the use case otherwise.
I think that all of these are best implemented as attributes on the link.
Yup, and more.
Sam