← Back to team overview

fuel-dev team mailing list archive

Re: Changing node's physical interfaces name

 

Hi Vyacheslav,
this is pretty unusual request to me.

The goal of Fuel is to hide underlying complexity of Linux and OpenStack,
and provide a user with a very friendly interface to install the cloud. It
has to give as much details as needed to tune it for the flexibility cloud
administrator wants. That's why, for example, we allow managing disk
allocations. At the same time, we hide unnecessary complexity of what is
going on behind the scenes - all raids, physical and logical volumes,
placement of boot partition on every device, etc.

Interfaces is purely internal thing, and exposed to the user in two ways:

   1. NIC names in the Fuel UI
   2. Physical NIC cards on the server

So, we name them as "eth0", "eth1", etc. on the UI as it is commonly
accepted, and network administrators usually know what it means on the back
of the server.
Let's clarify the use case  - if it's just matter of naming them in the UI
somehow like "mgmt", "public", etc. - and it would be convenient for the
user - then it probably makes sense, especially if server has same labels
on its NICs. In this case, internal naming can be the same still - eth0,
eth1, ..., and mapping would stored in Nailgun DB only.

Thanks,


On Thu, Oct 9, 2014 at 5:22 PM, Vyacheslav Valyavskiy <
vvalyavskiy@xxxxxxxxxxxx> wrote:

> Hi Igor,
>
> It's supposed that user can change interfaces names via UI or CLI and then
> he should get changed interfaces names on the provisioned node.
> We can add new field like 'changed name' to the NodeNICInterface object.
> Then we can continue to rely on interface names. And, then during the
> cobbler's profile creating we can base on 'NodeNICInterface.changed_
> name' field. If interface name was not changed, let's follow default value
> - 'NodeNICInterface.name'
>
> On Thu, Oct 9, 2014 at 4:36 PM, Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>
> wrote:
>
>> Hi there,
>>
>> Actually, I think it's a bad idea. As you already said, interface
>> names are come from nailgun agents and if we change them in database
>> (by means UI or CLI) the nodes will know nothing about these changes.
>>
>> This leads us to the fact, that we can loose a node if nailgun agent
>> doesn't send a mac address (which happens time to time), since we
>> can't rely on interface names anymore [1].
>>
>> If this topic was raised only for UI improvements, we can add a new
>> field - "label" - which will be shown instead of interface name. What
>> do you think? Will be it enough for customers?
>>
>> [1]:
>> https://github.com/stackforge/fuel-web/blob/stable/5.1/nailgun/nailgun/network/manager.py#L649
>>
>> Thanks,
>> Igor
>>
>> On Thu, Oct 9, 2014 at 2:34 PM, Vyacheslav Valyavskiy
>> <vvalyavskiy@xxxxxxxxxxxx> wrote:
>> > Hello everyone,
>> >
>> > Recently, we had request from our customer to provide feature to change
>> > node's interfaces names.
>> >
>> > I have researched it a little bit and it seems like there is no big
>> problem
>> > to implement it.
>> >
>> > I have hacked nailgun agent to send non-standard names to api and node
>> was
>> > provisioned successfully with
>> >
>> > custom interfaces names.
>> >
>> >
>> > This part of the code updates interfaces-networks assignment and we can
>> > update interfaces names here, too.
>> >
>> https://github.com/stackforge/fuel-web/blob/stable/5.1/nailgun/nailgun/network/manager.py#L586-L600
>> >
>> > Then, we can update interfaces names using cli immediately.
>> > ###############
>> > - assigned_networks: []
>> >   current_speed: 100
>> >   id: 10
>> >   mac: 52:bf:dd:5e:f3:13
>> >   max_speed: 100
>> >   name: eth0 # here we can replace iface name with something else
>> >   state: up
>> >   type: ether
>> > ###############
>> >
>> > Fuel UI. Here, type of the interface name field should be modified to be
>> > changeable. And, than, UI can generate proper
>> >
>> > api request.
>> >
>> > One thing here which make sense it's that bootstraped nodes send data
>> > request with real interfaces names from time to time. And, conflict may
>> be
>> > occurred. I didn't check it.
>> >
>> > What do think about this feature guys?
>> >
>> >
>> >
>> > --
>> > --
>> > With best regards,
>> > Viacheslav A. Valyavskiy
>> > Deployment engineer
>> > Mirantis, Inc. http://www.mirantis.com
>> >
>> > --
>> > 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
>> >
>>
>
>
>
> --
> --
> With best regards,
> Viacheslav A. Valyavskiy
> Deployment engineer
> Mirantis, Inc. http://www.mirantis.com
>
> --
> 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

Follow ups

References