Ah. Well makes sense. But then the solution is simple - rather than disabling
*all* the plugins by default, disable individually all plugins you know of
“now”.
That way you get the backwards compatibility automatically.
You will still need to be vigilant in case you want to be precise about having
“no extra plugins” - but I presume you could put a hook to notify you into the
crc job, and update it so it doesn’t notify when it sees that particular plugin.
For bonus points: launch the VPP with and without the “new” plugin, see which
API messages it serves and whether you need any of them, and then use that
knowledge to automatically update the list.
Unlike an API change, which can have a huge impact radius, the decision about
the breaking case of the “chipped off” plugin takes O(1) time when manual (and
can be trivially fully automated), so a blocking process does not appear
appropriate.
Thoughts ?
--a
> On 8 Nov 2019, at 16:51, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at
> Cisco) <vrpo...@cisco.com> wrote:
>
>
> > plugins are not disabled by default
>
> So? Default is not minimal, we are explicitly disabling default plugins:
> plugins { plugin default { disable } plugin dpdk_plugin.so { enable } }
>
> Vratko.
>
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Andrew
> Yourtchenko
> Sent: Friday, November 8, 2019 4:17 PM
> To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com>
> Cc: vpp-api-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] API and plugins
>
> These “New” plugins are not disabled by default, how comes they are not
> loaded in your scenario if you say you don’t know about them?
>
> What does the config that experiences problems look like ?
>
> --a
>
>
> On 8 Nov 2019, at 14:47, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
> Cisco) via Lists.Fd.Io <vrpolak=cisco....@lists.fd.io> wrote:
>
>
> <image001.gif>
> Questions: If an API message handler is moved into a different plugin,
> does it constitute a (backward incompatible) API change?
> If yes, should we use similar checks and processes as for CRC changes?
>
> Example (not merged yet): sw_interface_ip6nd_ra_config
> is being moved from vnet [0] to plugins/ip6-nd [1].
>
> Discussion: While section 7 of RFC2544 [2] requires the tests
> to be run with all plugins enabled, CSIT tests are also aimed
> at detecting performance regressions in specific functions,
> which is less noisy when enabling minimal set of plugins needed.
> In order to keep equivalence between configurations
> of performance and functional tests,
> CSIT uses minimal plugin configurations when verifying API functionality.
> As ip6-nd is a new plugin introduced in 22819,
> CSIT functional tests are not enabling it,
> which results in the API message to become unrecognized [3] by the VPP
> process.
> The current CRC checks aggregate all messages (with CRCs)
> into a flat list, so the information on which plugin handles a message is
> lost.
> Should we (CSIT) change the checks to track also the implementing plugin
> (making 22819 fail the CRC job and triggering API upgrade process [4])?
>
> Note: The issue of changing plugin requirements
> was first encountered in a Change [5],
> which does not touch .api files,
> so even the proposed update of CRC job would not have detected it.
>
> Vratko.
>
> [0] https://gerrit.fd.io/r/c/vpp/+/22819/10/src/vnet/ip/ip.api#b253
> [1] https://gerrit.fd.io/r/c/vpp/+/22819/10/src/plugins/ip6-nd/ip6_nd.api#93
> [2] https://tools.ietf.org/html/rfc2544
> [3]
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-csit-verify-device-master-1n-skx/4129/archives/log.html.gz#s1-s1-s1-s6-s1-t1-k2-k8-k13
> [4]
> https://github.com/FDio/csit/blob/f7d43390a6ce60284f54cad4e66b66d1ecd4a166/docs/automating_vpp_api_flag_day.rst
> [5] https://gerrit.fd.io/r/c/vpp/+/22980
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14546): https://lists.fd.io/g/vpp-dev/message/14546
> Mute This Topic: https://lists.fd.io/mt/47762399/675608
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [ayour...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14549): https://lists.fd.io/g/vpp-dev/message/14549
Mute This Topic: https://lists.fd.io/mt/47762399/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
