Instead of being excessively invasive to achieve HA, as Ole suggests, might be easier to spin off another instance based on some critical parameters. A kubernetes-like external agent that can be user configured to save the last config and reload the instances with the new plugin, or even restart the instances based on rules or policies.
Thanks! -- Regards, Balaji. From: <[email protected]> on behalf of Ole Troan <[email protected]> Date: Friday, December 13, 2019 at 9:42 AM To: "Dave Barach (dbarach)" <[email protected]> Cc: "chu.penghong" <[email protected]>, "[email protected]" <[email protected]> Subject: [SUSPECTED SPAM] Re: [vpp-dev] How to add plugin in running VPP ? > 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/1978096 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14888): https://lists.fd.io/g/vpp-dev/message/14888 Mute This Topic: https://lists.fd.io/mt/68530953/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
