-
Notifications
You must be signed in to change notification settings - Fork 2
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
Confusing parameters wrt logging? mainnet/testnet #24
Comments
Re reading, I think I forgot to mention that I can't seem to figure out which tx env variables I need to include to make it work. |
Correct.
Yes. The
There are many ways of skinning this.
This var (
The env vars for tx logging (the service, not legacy) are referenced here (them not being in the readme is a bug): It's
Yes, but it's not just that port, it's also Running multiple nodes on the same machine (particularly on different networks) is stretching the capabilities of Docker Compose. You could duplicate the services in the config file to make a mega deployment and that would probably work fine. Or change the ports as above. Otherwise I think you're entering Kubernetes land. I'm working on upgrading the Helm chart (#21) but it's not yet properly tested. |
If you aren't using the node dashboard, you could remove the services related to that. Then there aren't that many ports left to keep track of. |
Hi @sderuiter did the explanations above help? |
Note that #21 mentioned above has now been merged. |
To be honest, no. I've started a new node+logger, I think it works, but the logger is extremely slow (still hasn't caught up after 5 days?). I've abandoned running the logger (+ homegrown additional db on top) for the Explorer, it's too much maintenance at this moment. Still have loggers running for statistics, but hoping to get to a state where I can move to a new host and install a node + logger without hassle. Sorry. |
Not sure if this in the planning, but ideally either the node gets its logger removed, or the new logger uses parameters that have a distinctive naming pattern (to not confuse them with the node logging parameters). My preference would be the first. |
I've also seen these very long catchup times. I was assuming that it was due to the old transaction logging. The new one should be much faster, especially if you enable parallelization with
The new logger service has been completely verified to be consistent with the old one, so it is indeed the intent to remove it from both this project and longer term also from the node. I'm not sure what you mean by distinctive naming patters as they already use distinct prefixes ( Once the old feature is removed (which it will be soon; filed #40), I will probably settle on just the |
All referenced tasks have been fixed (updated Helm chart, removed legacy transaction logging, improved documentation). Does this leave any outstanding issues? @sderuiter |
Most relevant changes happened in #41. |
Are you sure this is consistently applied in the repo? the .ENV files are called +TX_LOG, which then refers to the old logger, while I think the purpose of these .ENV files is to enable to new logger? The READMD.md file, under heading Transaction Logger, also discusses the new logger, but uses the name TX_LOG? Also, that file has: Is this referring to the new or old logger? |
Further, in the readme under Transaction logger, you mention: In mainnet+txlog.env there's: Now, in docker-compose.yml, there's: Wouldn't this lead to a db name of mainnet_concordium_txlog-concordium_txlog? |
The term "txlog" was/is meant to refer to transaction logging in general, not a particular method. The old method was originally the only method; when the new one was added it had to have different names where they conflicted. The only place where this applied were in the environment variables. The The reason for keeping the legacy method until now was for verifying the new service.
I used to use this database name for the old logger. Now it's used for the only logger.
No it means that it defaults to |
The legacy transaction logging feature has been removed from the node as of v4.2.2 (Concordium/concordium-node#395). |
My goal is to start fresh on a new host. My end result should be:
None of these nodes should run the legacy tx logger from the node itself.
Pain points right now:
concordium-docker/docker-compose.yaml
Line 60 in 0bcd493
Ideally, I would:
NODE_NAME=concordium-explorer-mainnet ./run.sh mainnet-txlog
NODE_NAME=concordium-explorer-testnet ./run.sh testnet-txlog
The above doesn't seem possible in it's current form, right?
The text was updated successfully, but these errors were encountered: