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.

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

Conversation

arianejasuwienas
Copy link
Contributor

Description:
#685 (comment)

Related issue(s):

Fixes #685

Notes for reviewer:

Checklist

  • Documented (Code comments, README, etc.)
  • Tested (unit, integration, etc.)

Signed-off-by: Mariusz Jasuwienas <[email protected]>
Copy link
Contributor

@isavov isavov left a 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.
Copy link
Contributor

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

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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 = [
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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]>
Copy link
Contributor

@isavov isavov left a 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?

- multinode-importer-network

networks:
multinode-importer-network:
Copy link
Contributor

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?


networks:
multinode-importer-evm-network:
name: hedera-multinode-importer-evm
Copy link
Contributor

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

Copy link
Contributor Author

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]>
Copy link
Contributor

@isavov isavov left a 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

@@ -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
Copy link
Contributor

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

@@ -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
Copy link
Contributor

@isavov isavov Jul 16, 2024

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

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, you're right, I've missed it before . Both

npm run start

and

npm run start --multinode 

seem to work correctly at this moment.

Screenshot 2024-07-16 at 16 42 42

…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]>
Copy link
Contributor

@isavov isavov left a 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 🙏

@georgi-l95 georgi-l95 merged commit c2a0a10 into hiero-ledger:main Jul 17, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stopping the dockerized local node affects unrelated networks
4 participants