Networks: attributes and verbs
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! 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. 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. 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. 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.) - Port firewalling rules (e.g. connect server to the internet network, but only allow port 80 inbound) - 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) - 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). I think that all of these are best implemented as attributes on the link.
Richard Good email! For the benefit of people catching up ... can we treat this as "Proposed completion work on the Model"? Ignacio is leading the document creation process here - see his email about the wiki page. If there is stuff that is under the "Still under discussion" flag then mark it out as such. I don't see any but I may be wrong ;-) alexis On Wed, May 13, 2009 at 3:16 PM, Richard Davies <richard.davies@elastichosts.com> wrote:
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!
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.
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.
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.
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.) - Port firewalling rules (e.g. connect server to the internet network, but only allow port 80 inbound) - 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) - 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).
I think that all of these are best implemented as attributes on the link. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi, Yes, that is a good proposal for network management! I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "nound" would be the VM. Assumptions • Images: Images are pre-uploaded to the cloud and their UUIDs are known • Network: There are available networks for VMs to attach to. There are two kinds: public and private, and the UUIDs are known Cheers -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 13/05/2009, at 16:45, Alexis Richardson wrote:
Richard
Good email!
For the benefit of people catching up ... can we treat this as "Proposed completion work on the Model"? Ignacio is leading the document creation process here - see his email about the wiki page. If there is stuff that is under the "Still under discussion" flag then mark it out as such. I don't see any but I may be wrong ;-)
alexis
On Wed, May 13, 2009 at 3:16 PM, Richard Davies <richard.davies@elastichosts.com> wrote:
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!
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.
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.
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.
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.) - Port firewalling rules (e.g. connect server to the internet network, but only allow port 80 inbound) - 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) - 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).
I think that all of these are best implemented as attributes on the link. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "noun" would be the VM.
As we said on the call, I don't think the API is usable until it has servers, storage and network, so I think this can't be OCCI-API 1.0. You can certainly write the draft starting with the servers though, if it's helpful to get feedback on that part of the draft before writing the rest. Richard.
Richard, Our aim is to include the core functionality for server (VM) management with minimal network and storage management to have an usable API. Regards -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 13/05/2009, at 18:21, Richard Davies wrote:
I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "noun" would be the VM.
As we said on the call, I don't think the API is usable until it has servers, storage and network, so I think this can't be OCCI-API 1.0.
You can certainly write the draft starting with the servers though, if it's helpful to get feedback on that part of the draft before writing the rest.
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Wed, May 13, 2009 at 6:21 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "noun" would be the VM.
As we said on the call, I don't think the API is usable until it has servers, storage and network, so I think this can't be OCCI-API 1.0.
For many (perhaps yourselves included) it's not implementable until it's got billing... others might require performance monitoring and SLAs too. Everyone needs comute, network and storage though and OCCI 1.0 would be essentially useless without it. This is yet another reason to keep the core as compact as possible (ideally without reference to infrastructure at all) and do everything as modules - following the open source community's mantra: "release early, release often". I know this approach is trivial with AtomPub (it's what I've relied on to get so far so fast) but I'm not sure how easy it would be otherwise (namespaces really do help here). It's also a good reason not to try to go through the traditional process of getting a complete module in place and then blatting it out onto the wire... incremental, ongoing and ideally parallel development is going to work best for us. Sam
On Wed, May 13, 2009 at 4:53 PM, Ignacio Martin Llorente < llorente@dacya.ucm.es> wrote:
I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "nound" would be the VM.
But what if I want to use OCCI on a [virtual] network device or a storage system? You're making assumptions that deprive me of flexibility... all three nouns are first class citizens, yet none of them should be required (compute resources without storage or network, but probably not both, make perfect sense). OCCI Core should be exactly that... a skeleton. Sam
On May 13, 2009, at 12:56 PM, Sam Johnston wrote:
On Wed, May 13, 2009 at 4:53 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote:
I am preparing a proposal for OCCI-API 1.0 that I will distribute when ready. I would like the first specification to be a simplification of previous discussions on the list in order to achieve an agreement on the core functionality to be provided by the API. In particular, the only "nound" would be the VM.
But what if I want to use OCCI on a [virtual] network device or a storage system? You're making assumptions that deprive me of flexibility... all three nouns are first class citizens, yet none of them should be required (compute resources without storage or network, but probably not both, make perfect sense).
What Sam's saying seems sensible to me. At Sun, our core minimum set of nouns is VM, VM Template, Private network, public IP address, and "cluster", a simple grouping mechanism. I can't imagine constructing anything useful with much less than that. -Tim
On Wed, May 13, 2009 at 10:05 PM, Tim Bray <Tim.Bray@sun.com> wrote:
What Sam's saying seems sensible to me. At Sun, our core minimum set of nouns is VM, VM Template, Private network, public IP address, and "cluster", a simple grouping mechanism. I can't imagine constructing anything useful with much less than that. -Tim
Thanks Tim - let's see if you still think so when I explain further: - Your "VM" is our "server" resource - we don't care if you run VPSs, VMs or physical machines. - VM Templates are a WiP but basically a "server" that lacks a "start" button so far... rather something like a "clone" operation. They may have their own category. There's different types of templates - resources (e.g. Amazon's "small" and "large" instances), appliances (e.g. published AMIs), combinations of the two, and quite probably others I haven't thought of. I think this approach is flexible enough. - Your "Private network" is our "network"... which is itself basically a physical piece of wire/hub. I don't think IPs pull enough weight around here to become first class citizens (I just don't see the point) so they currently hang off networks. - Your "cluster" is our "category" - I very much prefer being as flexible as possible when it comes to taxonomies because this tends to be highly application-specific and varies from user to user. Atom is particularly good here as it allows us to have multiple vocabularies - such as "Operating System" or "Location" and as a significant bonus folksonomies (user-tagging) are thrown in for free. Questions like "give me all my windows boxes in california" become URLs like http://example.com/-/Windows/Californiaunder the current proposal. The last point is something that I've been meaning to bring up separately (and likely will soon) as the model Andy recently added uses more traditional and less flexible groups with a global namespace. For tiny installations that might be ok but anything bigger than that will obviously benefit from flexible organisation - it is after all just like an infinitely large library. In any case I hope you will agree that we can keep things simple and get by with three resources. Sam
Hello all, I would definitely like to keep an "infrastructure perspective" with regard to networking. I think that what the OCCI should expose is nothing more than I would get if I rented physical hardware: I, as the customer, get to define virtual networks and which machines I want to connect to these networks using which interfaces and which of these should have static IP addresses -- nothing else. This means, in particular, that I don't think that such additional services as (the configuration of) firewalls, DHCP servers, and the like should be included in the OCCI. If the customer requires these services, they should be implemented by VMs that are deployed on the customer's virtual network. In my view, letting the customer deploy appliances both simplifies the infrastructure from an implementation point of view *and* at the same time gives the customer greater flexibility. We previously discussed that a DHCP server can be configured in minute detail, and while not all customers will take full advantage of such configuration possibilities, allowing them to make such configurations makes things much easier for all parties involved. In such a scenario, a cloud provider could of course still define "Basic DHCP service" or "Basic Firewall" VMs with easy to use (web) interfaces so that customers that do not know iptables by heart can still be protected. Best regards, -- Lars On Wed, 13 May 2009, Richard Davies wrote:
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!
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.
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.
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.
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.) - Port firewalling rules (e.g. connect server to the internet network, but only allow port 80 inbound) - 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) - 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).
I think that all of these are best implemented as attributes on the link. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Lars Larsson wrote:
This means, in particular, that I don't think that such additional services as (the configuration of) firewalls, DHCP servers, and the like should be included in the OCCI. If the customer requires these services, they should be implemented by VMs that are deployed on the customer's virtual network.
This is an attractively elegant idea, but in many real clouds the minimum cost of a VM is quite high and thus it would be a waste to use a VM for something like DHCP. Also, if the cloud doesn't support DHCP, how can you create multiple VMs from a single disk image? You can't configure the image with a static IP address because then you'd have multiple VMs with the same address, and you can't configure the image with no address at all because then you wouldn't be able to log in to set the IP address. Wes Felter - http://felter.org/wesley/
On Wed, May 13, 2009 at 4:16 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
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<http://www.citrix.com/English/ps2/products/feature.asp?contentID=1689968>) 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
Linking to a network -------------------- Finally, there are a few attributes which can specified on the link when a server is linked to a network: ... - 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.
That one's actually pretty important to us at least: >50% of our servers work this way. The classic case is that a customer running a standard pre-installed operating system wants to use one of the public static IPs that they purchased. The high-hassle option for them is that they have to go into their OS and configure the static IP. We go with the other option - they can leave their OS configured to DHCP, and they can specify via the Web UI (or equivalently API) that the right static IP should be returned to that DHCP request, rather than just a random free one. Cheers, Richard.
On Wed, May 13, 2009 at 11:38 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
Linking to a network -------------------- Finally, there are a few attributes which can specified on the link when a server is linked to a network: ... - 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.
That one's actually pretty important to us at least: >50% of our servers work this way.
The classic case is that a customer running a standard pre-installed operating system wants to use one of the public static IPs that they purchased.
The high-hassle option for them is that they have to go into their OS and configure the static IP.
We go with the other option - they can leave their OS configured to DHCP, and they can specify via the Web UI (or equivalently API) that the right static IP should be returned to that DHCP request, rather than just a random free one.
So by "*once you've assigned an IP to a server*" I mean in OCCI, not in the server. If OCCI knows the server (presumably by MAC address) has a given IP and your DHCP server can talk to the OCCI backend (or vice versa) then there's no special case here... if you can support it then do and people won't have to (but can anyway) configure statics. Have I missed something? Sam
Linking to a network -------------------- Finally, there are a few attributes which can specified on the link when a server is linked to a network:
...
- 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.
That one's actually pretty important to us at least: >50% of our servers work this way.
The classic case is that a customer running a standard pre-installed operating system wants to use one of the public static IPs that they purchased.
The high-hassle option for them is that they have to go into their OS and configure the static IP.
We go with the other option - they can leave their OS configured to DHCP, and they can specify via the Web UI (or equivalently API) that the right static IP should be returned to that DHCP request, rather than just a random free one.
So by "once you've assigned an IP to a server" I mean in OCCI, not in the server. If OCCI knows the server (presumably by MAC address) has a given IP and your DHCP server can talk to the OCCI backend (or vice versa) then there's no special case here... if you can support it then do and people won't have to (but can anyway) configure statics. Have I missed something?
I think we're on the same page(?) The point I was trying to make was about the mechanism by which we assign IPs to a server in OCCI. I think that the assigned IP(s) should be specified an attribute of the link between the server and the network. A less detailed version would be like the last paragraph: just list the assigned IP(s) as attributes of the link. A more detailed version with better support for multiple IPs (e.g. for SSL web hosting) would be like my original e-mail in this thread and distinguish between two type of IP assignment: 1) A potentially large set of IPs which the server is permitted to use (i.e. all of the SSL web hosting IPs which they have purchased) 2) A single IP which is the primary IP to tell the server if it sends a DHCP request Cheers, Richard.
On Thu, May 14, 2009 at 12:43 AM, Richard Davies < richard.davies@elastichosts.com> wrote:
I think we're on the same page(?)
So do I.
The point I was trying to make was about the mechanism by which we assign IPs to a server in OCCI. I think that the assigned IP(s) should be specified an attribute of the link between the server and the network.
Well the process depends on the protocol but yes an IP needs to be assigned to a specific link between a server and a network. Another reason why addresses as first class citizens doesn't work (links having associations to resources starts to get fugly). Storage resources can have IPs by the way, as can network devices (but not sure it makes sense for network resources - will see that in due course). CIDR notation's another thing to think about at some point, especially for offering up large numbers of IPs - and yes I know it gets hairy fast. A less detailed version would be like the last paragraph: just list the
assigned IP(s) as attributes of the link.
That's what I would be expecting to see - one attribute for each IP.
A more detailed version with better support for multiple IPs (e.g. for SSL web hosting) would be like my original e-mail in this thread and distinguish between two type of IP assignment: 1) A potentially large set of IPs which the server is permitted to use (i.e. all of the SSL web hosting IPs which they have purchased) 2) A single IP which is the primary IP to tell the server if it sends a DHCP request
We need to be really flexible here - inflexibility will result in a> serious problems for users and/or b> seriously ugly workarounds. Addressing elements (XML parlance) hanging off resources and specifying the interface as an attribute may offer more flexibility than trying to do them as attributes on the links. Whatever gives the most flexibility... Sam
This is sounding awfully familiar, like DMTF's CIM model. How does this model handle channel bonding, cells, failover/failback, virtual circuits and traffic shaping ? -gary Sam Johnston wrote:
On Wed, May 13, 2009 at 4:16 PM, Richard Davies <richard.davies@elastichosts.com <mailto:richard.davies@elastichosts.com>> wrote:
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 <http://www.citrix.com/English/ps2/products/feature.asp?contentID=1689968>) 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
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Thu, May 14, 2009 at 6:34 AM, Gary Mazz <garymazzaferro@gmail.com> wrote:
This is sounding awfully familiar, like DMTF's CIM model.
The key difference is that instead of trying to do everything for everyone at one time we're starting with as little as possible and building on it based on demonstrated demand and sensibleness of request. Richard has said that 50% of his instances use pre-assigned DHCP leases - the idea makes a lot of sense and costs us nothing to facilitate. If he asked us later we'd only need add it to a registry. Use AtomPub and people who want CIM can still have it by embedding and/or linking<http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx#8573352>to it.
How does this model handle channel bonding, cells, failover/failback, virtual circuits and traffic shaping ?
These are all important questions when turning theory into reality and we have two options: 1. *Don't care.* Make a tight, inextensible API and let the clients pay for the limitations with extra code and workarounds, probably in the form of having to implement multiple APIs (e.g. OCCI + task specific). 2. *Play nice.* Be extensible by allowing foreign markup for specification of advanced features we don't care about. For example, in a request to create/update a network resource one could embed a descriptor standardised by SNIA. This doesn't hurt interop (at least not for the things we actually care about) because that information is still captured in the wrapper. I hope it's becoming clearer why AtomPub (and I say AtomPub so as not to confuse it with POX) is the best choice for this problem by a country mile. Sam
participants (8)
-
Alexis Richardson -
Gary Mazz -
Ignacio Martin Llorente -
Lars Larsson -
Richard Davies -
Sam Johnston -
Tim Bray -
Wes Felter