Re: [vpp-dev] ikev2 API & new API change process
I think there are two issues. One issue is with APIs that were not intended to be Production yet. For ikev2 that basically means the version has been set [5] above 0.x.y only by mistake. As downgrading versions is always risky, marking messages as "In-Progress" instead is better. The other issue is how to determine which APIs are really Production, and which are In-Progress with wrong version value. I believe every existing API should be reviewed, before we claim the new process [3] is applied. There are sub-issues, like who will decide, how much testing is needed, and how widespread a usage implies an API is effectively Production already. In contrast, the question of how to deal with Production APIs (existence of which hinders the work on legitimate improvements) is a non-issue. The new process has good reasons to force the expensive way with deprecation. Personally, I think it would be a good idea to mark ALL APIs as In-Progress, as it matches the (lack of) guarantees in previous releases, and let maintainers mark some messages as Production on their own pace. Vratko. [5] https://gerrit.fd.io/r/c/vpp/+/17803/3/src/plugins/ikev2/ikev2.api -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Benoit Ganne (bganne) via lists.fd.io Sent: Tuesday, 2020-June-16 18:29 To: vpp-dev@lists.fd.io Cc: Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco) ; Andrew Yourtchenko (ayourtch) Subject: [vpp-dev] ikev2 API & new API change process Hi all, The ikev2 plugin is currently getting some much needed love [1] [2] but it also means that its API is starting to show its age. We'd like to mark it as "In-Progress" under the new API change process [3] so that we can quickly improve it. The rationale is: - the requirement for an API to transition to "In-Production" is for the API to be stable and *tested* - there are currently no ikev2 unit test at all, and in fact the 1st proposed API change was motivated by the introduction of the initial test cases [4] - we are not aware of any users of the ikev2 plugin API today apart from the Calico-VPP integration Of course, a possibility would be to deprecate the existing one and to introduce a new one as "In-Progress" at the expense of more work. What does the community think here? Thanks ben [1] https://jira.fd.io/browse/VPP-1889 [2] https://jira.fd.io/browse/VPP-1904 [3] https://wiki.fd.io/view/VPP/ApiChangeProcess [4] https://gerrit.fd.io/r/c/vpp/+/27536 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16743): https://lists.fd.io/g/vpp-dev/message/16743 Mute This Topic: https://lists.fd.io/mt/74919923/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] ikev2 API & new API change process
> Personally, I think it would be a good idea to mark ALL APIs as In-Progress, > as it matches the (lack of) guarantees in previous releases, > and let maintainers mark some messages as Production on their own pace. I'm not sure how you could reconcile that with e.g. the CRC job verifier nor all the consumers of the API. If an API is used it is for all purposes in production. Ole-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16744): https://lists.fd.io/g/vpp-dev/message/16744 Mute This Topic: https://lists.fd.io/mt/74919923/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] ikev2 API & new API change process
> Yeah, i would rather not mark all api in progress since that would make > the transition much longer. Agreed. > So I suggest a 1 month period during a developer that wants to downgrade > an API, prepares a change with *just that action*, clearly marked “API > downgrade”, type: fix, adds me as a reviewer > and sends a mail Subject “API downgrade” to vpp-dev to get the consent > from the users as well as Inform them. > After 2-week timeout period, if no one complained, they can merge that > downgrade. > This means in 1.5 months we have it converged. > What do you think ? This is a good idea, but I'd merge downgrade + API modification at once instead of waiting for 2 weeks: - it means ikev2 tests cannot be merged for 2 weeks, preventing more new tests to be added alongside new fixes/features - at least if the API break, consumer has more chance to notice it 😊 ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16745): https://lists.fd.io/g/vpp-dev/message/16745 Mute This Topic: https://lists.fd.io/mt/74919923/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] jvpp compatiblity
Hi, It seems the current jvpp is not compatible with the latest vpp 20.05. Building jvpp against the latest vpp fails. Looks like jvpp development has stopped since vpp 19.04. Is there any plan to update jvpp to make it compatible with the latest vpp? In fact I do not understand why jvpp was dropped from vpp and made independent. Since honeycomb relies on jvpp, having up-to-date jvpp seems important. Thanks, Chang -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16746): https://lists.fd.io/g/vpp-dev/message/16746 Mute This Topic: https://lists.fd.io/mt/74950618/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Fetching SR Policy data using VPP C API
Can anyone please suggest something for this? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16747): https://lists.fd.io/g/vpp-dev/message/16747 Mute This Topic: https://lists.fd.io/mt/74894689/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error
Can anyone please suggest something for this? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16748): https://lists.fd.io/g/vpp-dev/message/16748 Mute This Topic: https://lists.fd.io/mt/74477804/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] jvpp compatiblity
Hi Chang, There’s no active development on jvpp as well as honeycomb but any contribution to update them is of course more than welcome. If you need to program vpp, I’d recommend considering go, c or python. Jerome De : au nom de Hyunseok Date : jeudi 18 juin 2020 à 03:21 À : "vpp-dev@lists.fd.io" Objet : [vpp-dev] jvpp compatiblity Hi, It seems the current jvpp is not compatible with the latest vpp 20.05. Building jvpp against the latest vpp fails. Looks like jvpp development has stopped since vpp 19.04. Is there any plan to update jvpp to make it compatible with the latest vpp? In fact I do not understand why jvpp was dropped from vpp and made independent. Since honeycomb relies on jvpp, having up-to-date jvpp seems important. Thanks, Chang -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16749): https://lists.fd.io/g/vpp-dev/message/16749 Mute This Topic: https://lists.fd.io/mt/74950618/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
