tarantool / tarantool/doc

roles: list differences between cartridge roles and tarantool 3 roles

Open Beginner friendly
#4,280 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

3.0 config server
Dominant language
CSS
Stars
15
Forks
49
Avg merge
1d 13h
Merged PRs (30d)
3

Description

Related dev. issue(s): https://github.com/tarantool/tarantool/issues/9078
Related doc. issue(s): https://github.com/tarantool/doc/issues/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 on_event (tarantool/doc#4666) 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the migration guide inside the Developing applications with Tarantool section and read the related development issue #9078 and documentation issue #3702 for context. Use the listed cartridge-versus-Tarantool 3 differences as the checklist, confirm details with the named SME, and finish when the migration guide clearly documents each difference for application and module developers.

Written by the indexing model from the issue text.

Assessment

Tech stack
lua
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.