Feature #3224

Authorize user/group to create restricted networks

Added by EOLE Team almost 7 years ago. Updated about 4 years ago.

Status:PendingStart date:10/03/2014
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Core & System
Target version:Release 5.6
Resolution: Pull request:

Description

Hello,

I would like to permit some groups to manage their internal network topology.

The use case is the following:

  1. the ONE admin create an internal bridge on the nodes usable by the user/group
  2. the ONE admin declare the bridge name as useable by the user/group
  3. the user/group has access to the Vnet creation dialog but with limited possibilities:
    • the network type must be forced and not settable (even displayed)
    • the bridge name must be forced and not settable (even displayed)
    • the VLAN may be force to yes, depending if the ONE admin share the bridge with other user/group
    • the VLAN_ID may be disabled and not displayed to let ONE manage it

Maybe something like a master network defined by the ONE admin and useable by the user/group, and the user/group can create some slave networks using the predefined fields of the master.

Regards.

History

#1 Updated by Carlos Martín over 6 years ago

Hi,

I think this was implemented by the VNet reservations:
http://docs.opennebula.org/4.12/user/virtual_resource_management/vgg.html#vnet-self-provisioning-reservations

Can we close this ticket?

#2 Updated by EOLE Team almost 6 years ago

Carlos Martín wrote:

Hi,

I think this was implemented by the VNet reservations:
http://docs.opennebula.org/4.12/user/virtual_resource_management/vgg.html#vnet-self-provisioning-reservations

Can we close this ticket?

Sorry, mail issues prevent me from being notified of your comment.

The original use case was the following:

  • we have a bridge called physical with a trunk on the physical switches to pass “official” VLAN to some VMs
  • we have a bridge called nebula where we plug virtual networks (networks not related to physical infrastructure)
  • we want some VDC admins to create their own virtual networks on bridge nebula without conflicting with others

To achieve this, we need:

  • to restrict the bridge name to nebula
  • to force the VLAN to yes since the bridge is shared between several groups
  • to disable the VLAN_ID to let OpenNebula manage it automatically (:start_vlan + :network_id)
  • to let the VDC admins manage their address range pool

The reservation requires the ONE admin to pre-create the networks and their address ranges and make reservation delegated to users which is great to give limited range of IP on the physical network to groups.

Thanks.

#3 Updated by Ruben S. Montero almost 5 years ago

  • Tracker changed from Request to Backlog
  • Category set to Core & System
  • Priority changed from Normal to High

#4 Updated by Kristian Feldsam over 4 years ago

Hello, I have related request https://forum.opennebula.org/t/allow-groupadmin-to-create-manage-own-802-1q-networks/3260

but instead of bridge, I like to preddefine physical device to use with 802.1q driver. I can't create vlans on bridge, because of not working gvrp dynamic vlan registration, which works only on physical device. My request is little bit simplier, I just need to predefine and force:

  • Network type to 802.1q
  • Physical device to custom, for ex. "team0"
  • Automatic VLAN_ID on

So basicly it is "template" which user picks and create netwrok from it.

No need to do something with address ranges...

#5 Updated by Kristian Feldsam over 4 years ago

Please add this to 5.4 roadmap, thank you.

#6 Updated by Ruben S. Montero over 4 years ago

  • Tracker changed from Backlog to Feature
  • Target version set to Release 5.4

#7 Updated by Bernhard J. M. Grün over 4 years ago

I would also benefit from that feature.

A perfect addition to this would be the possibility to use VXLAN (IDs) instead of the specialization to (only) VLANs.
I also assume that using VXLAN is easier to use for many installations because it is mostly independent of the switch configuration.

#8 Updated by kvaps kvaps about 4 years ago

I agree too, it is extremely necessary feature.

I think Network templates is very good idea.

#9 Updated by Ruben S. Montero about 4 years ago

  • Target version changed from Release 5.4 to Release 5.6

Also available in: Atom PDF