Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plug-in based system to enhance maintainability #159

Open
6 tasks
juagargi opened this issue Jan 25, 2024 · 0 comments
Open
6 tasks

Plug-in based system to enhance maintainability #159

juagargi opened this issue Jan 25, 2024 · 0 comments
Assignees

Comments

@juagargi
Copy link
Member

juagargi commented Jan 25, 2024

Due to the nature of SCIONLab, we mainly expect modifications to the source upstream in these two forms:

  1. Change existing behavior.
  2. New features.

The first one, changing an existing piece of code, can be tackled quite well with the use of gopatch (link), which has been tested already by @juagargi and works quite well.

On the other hand, adding new features usually involves only modifying a small amount of existing code from upstream,
while much more often (in number of changes) adding code where there was none.
This has been done in the past in these instances:

  • Adding a COLIBRI service.
  • Adding a COLIBRI data-plane forwarding routine.
  • Adding carbon impact as a new meta-information variable.

We do propose the use of Go plugins (link) in those entry points that we find out will be relevant for these types of endeavors. So far we have:

  1. Path Type: Allow forwarding of new path types
  2. Meta-information variables: allow the addition of new variables.
  3. (maybe) Useful for beacon selection and propagation (each AS could have their own function)

The use of plugins has to be first tested to ensure that:

  • They correctly link to the existing upstream version. Do we need a versioning system, or is that taken care by Go?
  • Performance is not impacted, where performance is important. Namely, data-plane forwarding.
  • Wrong configuration of the plugin preventing it to load properly will not affect the rest of the process. E.g. a wrong version of the plugin is loaded, whose symbols are incompatible with the main e.g. control service, forces an entry in the log as an error, but the control service resumes initializing and continues as usual.

To do:

  • Study the questions above.
  • Create a plugin system for e.g. the border router data-plane.
  • Create gopatch patches for this plugin system.
  • Contact the SCION Association to study the possibility of using our plugin system in general.
  • Merge to upstream whenever possible, and remove the corresponding gopatch.
  • Simultaneously proceed with the rest of the plugin systems (e.g. meta-information variables).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant