[vpp-dev] vpp api versioning
Hello folks, According to [0] it should be possible to add breaking changes to vpp api with incrementing the major version of the api. There's one issue in the LCP api - a C++ keyword "namespace" is used there and I want to change it to "netns" and increase a major version. But make checkstyle-api still fails. Any ideas? Of course, I can add new methods _v2 and deprecate the older ones. But it'd lead to code duplication and still I'd need to wait at least 2 releases. [0] https://wiki.fd.io/view/VPP/API_Versioning -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21662): https://lists.fd.io/g/vpp-dev/message/21662 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Stanislav, The api is marked as “Production” so the behavior of checkstyle is there to protect the users (as for the duplication - it is a choice to do it once in VPP or in each and every downstream consumer). As for the pure code exercise - I just did it for the sake of a test, took a grand total of 15 minutes to add the new message versions. Hardly a massive deal. (We could probably improve tooling on the lifecycle management of these, though) That said - for this specific case - is the presence of the “namespace” member in a structure within the api a showstopper for you - that is, does it cause a compilation failure of some sort ? If so - one option is to mark the APIs as experimental and then change it in-place. It is up to component owners to decide the policy. --a > On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: > > > Hello folks, > > According to [0] it should be possible to add breaking changes to vpp api > with incrementing the major version of the api. There's one issue in the LCP > api - a C++ keyword "namespace" is used there and I want to change it to > "netns" and increase a major version. But make checkstyle-api still fails. > Any ideas? > > Of course, I can add new methods _v2 and deprecate the older ones. But it'd > lead to code duplication and still I'd need to wait at least 2 releases. > > [0] https://wiki.fd.io/view/VPP/API_Versioning > > -- > Best regards > Stanislav Zaikin > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21664): https://lists.fd.io/g/vpp-dev/message/21664 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hoi, Currently, linux-cp API doesn't seem to work, at least in Python and GoVPP (see previous threads on this mailinglist with bugreports), lcp_itf_pair_add_del_v2() eventually succeeds but throws an error to the caller. This snippet: r = vpp.api.create_loopback() print(r) host_if_name = "loop%d" % r.sw_if_index t=0 ## LCP_API_ITF_HOST_TAP n="dataplane" r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, namespace=n) print(r) Shows as log, the following: create_loopback_reply(_0=758, context=3, retval=0, sw_if_index=10) ### hangs for a few seconds ... Traceback (most recent call last): File "./v3.py", line 35, in r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, namespace=n) File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 121, in __call__ return self._func(**kwargs) File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 495, in f return self._call_vpp(i, msg, multipart, **kwargs) File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 757, in _call_vpp raise VPPIOError(2, 'VPP API client: read failed') vpp_papi.vpp_papi.VPPIOError: [Errno 2] VPP API client: read failed Even though the LCP was created: DBGvpp# show lcp lcp default netns dataplane lcp lcp-auto-subint off lcp lcp-sync on itf-pair: [0] GigabitEthernet3/0/0 tap1 e0 29 type tap netns dataplane itf-pair: [1] GigabitEthernet3/0/0.101 tap1.101 servers 33 type tap netns dataplane itf-pair: [2] GigabitEthernet3/0/0.179 tap1.179 ixp 32 type tap netns dataplane itf-pair: [3] loop0 tap6 loop10 34 type tap netns dataplane Matt may have more insights (and Ole at some point tried to help me fix it, also), but if the API is actually busted, I am personally comfortable changing it in-place from s/namespace/netns/ rather than adding a _v3; but that's just one user's opinion. I would defer to +Matthew Smith as the maintainer of the plugin. groet, Pim On Fri, Jul 15, 2022 at 11:14 AM Andrew Yourtchenko wrote: > Hi Stanislav, > > The api is marked as “Production” so the behavior of checkstyle is there > to protect the users (as for the duplication - it is a choice to do it once > in VPP or in each and every downstream consumer). As for the pure code > exercise - I just did it for the sake of a test, took a grand total of 15 > minutes to add the new message versions. Hardly a massive deal. (We could > probably improve tooling on the lifecycle management of these, though) > > That said - for this specific case - is the presence of the “namespace” > member in a structure within the api a showstopper for you - that is, does > it cause a compilation failure of some sort ? If so - one option is to > mark the APIs as experimental and then change it in-place. It is up to > component owners to decide the policy. > > --a > > On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: > > > Hello folks, > > According to [0] it should be possible to add breaking changes to vpp api > with incrementing the major version of the api. There's one issue in the > LCP api - a C++ keyword "namespace" is used there and I want to change it > to "netns" and increase a major version. But make checkstyle-api still > fails. Any ideas? > > Of course, I can add new methods _v2 and deprecate the older ones. But > it'd lead to code duplication and still I'd need to wait at least 2 > releases. > > [0] https://wiki.fd.io/view/VPP/API_Versioning > > -- > Best regards > Stanislav Zaikin > > > > > > > -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21665): https://lists.fd.io/g/vpp-dev/message/21665 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Andrew, Thanks for the explanation. I'll try to reach maintainers of the lcp plugin and convince them :) Yes, I'm working on an agent for managing vpp through binary api and it's written in C++ - so it breaks the compilation. I have a patch in my local repo for that, but now I'm trying to merge all my patches upstream. On Fri, 15 Jul 2022 at 11:14, Andrew Yourtchenko wrote: > Hi Stanislav, > > The api is marked as “Production” so the behavior of checkstyle is there > to protect the users (as for the duplication - it is a choice to do it once > in VPP or in each and every downstream consumer). As for the pure code > exercise - I just did it for the sake of a test, took a grand total of 15 > minutes to add the new message versions. Hardly a massive deal. (We could > probably improve tooling on the lifecycle management of these, though) > > That said - for this specific case - is the presence of the “namespace” > member in a structure within the api a showstopper for you - that is, does > it cause a compilation failure of some sort ? If so - one option is to > mark the APIs as experimental and then change it in-place. It is up to > component owners to decide the policy. > > --a > > On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: > > > Hello folks, > > According to [0] it should be possible to add breaking changes to vpp api > with incrementing the major version of the api. There's one issue in the > LCP api - a C++ keyword "namespace" is used there and I want to change it > to "netns" and increase a major version. But make checkstyle-api still > fails. Any ideas? > > Of course, I can add new methods _v2 and deprecate the older ones. But > it'd lead to code duplication and still I'd need to wait at least 2 > releases. > > [0] https://wiki.fd.io/view/VPP/API_Versioning > > -- > Best regards > Stanislav Zaikin > > > > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21666): https://lists.fd.io/g/vpp-dev/message/21666 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Pim, There's also lcp_default_ns_get broken. I fixed that locally and want to send the patch. Can take a look at lcp_itf_pair_add_del_v2 as well. On Fri, 15 Jul 2022 at 12:57, Pim van Pelt wrote: > Hoi, > > Currently, linux-cp API doesn't seem to work, at least in Python and GoVPP > (see previous threads on this mailinglist with bugreports), > lcp_itf_pair_add_del_v2() eventually succeeds but throws an error to the > caller. This snippet: > > r = vpp.api.create_loopback() > > print(r) > > > host_if_name = "loop%d" % r.sw_if_index > > t=0 ## LCP_API_ITF_HOST_TAP > > n="dataplane" > > r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, > sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, > namespace=n) > > print(r) > > Shows as log, the following: > > create_loopback_reply(_0=758, context=3, retval=0, sw_if_index=10) > ### hangs for a few seconds ... > Traceback (most recent call last): > File "./v3.py", line 35, in > r = vpp.api.lcp_itf_pair_add_del_v2(is_add=True, > sw_if_index=r.sw_if_index, host_if_name=host_if_name, host_if_type=t, > namespace=n) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 121, in > __call__ > return self._func(**kwargs) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 495, in > f > return self._call_vpp(i, msg, multipart, **kwargs) > File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 757, in > _call_vpp > raise VPPIOError(2, 'VPP API client: read failed') > vpp_papi.vpp_papi.VPPIOError: [Errno 2] VPP API client: read failed > > Even though the LCP was created: > > DBGvpp# show lcp > > lcp default netns dataplane > > lcp lcp-auto-subint off > > lcp lcp-sync on > > itf-pair: [0] GigabitEthernet3/0/0 tap1 e0 29 type tap netns dataplane > > itf-pair: [1] GigabitEthernet3/0/0.101 tap1.101 servers 33 type tap netns > dataplane > > itf-pair: [2] GigabitEthernet3/0/0.179 tap1.179 ixp 32 type tap netns > dataplane > > itf-pair: [3] loop0 tap6 loop10 34 type tap netns dataplane > > Matt may have more insights (and Ole at some point tried to help me fix > it, also), but if the API is actually busted, I am personally comfortable > changing it in-place from s/namespace/netns/ rather than adding a _v3; but > that's just one user's opinion. I would defer to +Matthew Smith > as the maintainer of the plugin. > > groet, > Pim > > On Fri, Jul 15, 2022 at 11:14 AM Andrew Yourtchenko > wrote: > >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there >> to protect the users (as for the duplication - it is a choice to do it once >> in VPP or in each and every downstream consumer). As for the pure code >> exercise - I just did it for the sake of a test, took a grand total of 15 >> minutes to add the new message versions. Hardly a massive deal. (We could >> probably improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to >> mark the APIs as experimental and then change it in-place. It is up to >> component owners to decide the policy. >> >> --a >> >> On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: >> >> >> Hello folks, >> >> According to [0] it should be possible to add breaking changes to vpp api >> with incrementing the major version of the api. There's one issue in the >> LCP api - a C++ keyword "namespace" is used there and I want to change it >> to "netns" and increase a major version. But make checkstyle-api still >> fails. Any ideas? >> >> Of course, I can add new methods _v2 and deprecate the older ones. But >> it'd lead to code duplication and still I'd need to wait at least 2 >> releases. >> >> [0] https://wiki.fd.io/view/VPP/API_Versioning >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> >> >> >> > > -- > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/ > > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21667): https://lists.fd.io/g/vpp-dev/message/21667 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Andrew, Neale and I are the maintainers of linux-cp. I am ok with changing it in place because the use of "namespace" is preventing Stanislav from even being able to compile his code. When you say "mark the APIs as experimental" are you talking about putting "state: experimental" in the FEATURE.yaml file or something else? If you're talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml already lists the state as experimental. Maybe the formatting of the file is bad? Thanks, -Matt On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko wrote: > Hi Stanislav, > > The api is marked as “Production” so the behavior of checkstyle is there > to protect the users (as for the duplication - it is a choice to do it once > in VPP or in each and every downstream consumer). As for the pure code > exercise - I just did it for the sake of a test, took a grand total of 15 > minutes to add the new message versions. Hardly a massive deal. (We could > probably improve tooling on the lifecycle management of these, though) > > That said - for this specific case - is the presence of the “namespace” > member in a structure within the api a showstopper for you - that is, does > it cause a compilation failure of some sort ? If so - one option is to > mark the APIs as experimental and then change it in-place. It is up to > component owners to decide the policy. > > --a > > On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: > > > Hello folks, > > According to [0] it should be possible to add breaking changes to vpp api > with incrementing the major version of the api. There's one issue in the > LCP api - a C++ keyword "namespace" is used there and I want to change it > to "netns" and increase a major version. But make checkstyle-api still > fails. Any ideas? > > Of course, I can add new methods _v2 and deprecate the older ones. But > it'd lead to code duplication and still I'd need to wait at least 2 > releases. > > [0] https://wiki.fd.io/view/VPP/API_Versioning > > -- > Best regards > Stanislav Zaikin > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21668): https://lists.fd.io/g/vpp-dev/message/21668 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hi Matt, Oh right, so especially given the plugin is marked experimental, in-place approach would make a lot of sense… By saying “experimental” I was thinking of marking the API messages as “in-progress” [0] - which would then exempt them from the change enforcements and allow further iterations on the api unconstrained. --a [0] https://wiki.fd.io/view/VPP/ApiChangeProcess > On 15 Jul 2022, at 17:41, Matthew Smith via lists.fd.io > wrote: > > > Hi Andrew, > > Neale and I are the maintainers of linux-cp. I am ok with changing it in > place because the use of "namespace" is preventing Stanislav from even being > able to compile his code. > > When you say "mark the APIs as experimental" are you talking about putting > "state: experimental" in the FEATURE.yaml file or something else? If you're > talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml > already lists the state as experimental. Maybe the formatting of the file is > bad? > > Thanks, > -Matt > > >> On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko >> wrote: >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there to >> protect the users (as for the duplication - it is a choice to do it once in >> VPP or in each and every downstream consumer). As for the pure code exercise >> - I just did it for the sake of a test, took a grand total of 15 minutes to >> add the new message versions. Hardly a massive deal. (We could probably >> improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to mark >> the APIs as experimental and then change it in-place. It is up to component >> owners to decide the policy. >> >> --a >> On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: >>> >>> Hello folks, >>> >>> According to [0] it should be possible to add breaking changes to vpp api >>> with incrementing the major version of the api. There's one issue in the >>> LCP api - a C++ keyword "namespace" is used there and I want to change it >>> to "netns" and increase a major version. But make checkstyle-api still >>> fails. Any ideas? >>> >>> Of course, I can add new methods _v2 and deprecate the older ones. But it'd >>> lead to code duplication and still I'd need to wait at least 2 releases. >>> >>> [0] https://wiki.fd.io/view/VPP/API_Versioning >>> >>> -- >>> Best regards >>> Stanislav Zaikin >>> >>> >>> >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21673): https://lists.fd.io/g/vpp-dev/message/21673 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp api versioning
Hello folks, I've just sent 3 patches addressing issues in LCP [0] [1] [2]. First one for marking APIs in progress. 2nd only for s/namespace/netns/g. 3rd fixes endian issues in different methods. One thing I can't understand - if the "autoendian" keyword is specified for API type - I should use macros end with _END, right? It worked for lcp_itf_pair_add_del_v2 and lcp_default_ns_get, but for some reason it doesn't work for lcp_itf_pair_details (though the type is also marked with "autoendian"). Any inputs here much appreciated. Thanks guys [0] - https://gerrit.fd.io/r/c/vpp/+/36708 [1] - https://gerrit.fd.io/r/c/vpp/+/36709 [2] - https://gerrit.fd.io/r/c/vpp/+/36710 On Fri, 15 Jul 2022 at 17:41, Matthew Smith via lists.fd.io wrote: > Hi Andrew, > > Neale and I are the maintainers of linux-cp. I am ok with changing it in > place because the use of "namespace" is preventing Stanislav from even > being able to compile his code. > > When you say "mark the APIs as experimental" are you talking about putting > "state: experimental" in the FEATURE.yaml file or something else? If you're > talking about FEATURE.yaml, the file at src/plugins/linux-cp/FEATURE.yaml > already lists the state as experimental. Maybe the formatting of the file > is bad? > > Thanks, > -Matt > > > On Fri, Jul 15, 2022 at 4:14 AM Andrew Yourtchenko > wrote: > >> Hi Stanislav, >> >> The api is marked as “Production” so the behavior of checkstyle is there >> to protect the users (as for the duplication - it is a choice to do it once >> in VPP or in each and every downstream consumer). As for the pure code >> exercise - I just did it for the sake of a test, took a grand total of 15 >> minutes to add the new message versions. Hardly a massive deal. (We could >> probably improve tooling on the lifecycle management of these, though) >> >> That said - for this specific case - is the presence of the “namespace” >> member in a structure within the api a showstopper for you - that is, does >> it cause a compilation failure of some sort ? If so - one option is to >> mark the APIs as experimental and then change it in-place. It is up to >> component owners to decide the policy. >> >> --a >> >> On 15 Jul 2022, at 09:39, Stanislav Zaikin wrote: >> >> >> Hello folks, >> >> According to [0] it should be possible to add breaking changes to vpp api >> with incrementing the major version of the api. There's one issue in the >> LCP api - a C++ keyword "namespace" is used there and I want to change it >> to "netns" and increase a major version. But make checkstyle-api still >> fails. Any ideas? >> >> Of course, I can add new methods _v2 and deprecate the older ones. But >> it'd lead to code duplication and still I'd need to wait at least 2 >> releases. >> >> [0] https://wiki.fd.io/view/VPP/API_Versioning >> >> -- >> Best regards >> Stanislav Zaikin >> >> >> >> >> >> >> > > > -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21685): https://lists.fd.io/g/vpp-dev/message/21685 Mute This Topic: https://lists.fd.io/mt/92396431/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-