OpenNebula

Hi Simon,

Thanks for the patches I'll take a look at them ASAP (probably next week). I am interested in some of your comments to improve the Network stack, so let me summary so I can fill issues form them:

1. Better signature for class methods. I totally agree with this one, for example with IPv6 one should be able to request a MAC address and now it is not possible because of this, so probably pass a Lease to these functions is a good idea. We have #1958 open, and I think this can be developed in the context of that issue

1. Lock's in PoolSQL. For me this is a bug, if we add an ALLOCATE hook like (sleep 100) you'll hang the whole system. I think we can safety move the do_hooks out of the critical section. I'd say that the general idea with the pool lock is to be quick, have you noticed any other situation where the pool would be locked for a long time?.

These two are clear for me and will fill a couple of separate issues. Then we have:

1. accessing the request, I am not sure how to make this happening without a deep change on most of the functions to pass down the value. Any suggestions here?

1. RANGED as FIXED, this is something we've discussed in the past and decided not to go that way because of the storage request (e.g. for someone defining a B class...). I've several references of people using ranged...

Finally, I'd really like to hear any suggestion to improve and optimize the network module, where do you feel we could do it better....

Thanks again for your feedback and contributions! :)

Ruben S. Montero wrote:

1. accessing the request, I am not sure how to make this happening without a deep change on most of the functions to pass down the value. Any suggestions here?

We could look at having per-thread structure containing thread specific information ex.: http://www.boost.org/doc/libs/1_34_1/doc/html/boost/thread_specific_ptr.html

Then have a static method for retrieving / handling the per-thread information (retrieving the thread Request object, etc.)

That's similar to what log4cpp is using for its thread NDC context. On a side note we could use Log4cpp NDC when creating new threads to tags the user ID or the VM ID that thread is servicing (when syslog logging is used).

Simon

Hi

After an almost-complete implementation of this feature it seems that the overall design does not play well with it (i.e. chmod/ACL's/... access to a reserved leases should rely on the current auth mechanism, same for ownership).

We've come out with an intermediate solution. Access to the network is controlled with the current mechanisms. A lease can be USED (by a VM), FREE (can be automatically assigned to VMs), HOLD (lease is excluded from the IP range and cannot be assigned) and RESERVED (the leases will not be automatically assigned but can be manually requested).

Comments?

Initially the idea was to have the IP addresses reserved for usage by a given user. Much like the EC2 Elastic IP, the user can reserve IP and assign them to his VMs at will.

From the quota point of view, I would see the IP address being accounted as used by the user when it's reserved for its exclusive usage, independently if it's really in use or not (assigned to a VM or not).

In term of ownership of the VNET and right to use the lease, I was seeing the reserved lease as a second level of permission. You still need USE access to the VNET, but you are allowed to instantiate (and attach new NICs) with leases that are in RESERVED state only if the lease is reserved for your UID or GID.

Hi Simon,

That scenario can still be implemented with Ruben's proposal. Users will be able to assign RESERVED IPs at will.

If you need to separate which IPs can be used by each user, this can be done creating a different VNet for each one. E.g. Fixed VNet 0 [...1 - ...10] for user A, VNet 1 [...11 - ...15] for user B, etc.

Our main concern is the authorization mechanism. We don't feel comfortable having a specific authentication method for leases that doesn't support ACL, chmod, etc.

If we have to add owner/group to each lease, we should do a major redesign and maybe make them first-class citizens (PoolElement). We could also consider merging somehow the ranged and fixed networks, as you said. But this would be a big development effort and we don't consider it a high priority right now.

Best regards

Carlos Martín wrote:

If you need to separate which IPs can be used by each user, this can be done creating a different VNet for each one. E.g. Fixed VNet 0 [...1 - ...10] for user A, VNet 1 [...11 - ...15] for user B, etc.

The problem with that is I like to assign an entire subnet to OpenNebula, and then leave OpenNebula manage to subnet. With the scenario of having one VNet per user, I'd have to manage the available IP addresses externally from OpenNebula, or, have some dummy VNet that contains all my subnets, and when a user requests an elastic IP, mark the IP as held in the dummy VNet, and add the IP to the user's private VNet. When the user releases an elastic IP, remove the IP from his private VNet, and release the IP from the dummy VNet.

Our main concern is the authorization mechanism. We don't feel comfortable having a specific authentication method for leases that doesn't support ACL, chmod, etc.

If we have to add owner/group to each lease, we should do a major redesign and maybe make them first-class citizens (PoolElement). We could also consider merging somehow the ranged and fixed networks, as you said. But this would be a big development effort and we don't consider it a high priority right now.

Yes, I've though of this too, make IP address PoolElements, also merge the ranged and fixed networks. I'm interested and can help. I've dig down quite a bit in the OpenNebula network part and feel quite comfortable doing this on my spare time. Looking forward at discussing this with you and the conference.

Simon

Implementation Proposal
---------------------

Allow a LEASE to belong to both a VM and to a sub-VNET (hierarchical model). The sub-VNET would inherit all variables in the parent VNET and only be a container for IP address. This could allow users with the proper ACLs, or administrators to use the VNET for VM IPs, or to create a sub-VNET container with one more more IP addresses from the parent VNET.

It'd be nice to be able to disable "parent" VNET creation while allowing users to create "child" VNETs from an existing "parent" VNET. This seems work with existing ACLs methods as creating a "child" VNET could fall under the "USE" ACL for a VNET.