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 <pvi...@vinciconsulting.com> 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 interface` >> can be a bit hard to understand and could benefit from context-related >> names. >> >> Anyway, would definitely use such a feature :) >> >> Cheers >> -Nathan >> >> Le mer. 5 mai 2021 à 10:18, Ole Troan <otr...@employees.org> a écrit : >> >>> Matt, >>> >>> > Source file src/vnet/interface.c has a function >>> vnet_rename_interface(). It only appears to be called by the lisp plugin >>> currently. It would be handy to be able to rename a DPDK interface without >>> having to change startup.conf and restart VPP. I am wondering if I could do >>> that by adding a sw_interface_rename API and calling >>> vnet_rename_interface() in the handler function. Before I spend much time >>> working on that, I want to find out if there are any known issues which >>> would prevent that from working or if anyone has any objections to doing it. >>> >>> As a general principle, VPP doesn't have interface names. It has >>> interface indices and you can in your application choose the index to name >>> mapping yourself. >>> >>> Best regards, >>> Ole >>> >>> >>> >>> >> >> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19337): https://lists.fd.io/g/vpp-dev/message/19337 Mute This Topic: https://lists.fd.io/mt/82588728/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
