fuel-dev team mailing list archive

[Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx>]

+ Greg

---
Regards,
Dmitriy


On Sat, Apr 5, 2014 at 12:48 PM, Vitaly Kramskikh
<vkramskikh@xxxxxxxxxxxx>wrote:

> 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.
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>