-
Notifications
You must be signed in to change notification settings - Fork 21
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
Standardize default exposed ports in the node chart #178
Comments
The I think it's best to stick with the relaychain and parachain naming conventions if you agree:
|
No it's not best because when you deploy a parachain, you don't want to have these strange ports for your main chain. Actually the embedded relay-chain node will be optional in the future so it make sense that those will be shifted by -1000 so we keep our usual ports that have their function. The confusion was caused by us reusing our existing relay-chain scripts to deploy parachains and it caused tremendous confusion for users that want to connect to their parachains and don't understand why it would use different ports than a regular substrate chain. |
I agree, my comment was more about setting the ports based on being relaychain or parachain, rather than primary or secondary as a relaychain could be primary or secondary depending on So IIUC this would be the port numbers, right?
|
You are completely correct that but this puts into question having default values for those ports in the values.yaml. So for now we can use old default ports. 30333 (tcp relay), 30334 (ws-relay), 30334 (tcp para), 30334 (ws-para). Overiddes will be needed for resolving conflicts for now. |
The confusion is caused by the fact that we use different approaches in ansible role, in helm-chart and default CLI settings of the application. The port number is just a habit, if we use "8944" for the parachain and "9944" for the relaychain in the collection node, it will simplify the ansible and helm diagrams, but still cause confusion if we have different ports in the CLI default values. I suggest moving this issue to the cumulus repository. |
I think what makes things harder is that I have made a big mistake and didn't follow initial logic of the helm-chart for implementing the p2p services. I have added So this:
Should be IMO changed to this:
Please 👍 or 👎 if you agree with this or not ? |
We want to make it easier to reason about the exposed ports for substrate nodes (especially collators that run 2 nodes in 1). So from internal discussions at Parity we brainstormed the following table. The logic is to reuse conventions that arose organically while minimizing confusion (eg. it is very hard to differentiate 30334 and 30344 at a glance).
To achieve this we propose to shift port numbers by
-1000
for the secondary chain (ie. relay-chain for the collator). Note that most of the times those ports don't need to be exposed.The text was updated successfully, but these errors were encountered: