Skip to content

roles: list differences between cartridge roles and tarantool 3 roles #4280

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

Open
Totktonada opened this issue Jun 10, 2024 · 0 comments
Open
Labels
3.0 config server [area] Task relates to Tarantool's server (core) functionality

Comments

@Totktonada
Copy link
Member

Totktonada commented Jun 10, 2024

Related dev. issue(s): tarantool/tarantool#9078
Related doc. issue(s): #3702

Product: Tarantool
Since: 3.0.0
Audience/target: application and module developers
Root document: A migration guide inside the Developing applications with Tarantool section
SME: @ Totktonada

Details

There are a couple of differences between cartridge's roles and tarantool 3 roles. I propose to list them in the documentation to ease UX for developers who migrate its application from cartridge to tarantool 3.

The list of known differences:

  • No role_name parameter. A name of tarantool 3 role is the name of the module (foo/bar/baz.lua is a foo.bar.baz role).
  • No init function. An initialization code is what the module itself executes on require, IOW, the code outside functions on the top level.
  • The role code is loaded after first box.cfg(), not before.
  • Different function names: validate_config -> validate, apply_config -> apply.
  • validate and apply receive cfg argument that represents a configuration of the given role (roles_cfg.<role name>), not a full config. A full config can be acquired using config:get().
  • No second old_cfg argument.
  • <role>.apply is not invoked on RO/RW changes. Use box.watch('box.status', <...>) to react on the RO/RW mode changes.
  • stop() is called in the reverse order (according to dependencies). So, higher level roles are stopped first.
  • validate, apply, stop should raise a Lua error to report an unrecoverable error. Any return value (including return nil, err) is considered as success.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.0 config server [area] Task relates to Tarantool's server (core) functionality
Projects
None yet
Development

No branches or pull requests

2 participants