fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Vitaly, thanks a lot for putting this all together. It definitely needs
visual representation...

Can we use any existing design doc to put this stuff into or we need to
create new blueprint? Then we will be able to comment there.

Thanks,


On Mon, Apr 7, 2014 at 10:41 AM, Dmitriy Novakovskiy <
dnovakovskiy@xxxxxxxxxxxx> wrote:

> + 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
>>
>>
>
> --
> 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
>
>


-- 
Mike Scherbakov
#mihgen