-
Notifications
You must be signed in to change notification settings - Fork 428
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
Service for database domain management #3052
Service for database domain management #3052
Conversation
Please describe the architecture, e.g. why two database tables are needed. One commit with 1000 lines of code and no description of the changes makes it difficult to figure out the reasoning behind all the changes. For PR's still in progress (not intended for review and merging yet) please use the 'Draft' option on GitHub. |
Codecov Report
@@ Coverage Diff @@
## multi-tenancy-phase-1 #3052 +/- ##
=========================================================
+ Coverage 78.53% 78.60% +0.06%
=========================================================
Files 378 385 +7
Lines 31119 31438 +319
=========================================================
+ Hits 24440 24712 +272
- Misses 6679 6726 +47
Continue to review full report at Codecov.
|
fbd21ff
to
7978a7b
Compare
7978a7b
to
1cbf7cf
Compare
Two new DB tables: domain_settings and domain_events. Added service service_domain_db. Added prepared queries in mongoose_domain_sql. The entry point for logic is in mongoose_domain_api. The module mongoose_domain_core should be always started. service_domain_db needs to be specified in the TOML config. service_domain_db_SUITE contains tests.
36607d8
to
8fd9252
Compare
src/domain/mongoose_domain_core.erl
Outdated
false | ||
end. | ||
|
||
remove_all_unlocked() -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of such interface? There must be per domain operations, group removal should not be possible. Otherwise, it's impossible to implement domain add/remove hooks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the simplest way to recover if gen_server of a DB service crashes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we must rework this. if this ETS is a source of truth for other components, it cannot spontaneously lose all the domains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
putting here some notes after today's discussion:
there are 2 different cases when domains DB service can potentially crash:
- During the MIM startup. before the initial filling of the ETS table (from DB) is done.
- after initial ETS filling.
for the first case it's acceptable to completely drop the core's ETS table, because we cannot use events DB table to perform an update of the ETS table with the latest changes.
for the second case, we must use events DB table.
implementation notes:
- core's gen_server must store the last applied event id.
- at the beginning, before the initial ETS filling, this event id is undefined.
- once initial ETS filling is done, event id is set for the first time.
- after that event id is updated with each and every change of the ETS.
- it must be possible to drop ETS data only if event id is not set yet.
- after initialization of the event id, DB service (on restart) must use that stored event id to apply the latest changes to the ETS.
- also we may want to extend the cleaning interval and max age parameters for the events DB table to some higher value, e.g. 1 day
@arcusfelis please add some implementation note in the source code.
src/domain/mongoose_domain_api.erl
Outdated
%% must be added to the core MIM component described above. | ||
%% Domains should be nameprepped using `jid:nameprep' | ||
-spec init([pair()]) -> ok | {error, term()}. | ||
init(Pairs) -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It must accept as a second parameter the list of allowed host types.
Only operation with the specified host types are allowed! if an invalid host type is used, the corresponding error must be returned.
Also host types are just strings. So every correct domain name is a correct host type identifier, but not every host type is a correct domain name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also host types are just strings. So every correct domain name is a correct host type identifier, but not every host type is a correct domain name
so, it would not make it interchangeable with any code, which does nameprepping for the Host
argument. Or requires host-type in the specification (hook api-s, pool api-s).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the host types automatically created for hosts declaration in config file will be interchangeable.
but the final goal is to ensure that MIM supports any string id for the host_type. that is one of the sanity checks.
Add db_reinserted_from_one_node_while_service_disabled_on_another testcase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of good work! I have some comments, but with such a big change it is inevitable.
-module(mongoose_domain_utils). | ||
-export([halt_node/1]). | ||
|
||
halt_node(ExitText) -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a side note, no need to change anything:
we should think about one common MIM helper module for such functionality
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a side note, no need to change anything in this PR:
in the future we should split service_domain_db_SUITE.erl into 2 separate suites:
- one for the domains core module testing (MB even make it a unit test)
- another for service testing
and of course we will have to extend (and rework if required) dynamic domain documentation as we progress with implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments that should be addressed in subsequent PR's.
db_reanabled_domain_is_in_db, | ||
db_reanabled_domain_is_in_core, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor typo: reenabled
get_all_static() -> | ||
mongoose_domain_core:get_all_static(). | ||
|
||
%% Get the list of the host\_types provided during initialisation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
%% Get the list of the host\_types provided during initialisation | |
%% Get the list of the host_types provided during initialisation |
end. | ||
|
||
check_for_updates(FromId, PageSize) -> | ||
check_if_from_num_still_relevant(FromId), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
check_if_from_num_still_relevant(FromId), | |
check_if_from_id_still_relevant(FromId), |
|
||
check_for_updates(FromId, PageSize) -> | ||
check_if_from_num_still_relevant(FromId), | ||
%% Ordered by the earlist events first |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
%% Ordered by the earlist events first | |
%% Ordered by the earliest events first |
check_if_from_num_still_relevant(0) -> | ||
ok; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This returns ok
but what if some records were added in the meantime (while there was no connection to the DB) and then cleanup happened? I think that we should still check that Min = 1
or something like that to make sure no cleanup was done.
Proposed changes include:
DONE:
- Need to add tests to check what is happening when service goes down.