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.

Sign up for GitHub

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

Jump to bottom

Introduce roles in config #9078

Closed
2 of 3 tasks
ImeevMA opened this issue Sep 1, 2023 · 1 comment
Closed
2 of 3 tasks

Introduce roles in config #9078

ImeevMA opened this issue Sep 1, 2023 · 1 comment
Assignees
@ImeevMA
Labels
3.0 Target is 3.0 and all newer release/master branches config

Comments

@ImeevMA
Copy link
Collaborator

ImeevMA commented Sep 1, 2023 •
edited by Totktonada

@ImeevMA ImeevMA added 3.0 Target is 3.0 and all newer release/master branches config labels Sep 1, 2023
@ImeevMA ImeevMA self-assigned this Sep 1, 2023
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 3, 2023
@ImeevMA
config: introduce roles
914bca0 
This patch introduces initial support for roles.

Roles are programs that run when a configuration is loaded or reloaded.
Roles can be defined for each instance. On first run, the role is
initialized with the init() method. On every run, the role calls
validate_config() and apply_config(). If the roles were removed from the
instance on reboot, the role is stopped using the stop() method.

If a role was added to an instance, then removed from the instance, and
then added again, init() is still not called.

Roles must have four methods: init(), validate_config(), apply_config()
and stop().

Each assigned role must be described in the roles_cfg file.

Dependencies are not currently supported for roles.

Part of tarantool#9078

NO_DOC=will be added later.
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 3, 2023
@ImeevMA
config: introduce roles
1a61576 
This patch introduces initial support for roles.

Roles are programs that run when a configuration is loaded or reloaded.
Roles can be defined for each instance. On first run, the role is
initialized with the init() method. On each run, the role calls
validate_config() and then apply_config() if validate_config() returns
true. If the roles were removed from the instance on reboot, the role is
stopped using the stop() method.

If a role was added to an instance, then removed from the instance, and
then added again, init() is still not called.

If a role is defined more than once on an instance, it will still only
run once.

Roles must have four methods: init(), validate_config(), apply_config()
and stop().

Each assigned role must be described in the roles_cfg file.

Dependencies are not currently supported for roles.

Part of tarantool#9078

NO_DOC=will be added later.
@ImeevMA ImeevMA mentioned this issue Sep 3, 2023
Merged
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 5, 2023
@ImeevMA
config: introduce roles
36099ba 
This patch introduces initial support for roles. Dependencies are not
currently supported for roles. In this regard, there is no strict order
in which roles are performed.

Part of tarantool#9078

@TarantoolBot document
Title: Roles

Roles are programs that run when a configuration is loaded or reloaded.
Roles can be defined for each instance. On first run, the role is
initialized with the init() method. On each run, the role calls
validate_config() and then apply_config() if validate_config() returns
true. If the roles were removed from the instance on reboot, the role is
stopped using the stop() method.

If a role was added to an instance, then removed from the instance, and
then added again, init() will be called.

If a role is defined more than once on an instance, it will still only
run once.

Roles must have four methods: init(), validate_config(), apply_config()
and stop().
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 7, 2023
@ImeevMA
config: introduce roles
dc99987 
This patch introduces initial support for roles. Dependencies are not
currently supported for roles. In this regard, there is no strict order
in which roles are performed.

Part of tarantool#9078

@TarantoolBot document
Title: Roles

Roles are programs that run when a configuration is loaded or reloaded.

Roles can be defined for each instance.

If a role is defined more than once on an instance, it will still only
run once.

The roles will be executed in the order in which they are specified in
the corresponding option.

As with almost all other options, with the exception of those defined as
"map", the roles for the lower scope will replace the roles for the
higher scope.

Value roles_cfg however defined as "map", so it will be merged.

Roles must have three functions defined: validate(), apply() and stop().

Each of these functions must throw an error if it occurs.

On each run, the role calls validate() and then apply().

If the roles were removed from the instance on reload, the role is
stopped using the stop() function.
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 8, 2023
@ImeevMA
config: introduce roles
9f2841d 
This patch introduces initial support for roles. Dependencies are not
currently supported for roles.

Part of tarantool#9078

@TarantoolBot document
Title: Roles

Two new options have been added: "roles" and "roles_cfg". The first one
is an array and the second one is a map. Each of these can be defined
per instance, replica set, group, and globally. As with almost all other
options, with the exception of those defined as 'map', the 'roles'
option for the lower scope will replace the roles for the higher scope.
Value roles_cfg however defined as "map", so it will be merged.

The "roles" option defines the roles for each instance. A role is a
program that runs when a configuration is loaded or reloaded. If a role
is defined more than once on an instance, it will still only be run
once. Three functions must be defined in the role: validate(), apply()
and stop(). Each of these functions should throw an error if it occurs.

The "roles_cfg" option specifies the configuration for each role. In
this option, the role name is the key and the role configuration is the
value.

On each run, all roles will be loaded (if necessary) in the order in
which they were specified; the configuration for each role will then be
validated using the corresponding validate() function in the same order;
and then they will all be run with apply() function in the same order.
If some roles have been removed from the instance, they will be stopped
in reverse order using the stop() function.

Example of a role structure:
```
local M = {}

-- Validates configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the validation fail.
function M.validate(cfg)
    -- <...>
end

-- Applies the given configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the given configuration can't be appied.
function M.apply(cfg)
    -- <...>
end

-- Stops the role.
--
-- Called on configuration reload if the role was enabled before
-- and removed now from the list of roles of the given instance.
--
-- Should cancel all background fibers and clean up hold
-- resources.
--
-- Must raise an error if this action can't be performed.
function M.stop()
    -- <...>
end

return M
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Sep 8, 2023
@ImeevMA
config: introduce roles
81f4d6d 
This patch introduces initial support for roles. Dependencies are not
currently supported for roles.

Part of tarantool#9078

@TarantoolBot document
Title: Roles

Two new options have been added: "roles" and "roles_cfg". The first one
is an array and the second one is a map. Each of these can be defined
per instance, replica set, group, and globally. As with almost all other
options, with the exception of those defined as 'map', the 'roles'
option for the lower scope will replace the roles for the higher scope.
Value roles_cfg however defined as "map", so it will be merged.

The "roles" option defines the roles for each instance. A role is a
program that runs when a configuration is loaded or reloaded. If a role
is defined more than once on an instance, it will still only be run
once. Three functions must be defined in the role: validate(), apply()
and stop(). Each of these functions should throw an error if it occurs.

The "roles_cfg" option specifies the configuration for each role. In
this option, the role name is the key and the role configuration is the
value.

On each run, all roles will be loaded (if necessary) in the order in
which they were specified; the configuration for each role will then be
validated using the corresponding validate() function in the same order;
and then they will all be run with apply() function in the same order.
If some roles have been removed from the instance, they will be stopped
in reverse order using the stop() function.

Example of a role structure:
```
local M = {}

-- Validates configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the validation fail.
function M.validate(cfg)
    -- <...>
end

-- Applies the given configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the given configuration can't be applied.
function M.apply(cfg)
    -- <...>
end

-- Stops the role.
--
-- Called on configuration reload if the role was enabled before
-- and removed now from the list of roles of the given instance.
--
-- Should cancel all background fibers and clean up hold
-- resources.
--
-- Must raise an error if this action can't be performed.
function M.stop()
    -- <...>
end

return M
```
Totktonada pushed a commit that referenced this issue Sep 8, 2023
@ImeevMA @Totktonada
config: introduce roles
5288440 
This patch introduces initial support for roles. Dependencies are not
currently supported for roles.

Part of #9078

@TarantoolBot document
Title: Roles

Two new options have been added: "roles" and "roles_cfg". The first one
is an array and the second one is a map. Each of these can be defined
per instance, replica set, group, and globally. As with almost all other
options, with the exception of those defined as 'map', the 'roles'
option for the lower scope will replace the roles for the higher scope.
Value roles_cfg however defined as "map", so it will be merged.

The "roles" option defines the roles for each instance. A role is a
program that runs when a configuration is loaded or reloaded. If a role
is defined more than once on an instance, it will still only be run
once. Three functions must be defined in the role: validate(), apply()
and stop(). Each of these functions should throw an error if it occurs.

The "roles_cfg" option specifies the configuration for each role. In
this option, the role name is the key and the role configuration is the
value.

On each run, all roles will be loaded (if necessary) in the order in
which they were specified; the configuration for each role will then be
validated using the corresponding validate() function in the same order;
and then they will all be run with apply() function in the same order.
If some roles have been removed from the instance, they will be stopped
in reverse order using the stop() function.

Example of a role structure:
```
local M = {}

-- Validates configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the validation fail.
function M.validate(cfg)
    -- <...>
end

-- Applies the given configuration of the role.
--
-- Called on initial configuration apply at startup and on
-- configuration reload if the role is enabled for the given instance.
--
-- The cfg argument may have arbitrary user provided value,
-- including nil.
--
-- Must raise an error if the given configuration can't be applied.
function M.apply(cfg)
    -- <...>
end

-- Stops the role.
--
-- Called on configuration reload if the role was enabled before
-- and removed now from the list of roles of the given instance.
--
-- Should cancel all background fibers and clean up hold
-- resources.
--
-- Must raise an error if this action can't be performed.
function M.stop()
    -- <...>
end

return M
```
@andreyaksenov andreyaksenov mentioned this issue Sep 14, 2023
Open
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 7, 2023
@ImeevMA
config: add dependencies for roles
59fa815 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded in the same
order in which they were specified, i.e. not taking dependencies into
account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
@ImeevMA ImeevMA mentioned this issue Nov 7, 2023
Merged
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 7, 2023
@ImeevMA
config: add dependencies for roles
79287dc 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded in the same
order in which they were specified, i.e. not taking dependencies into
account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 9, 2023
@ImeevMA
config: add dependencies for roles
14a0a0e 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded in the same
order in which they were specified, i.e. not taking dependencies into
account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 23, 2023
@ImeevMA
config: add dependencies for roles
ecc2cac 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded (not applied!)
in the same order in which they were specified, i.e. not taking
dependencies into account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 28, 2023
@ImeevMA
config: add dependencies for roles
1b6dcf7 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded (not applied!)
in the same order in which they were specified, i.e. not taking
dependencies into account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Nov 28, 2023
@ImeevMA
config: add dependencies for roles
5815cdf 
This patch adds dependencies support for roles.

Part of tarantool#9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded (not applied!)
in the same order in which they were specified, i.e. not taking
dependencies into account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
Totktonada pushed a commit that referenced this issue Nov 29, 2023
@ImeevMA @Totktonada
config: add dependencies for roles
7fbc1d0 
This patch adds dependencies support for roles.

Part of #9078

@TarantoolBot document
Title: dependencies for roles

Roles can now have dependencies. This means that the verify() and
apply() methods will be executed for these roles, taking into account
the dependencies. Dependencies should be written in the "dependencies"
field of the array type. Note, the roles will be loaded (not applied!)
in the same order in which they were specified, i.e. not taking
dependencies into account.

Example:

Dependencies of role A: B, C
Dependencies of role B: D
No other role has dependencies.

Order in which roles were given: [E, C, A, B, D, G]
They will be loaded in the same order: [E, C, A, B, D, G]
The order, in which functions verify() and apply() will be executed:
[E, C, D, B, A, G].
@Totktonada
Copy link
Member

The main scope is done. I propose to track the permissions enhancements separately. Closing so.

@andreyaksenov andreyaksenov mentioned this issue Mar 5, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ImeevMA ImeevMA

Labels
3.0 Target is 3.0 and all newer release/master branches config
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Totktonada @ImeevMA