Skip to content

Conversation

vitvakatu
Copy link
Contributor

@vitvakatu vitvakatu commented Nov 6, 2019

Overview

Also fixed bug in java_runtime_factory module and fixed service_runtime_bootstrap native IT (it is still disabled)


See: https://jira.bf.local/browse/ECR-3727

Definition of Done

  • There are no TODOs left in the code
  • Change is covered by automated tests
  • The coding guidelines are followed
  • Public API has Javadoc
  • Method preconditions are checked and documented in the Javadoc of the method
  • Changelog is updated if needed (in case of notable or breaking changes)
  • The continuous integration build passes

@vitvakatu vitvakatu added the work-in-progress 👷‍♂️ Do not expect reviewers to provide any feedback on WIP PRs — please ask for it explicitly! label Nov 7, 2019
@vitvakatu vitvakatu removed the work-in-progress 👷‍♂️ Do not expect reviewers to provide any feedback on WIP PRs — please ask for it explicitly! label Nov 7, 2019
@coveralls
Copy link

coveralls commented Nov 7, 2019

Coverage Status

Coverage remained the same at 85.602% when pulling 6711f78 on vitvakatu:ecr-3727-run-dev-support into f74692b on exonum:master.

Copy link
Contributor

@dmitry-timofeev dmitry-timofeev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a couple of questions to the intended behaviour:

  1. Is this command expected to always start with a fresh blockchain? I.e., once the node is stopped, can the db be scrapped?
  2. If it is, then why doesn't it use a new temporary directory to store the database with auto-delete on exit feature? Deleting a directory that this process has created is fine, a directory that was previously created and (a) might not contain a database but user files; (b) might belong to another running process is not.
  3. If it isn't, then shan't we use a new temp by default, but allow specifying an existing db directory?
  4. A related question — if I started with a temporary directory, would I ever want to keep the db after I shutdown the node?

/// Run the node in development mode (generate configuration and db files automatically).
///
/// Runs one node with public API address 127.0.0.1:8080, private API address 127.0.0.1:8081,
/// EJB port 6400 and no logging configuration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no or default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially no way to specify Java logging configuration. Now added a special option for it. Not sure if I need to duplicate all other ejb parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't ask for an option to add configuration, I asked whether such invocation will have no configuration or the default. I do not expect and consider as sensible supporting logging configuration for this command.

@vitvakatu
Copy link
Contributor Author

Implementation has been rewritten almost completely, now it supports setting database directory and node configuration file.

@vitvakatu
Copy link
Contributor Author

In current implementation, user is allowed to provide the following parameters to the CLI:

  • artifacts-path - path to a directory containing Java artifacts. Works exactly as run command
  • db-path - path to a directory for database files. If not provided, system temporary directory is used. No files are deleted automatically, so the user must clean them manually if needed.
  • node-config - path to a node configuration file. If not provided, defaults to db_path/config and new config will be generated before node start. Again, no files are deleted automatically. Existing node configuration is used.
  • ejb-log-config-path - same as for run command.

So the user can:

  1. Easily run a node with "default" settings.
  2. Run node with specific database and/or node configuration.
  3. Reuse database and/or node configuration from previous runs

Copy link
Contributor

@dmitry-timofeev dmitry-timofeev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt it works, and the first question on the intended behaviour remains: is it expected to always start anew? Do we need to support these four options?

///
/// If <db_path> parameter is provided, returns <db_path>/config. Else returns system temporary
/// directory.
fn config_directory(&self) -> Result<PathBuf, failure::Error> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is named as a getter but it will create a new temporary directory if none exists.

let node_config_path = concat_path(config_directory.clone(), "node.toml");

// Configuration files exist, skip generation.
if config_directory.exists() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does existence of a config_directory (a temp dir may be created in config_directory) imply config file existence? Have you tested this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error messages when node configuration file is deleted from database_path/config directory:

Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

loading config from testnet/config/node.toml

/// files and <tmp>/config for node configuration files.
/// 2. Only `<db_path>` is provided. `<db_path>` is used for database files, `<db_path>/config` is
/// used for configuration files. If `<db_path>/config` exists, existing configuration files are
/// used, otherwise node configuration is auto-generated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-generated or extracted from the database? If the first, would it even work?

@vitvakatu
Copy link
Contributor Author

Reimplemented once more. Now the user must provide a required blockchain-path parameter which sets the directory used to store both database files and node configuration files. User must manually delete this directory (or use the new one) if a new node needs to be started.

Copy link
Contributor

@dmitry-timofeev dmitry-timofeev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, thanks!

To give some context: we discussed that the combinations of parameters when there are separate db path and config path and they are optional are too complex to implement and document and maintain; and unclear how useful; making the blockchain path in tmp would entail some restrictions and extra burden on the user since there is no easy way to implement auto-cleaning of that directory after node finishes (as a restriction, don't use in long-running systems that generate some transactions as nothing will clear the database directory until reboot). If we consider that tmp-that-is-not-cleaned is fine for the target usages, or tmp-that-is-cleaned is required (the use cases justify the complexity) — we can add any of that later, when there is demand.

/// Database is located in <blockchain_path>/db directory, node configuration files
/// are located in <blockchain_path>/config directory. Existing files and directories are
/// reused. To generate new node configuration and start a new blockchain, the user must
/// manually delete existing <blockchain_path> directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or specify a new one.

@dmitry-timofeev
Copy link
Contributor

The clippy is unhappy.

Copy link
Contributor

@skletsun skletsun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dmitry-timofeev dmitry-timofeev merged commit f20fe67 into exonum:master Nov 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants