-
Notifications
You must be signed in to change notification settings - Fork 62
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
fix: removing only networks started by hedera instead of global prune #686
fix: removing only networks started by hedera instead of global prune #686
Conversation
Signed-off-by: Mariusz Jasuwienas <[email protected]>
Signed-off-by: Mariusz Jasuwienas <[email protected]>
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.
Nice approach and a valuable contribution, thank you so much!
Just one small thing, this approach relies on the deterministic creation of networks. Currently if we start the local node and run
docker network ls
you can see there's a default network being created - its name is dependent on the name of the docker-compose project, which might change if we don't set it explicitly when bringing up the project.
That network is created here because the explorer component doesn't have an explicit network set. If all containers have an explicitly set custom network the default one will not be created. I would suggest adding it to the mirror-node network.
For extra safety it would be nice if you can add a test that verifies each service has a network set as well.
} | ||
|
||
/** | ||
* Removes one single network by its 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.
This is technically not true, as it will loop through all networks that match that name filter and remove them, so for example an argument of hedera
would remove all 3 networks created here, and if in the future we have a network named hedera-mirror-node-2
for example that would be removed together with hedera-mirror-node
when called with the hedera-mirror-node
parameter
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.
@isavov You are correct. I have updated the comment and added a remark to the README file regarding the functionality of our script. Currently, it will remove all networks with the “hedera-” prefix.
@@ -356,7 +356,7 @@ services: | |||
|
|||
networks: | |||
network-node-bridge: | |||
name: network-node-bridge | |||
name: hedera-network-node-bridge |
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.
maybe for consistency's sake all networks should have a -bridge suffix, or none of them
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.
@isavov
I chose the latter option since there is only one network with the “bridge” suffix and a few without it.
I have only updated the name used by Docker, not the Docker Compose level alias, as changing the alias seemed to be outside the current scope.
src/constants.ts
Outdated
* Names of all the networks created by Docker Compose in this repository. | ||
* Make sure to keep them up to date to always be able to remove them all using this service. | ||
*/ | ||
export const NETWORK_NAMES = [ |
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.
QQ: can’t we get this dynamically? It’s a pain to have to update this constant every time we make modifications to the docker-compose configurations. Also, one might not know this and may introduce bugs if he forgets to update this.
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.
Btw, why not use docker compose down
?
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.
@victor-yanev it's called, but this is an extra cleanup step. Alternatively to avoid the need for const NETWORK_NAMES
we could rely that all networks we use and only them have the hedera-
prefix and remove them that way.
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 could rely that all networks we use and only them have the hedera- prefix and remove them that way.
Understood, it will now function as described.
… listed in the constant Signed-off-by: Mariusz Jasuwienas <[email protected]>
… as its usage seemed to be inconsistent Signed-off-by: Mariusz Jasuwienas <[email protected]>
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.
Do we need to add that many different networks?
docker-compose.multinode.yml
Outdated
- multinode-importer-network | ||
|
||
networks: | ||
multinode-importer-network: |
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.
do we need this extra network?
docker-compose.multinode.evm.yml
Outdated
|
||
networks: | ||
multinode-importer-evm-network: | ||
name: hedera-multinode-importer-evm |
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.
do we need a different network here
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.
I guess not, I've replaced the extra networks with
network_mode: none
declarations.
Signed-off-by: Mariusz Jasuwienas <[email protected]>
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.
Starting with the latest changes gives me an error, removing the offending option for this service makes the next one behave the same way and so on
service record-sidecar-uploader declares mutually exclusive `network_mode` and `networks`: invalid compose project
docker-compose.evm.yml
Outdated
@@ -26,6 +30,8 @@ services: | |||
"echo 'Deleting old sidecars files.';find /sidecar-files/ -type f -delete;echo 'This container is intentionally disabled by the EVM profile.';" | |||
] | |||
command: [] | |||
network_mode: none |
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.
When starting local node I'm getting this error
service record-sidecar-uploader declares mutually exclusive `network_mode` and `networks`: invalid compose project
Signed-off-by: Mariusz Jasuwienas <[email protected]>
docker-compose.multinode.yml
Outdated
@@ -15,6 +15,7 @@ services: | |||
start_period: 10s | |||
volumes: | |||
- "${APPLICATION_ROOT_PATH}/config.multinode.txt:/opt/hgcapp/services-hedera/HapiApp2.0/config.txt" | |||
network_mode: none |
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.
@arianejasuwienas this will cause the same issue as with the evm profile, you can test by running with
--multinode
flag
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.
Strange, no network option was present for this service. However, I've changed it. Could you please check it once again? @isavov
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.
@arianejasuwienas I don't see the changes, can you please double check if you've pushed all changes.
Regarding the no network being defined. The way the multinode mode is constructed is that docker-compose.multinode.yml
is loaded on top of docker-compose.yml
and overrides the values in there. Therefore the network defined in the base file (docker-compose.yml) are used. You can gain a deeper insight in how it all works by reviewing this function here https://github.com/hashgraph/hedera-local-node/blob/40357136639d9caeb3834404ed0d3b12ab37c16f/src/services/DockerService.ts#L327-L357 as all the logic around this is defined there.
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.
…ces defined in docker-compose.yaml Signed-off-by: Mariusz Jasuwienas <[email protected]>
…ces defined in docker-compose.yaml Signed-off-by: Mariusz Jasuwienas <[email protected]>
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.
Thanks for this contribution @arianejasuwienas
Looks good to me 🙏
Description:
#685 (comment)
Related issue(s):
Fixes #685
Notes for reviewer:
Checklist