> As of today, plugins are loaded early enough in the vpp init sequence;
> everything which can be done in core engine code can also be done from
> plugins. They are not removed and they are not updated after vpp starts.
>
> Making plugins removable or updateable would take considerable attention to
> detail, and doesn’t seem worth the amount of work involved, especially with
> respect to plugin API changes.
>
> Plugins would need “unload_prep” methods, with fine-grained controls to
> minimize unnecessary data-structure teardowns. Best to keep FIBs and session
> tables and so on intact if data structures match.
>
> In my own production use of vpp, I expect a single vpp process to run for up
> to a year. Updates are scheduled in advance. The vpp update portion of the
> exercise typically takes about 10 seconds.
>
> I’d be interested in hearing from the community: should we think about how to
> refactor the entire code base to support arbitrary plugin load / unload /
> reload scenarios? I don’t think it’s worth the amount of effort involved, but
> that just my view.
Isn't this a pets vs cattle culture crash?
On one side of the spectrum you have the always up HA systems with Non-stop
forwarding and ISSU etc, and on the other side the "just spin up a new thing
(bare metal/container/VM/process) if anything needs changing".
I would be very cautious of the "old way" of achieving robustness. The added
complexity is going to make the system harder to develop in, slow down feature
velocity, and likely decrease robustness instead of improving on it.
Best regards,
Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14887): https://lists.fd.io/g/vpp-dev/message/14887
Mute This Topic: https://lists.fd.io/mt/68267897/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
