Hi Dave,
I started out saying that I think this is a valuable change. That being
said, this is going to have implications for folks.
Sometimes concrete examples help. I did not have to look far.
Here is code from VOM. Yes, it is deprecated, but it is an example for
folks to follow.
/**
* A DB of all the interfaces, key on the name
*/
singular_db interface::m_db;
/**
* A DB of all the interfaces, key on VPP's handle
*/
std::map> interface::m_hdl_db;
If you look at tests, the name is a cached property and used as an identity
property
class VppInterface(metaclass=abc.ABCMeta):
@property
def name(self):
"""Name of the interface."""
return self._name
r = self.test.vapi.sw_interface_dump(sw_if_index=self.sw_if_index)
for intf in r:
if intf.sw_if_index == self.sw_if_index:
self._name = intf.interface_name
self._local_mac = intf.l2_address
self._dump = intf
break
else:
...
Matt has shown himself to be quite capable, and I'm sure he could easily
write a few extra lines of code to protect existing implementations in
less time than we have gone back and forth. I'm not tied to my suggestion
as the only way to address this, but rather to not invalidate assurances
that other folks rely upon. It has the side effect of making *other*
existing api's backward incompatible.
Ole's comments are aspirational at this point and I 100% agree that we
should strive for all access to be keyed/ filtered on sw_if_index, but
that is not the reality of the state of the api today.
Paul
On Fri, May 14, 2021 at 12:40 AM David Cornejo wrote:
> Ole,
> As you note, internally only the index is used. As far as I can tell, the
> ability to store the name in VPP is a convenience. The ability to change it
> shouldn't impact VPP but makes it much easier for those of us that have to
> deal with the human side of a product. The change to expose it is minor and
> it is very useful, so I hope that we will be allowed to commit it.
>
> Paul,
> The availability of an API doesn't mean that you have to use it or expose
> it to your users, so I don't see it as an issue. The idea of enabling or
> disabling every possible way to shoot your foot in VPP is daunting, and
> IMO, this is the job of the control plane. I could interpret Ole's comment
> in that light too.
>
> Nathan, thanks for the support!
>
> dave c
>
>
> On Wed, May 5, 2021 at 3:25 AM Nathan Skrzypczak <
> nathan.skrzypc...@gmail.com> wrote:
>
>> Hi Paul,
>>
>> From my understanding - but I might be mistaken here - I thought this was
>> about an explicit `rename` cli & api,
>> so foot shooting would be quite explicit from the user's perspective.
>> On ability to query/disable `show int` and equivalent apis would return
>> this modified state,
>> and not calling it would preserve the existing auto-generated names, so
>> existing users shouldn't be disrupted.
>>
>> Anyway, I'm pushing for this change, as this would push quite useful for
>> container interfaces in Calico/VPP :)
>>
>> Cheers
>> -Nathan
>>
>>
>> Le mer. 5 mai 2021 à 14:46, Paul Vinciguerra
>> a écrit :
>>
>>> Hi Matt, Ole, Nathan,
>>>
>>> Matt,
>>> I have no objection to the feature, I would just ask that you provide a
>>> startup.conf option to disable it and an api to query that state. The
>>> reason I say this is that there are configuration models that depend on the
>>> stability of the device name. Many yang models as an example, expect the
>>> interface name to be stable and take on the role of candidate
>>> configuration. The name filter functionality within the api may be
>>> invalidated once you execute your change.
>>>
>>> Ole,
>>> I agree with the factual aspect of your comment, but the interface index
>>> is not an idempotent property of the system, but dependent on the
>>> operational history of the device. We have interface instances which can
>>> be user specified, and apis that rely on the instance identifier
>>> irrespective of the format name. We also do not yet support all actions
>>> via interface index via the api. I'm just saying that this could break
>>> existing api clients' assumptions.
>>>
>>> Nathan,
>>> I too see the utility of the change, but also the disruptive nature. I
>>> just ask that we provide a means to keep folks from inadvertently shooting
>>> themselves in the foot, especially considering the diversity of use cases.
>>>
>>> Paul
>>>
>>> On Wed, May 5, 2021 at 6:15 AM Nathan Skrzypczak <
>>> nathan.skrzypc...@gmail.com> wrote:
>>>
Hi Matt, Hi Ole,
I think adding a cli & api call for renaming interfaces would be quite
useful.
I agree we shouldn't refer to interfaces by name in the API thought
(sw_if_index is definitely the way to go)
Several non-api use-cases would imho benefit from this. I can see
writing cli scripts without having to sed $interface_name all over the
place.
Also towards user friendliness, when exposing vppctl in a production
environment, `show
