fuel-dev team mailing list archive

[Vitaly Kramskikh <vkramskikh@xxxxxxxxxxxx>]

2014-04-07 13:05 GMT+04:00 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.
>

I think we can use advanced-networking blueprint, it already depends on
multiple-cluster-networks.

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

I hope it can be done on the network tab.

- CIDR can also be absent for particular network (e.g. for separate private
> network).
>

Yes, as well as some other parameters (gateway, exclude ranges, static
routes, etc.)

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

I think we can modify our default interface configuration algorithm not to
assign networks with these roles to nodes with specific roles.


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


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