fuel-dev team mailing list archive

[Aleksey Kasatkin <akasatkin@xxxxxxxxxxxx>]

Now we have three BPs which cover these things but not from UI side:
1. https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks
2. https://blueprints.launchpad.net/fuel/+spec/advanced-networking
3. https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks (can
be included to advanced-networks)

First one is in good progress so it seems that we can have Node Groups
faster than other stuff.
AFAIC, there is no sense to modify UI just for Node Groups than for other
stuff. Let's make one more BP and push all the UI changes there.
There are things to be clarified:
- As I remember we agreed to define network_roles-to-networks mapping
globally for the whole cluster, right? Is that mapping to be done using
separate tab or something?
- CIDR can also be absent for particular network (e.g. for separate private
network).
- We could have Network Roles subsets depended on node roles (and may be
other parameters) as well. It can be done automatically w/o user
involvement. Just show to user that he has particular set of Network Roles
for a particular Node (subset from all cluster-enabled Network Roles). Do
we need that?


Aleksey Kasatkin

S. Software Developer | Mirantis, Inc. | http://www.mirantis.com
cell: +380938330852 | skype: alexeyk_ru


On Mon, Apr 7, 2014 at 11:06 AM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx>wrote:

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