Georgy Moshkin authored 5 months ago and Dmitry Rodionov committed 5 months ago

Previous implementation would call functions over the ffi boundary which
weren't defined with the required `extern` specifiers, which is not allowed.

This commit embeds in plugins a new variable, containing picoplugin
version used to build it. If this version differs from the picodata version
when the plugin gets loaded, the loading fails with an error reporting
the expected and the current versions. This check can be disabled via env
PICODATA_UNSAFE_DISABLE_PLUGIN_COMPATIBILITY_CHECK.

Дмитрий Кольцов authored 5 months ago and Georgy Moshkin committed 5 months ago

All migrations are explicitly listed in manifest.yaml,
so there is no much sense in strict extension check

Closes #990

godzie44 authored 6 months ago and Georgy Moshkin committed 6 months ago

Closes #664

godzie44 authored 6 months ago and Georgy Moshkin committed 6 months ago

Closes #708

godzie44 authored 6 months ago and Georgy Moshkin committed 6 months ago

fix(plugin): remove `on_config_validate` callback and introduce `ServiceRegistry::add_config_validator` function

These changes make it possible to change the configuration for a disabled plugin, as well as initiate a configuration change from instances where the plugin was not enabled.

Closes #845

godzie44 authored 7 months ago and Georgy Moshkin committed 6 months ago

Closes: #837

Added tier parameter to plugin RPC target BucketId

We only use Eq ranges

CAS predicates should always contain the current raft term, because this
is what's explicitly checked in proc_cas.

Note that this will sometimes result in a EntryTermMismatch error
because the latest applied entry may have a different term in case the
election has started but not finished yet.

We could add this check to all the client cas precondition checks, but
it's not a big deal, because we handle the situation correctly anyways.

fix: report a more specific error when plugin is dropped while we're waiting for enable plugin operation to finish

- Simplify code
- Check plugin exists on client side

- Move all preconditions checking to the client
- Return errors if preconditions fail instead of silently ignoring them

- Don't ignore operation if plugin is already enabled,
  the client must take care of this via the CaS ranges

- Don't propose mutliple Raft operations during one step as this may
  lead to inconsistencies in case of crashes

- Don't ignore operation if plugin is already installed,
  the client must take care of this via the CaS ranges

- Don't propose multiple Raft operations during one step as this may
  lead to inconsistencies in case of crashes