fuel-dev team mailing list archive

[Vitaly Kramskikh <vkramskikh@xxxxxxxxxxxx>]

Hi,

I want to describe an approach which we decided to use for our next-gen
network management. It will allow us to cover most of different network
configurations and will make our network configuration highly customizable.

Here is the list of entities that is used in this approach and relations
between them:

   1. Environment has a list of *networks*. User can add, delete and remove
   them, so any environment can have any amount of networks. User can also
   give them names like "Public" or "Private". These networks can be assigned
   assigned to interfaces of nodes on interface configuration screen. On UI
   management of these networks could be done on the network tab.
   2. Environment also has a list of *network roles*. Exact roles depend on
   release, network manager, storage options, etc. Examples: admin,
   management, storage-object, storage-rbd, gre-mesh, etc. These roles can be
   assigned to the networks previously defined by user. On UI it can be done
   via dragging and dropping roles on previously defined networks.
   3. Every defined network should also have a set of *network properties*:
   CIDR, VLAN tag or its absence, gateway, IP ranges to include/exclude, etc.
   There could be 2 options how to implement these properties depending on
   whether or not we implementing
multiple-cluster-networks<https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks>feature:
   1. If we aren't, these properties are just properties of networks. On UI
      they can be located near the corresponding network.
      2. If we are, then we should introduce *node group*. Node groups
      should contain properties for every defined network in an environment.
      Every environment should have one or more node groups. Node groups should
      also have names like "Rack #1", "Rack #2", etc. In this case UI becomes
      rather complex, I would propose the following: there should be a table in
      which columns are networks and rows are properties and node group name.
      User could add another node group, so another set of the fields would
      appear.
      As far as I understand, nodes can automatically detect which node
      group they belong to and configure network according to properties of
      chosen node group.
      4. We also need to have ability not to assign networks to interfaces
   on some nodes at all. I propose to add "available networks" area on the
   interface configuration screen so unnecessary networks can be dropped there.

If you have any questions or corrections on this or ideas about how it
should be implemented on UI, please provide them.

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.