TrueCloudLab/frostfs-dev-env

Fork 18

Allow to start from the frostfs-adm prepared dump #42

New issue

Open

opened 2023-08-02 12:20:14 +00:00 by fyrchik · 5 comments

fyrchik commented

2023-08-02 12:20:14 +00:00

Owner

frostfs-adm support morph init to the dump file. If I do multiple make down clean up during the development, I should have an option to not wait for >10 seconds just for frostfs-adm to deploy.

`frostfs-adm` support `morph init` to the dump file. If I do multiple `make down clean up` during the development, I should have an option to not wait for >10 seconds just for frostfs-adm to deploy.

fyrchik added the

discussion

good first issue

labels 2023-08-02 12:20:48 +00:00

alexvanin commented

2023-09-20 13:16:39 +00:00

Owner

As an alternative, frostfs-aio stores chain in the docker volume, so it is persistent between restarts and cleaned after make clean. Therefore first start takes >10 seconds, but then restarts are much faster. What do you think about it?

As an alternative, frostfs-aio stores chain in the docker volume, so it is persistent between restarts and cleaned after `make clean`. Therefore first start takes >10 seconds, but then restarts are much faster. What do you think about it?

fyrchik commented

2023-10-02 13:30:05 +00:00

Author

Owner

It works, but I was thinking specifically about clean case, when I want to start with a fresh instance of node.

It works, but I was thinking specifically about `clean` case, when I want to start with a fresh instance of node.

alexvanin commented

2023-10-19 06:38:01 +00:00

Owner

Maybe some make dump and make restore commands can be useful. Default workflow isn't changed, but you can dump chain state at some point and then make down clean restore when you need to go back.

Maybe some `make dump` and `make restore` commands can be useful. Default workflow isn't changed, but you can dump chain state at some point and then `make down clean restore` when you need to go back.

fyrchik referenced this issue from a commit

2024-11-20 11:32:10 +00:00

adm: Allow to use --local-dump everywhere --rpc-endpoint is present

fyrchik referenced this issue from a commit

2024-11-20 11:32:49 +00:00

adm: Allow to use --local-dump everywhere --rpc-endpoint is present

fyrchik referenced this issue from TrueCloudLab/frostfs-node

2024-11-20 11:33:13 +00:00

WIP: adm: Allow to use local-dump from every command #1511

fyrchik referenced this issue from a commit

2024-11-20 11:38:05 +00:00

adm: Allow to use --local-dump everywhere --rpc-endpoint is present

fyrchik referenced this issue from a commit

2024-11-20 11:38:38 +00:00

adm: Allow to use --local-dump everywhere --rpc-endpoint is present

nzinkevich commented

2024-12-26 10:31:48 +00:00

Member

Also I think it would be nice to reuse already downloaded binaries instead of downloading them on every make up . Env variables FROSTFS_CONTRACTS_PATH, FROSTFS_ADM_PATH, FROSTFS_CLI_PATH have already presented but we have to configure them manually when dev-env versions are updated. Consider adding a check for cases where local binaries are outdated in order to use these envs by default

Also I think it would be nice to reuse already downloaded binaries instead of downloading them on every `make up` . Env variables `FROSTFS_CONTRACTS_PATH`, `FROSTFS_ADM_PATH`, `FROSTFS_CLI_PATH` have already presented but we have to configure them manually when dev-env versions are updated. Consider adding a check for cases where local binaries are outdated in order to use these envs by default

fyrchik commented

2024-12-26 11:24:02 +00:00

Author

Owner

where local binaries are outdated in order to use these envs by default

This check is hard to implement: we cannot use astronomical time and, usually, frostfs-cli version matches that of node.
To solve constant manual configuration we should use some .env that is not checked out in this repo (but used in Makefile).

>where local binaries are outdated in order to use these envs by default This check is hard to implement: we cannot use astronomical time and, usually, frostfs-cli version matches that of node. To solve constant manual configuration we should use some .env that is not checked out in this repo (but used in Makefile).