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

Remove ipv4 v3 #303

Closed
Closed

Conversation

willcl-ark
Copy link
Contributor

@willcl-ark willcl-ark commented Mar 5, 2024

Remove the ipv4 stuff (and fixed subnet from compose).

Closes #253

@@ -468,7 +486,6 @@ def create_lnd_container(
f"--bitcoind.zmqpubrawblock={bitcoind_rpc_host}:{tank.zmqblockport}",
f"--bitcoind.zmqpubrawtx={bitcoind_rpc_host}:{tank.zmqtxport}",
f"--rpclisten=0.0.0.0:{tank.lnnode.rpc_port}",
f"--externalhosts={lightning_dns}",
Copy link
Contributor

@pinheadmz pinheadmz Mar 7, 2024

Choose a reason for hiding this comment

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

might reconsider keeping this. from the doc:

 --externalhosts=                                      

Add a hostname:port that should be periodically resolved to announce IPs for. If a port is not specified, the default (9735) will be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, not sure what to do here, as we won't know the ip address until after startup in our classic, re-occurring chicken-and-egg problem.

Copy link
Contributor

Choose a reason for hiding this comment

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

but lightning_dns is a domain name isn't it? Sounds to me like lnd will resolve the IP sometime after startup

src/warnet/lnnode.py Outdated Show resolved Hide resolved
src/warnet/lnnode.py Outdated Show resolved Hide resolved
Comment on lines 109 to 111
# TODO: What does this break?
# "address": f"https://{self.ipv4}:{self.rpc_port}",
Copy link
Contributor

Choose a reason for hiding this comment

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

Great point actually. So, running warnet+simln locally, simln would be running on the host and not in the docker network at all. It would use the IPs of the lnd nodes inside docker to send RPC commands (remember we made them fix it, bitcoin-dev-project/sim-ln#151).

This may be the only time we explicitly need the actual IP of the lnd node.

Or we could work out how to incorporate sim-ln inside a container in the network, which we will probably need for K8s deployment anyway

@pinheadmz
Copy link
Contributor

Re: #134

Yes this does create each new network with a unique subnet.

Test:

warcli network start --network=wn1
warcli network start --network=wn2
docker inspect wn1 | grep Subnet
docker inspect wn2 | grep Subnet

However I think we could make one additional change to the compose file to make it even more clear in the docker desktop GUI and who knows wherever else:

diff --git a/src/backends/compose/compose_backend.py b/src/backends/compose/compose_backend.py
index ecc067c..7eab535 100644
--- a/src/backends/compose/compose_backend.py
+++ b/src/backends/compose/compose_backend.py
@@ -289,7 +289,7 @@ class ComposeBackend(BackendInterface):
     def _write_docker_compose(self, warnet):
         compose = {
             "version": "3.8",
-            "name": "warnet",
+            "name": warnet.network_name,
             "networks": {
                 warnet.network_name: {
                     "name": warnet.network_name,

@willcl-ark
Copy link
Contributor Author

Yes this does create each new network with a unique subnet.

I just added the fixed subnet back in. It would seem to me to make things much easier for you on the Tor side, whilst not having much downside for us?

It's compose-only now, and not part of Warnet. (added to compose_backend here (yes I re-organised those other variables in this touch, and what!)

@mplsgrant
Copy link
Collaborator

I see some kind of caching issue for warcli network info revealed after doing a warcli network down

@willcl-ark
Copy link
Contributor Author

I see some kind of caching issue for warcli network info revealed after doing a warcli network down

This should be fixed in a new PR as it's not related to this change

@pinheadmz
Copy link
Contributor

added a commit that puts ipv4 back in the info table, so if warcli network info is called after IPs have been assigned, it makes sense:

(.venv) --> warcli network start test/data/ln.graphml --force
Warnet:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Temp dir                    ┃ Bitcoin network ┃ Warnet network name ┃ Graph                                 ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ /root/.warnet/warnet/warnet │ regtest         │ warnet              │ MultiDiGraph with 5 nodes and 9 edges │
└─────────────────────────────┴─────────────────┴─────────────────────┴───────────────────────────────────────┘

Tanks:
┏━━━━━━━┳━━━━━━━━━┳━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┓
┃ Index ┃ Version ┃ IPv4 ┃ bitcoin conf  ┃ tc_netem ┃ LN  ┃ LN Image                          ┃ LN IPv4 ┃
┡━━━━━━━╇━━━━━━━━━╇━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━┩
│ 0     │ 27.0    │ None │ -uacomment=w0 │ None     │ lnd │ lightninglabs/lnd:v0.17.5-beta    │ None    │
│ 1     │ 27.0    │ None │ -uacomment=w1 │ None     │ lnd │ lightninglabs/lnd:v0.18.0-beta    │ None    │
│ 2     │ 27.0    │ None │ -uacomment=w2 │ None     │ lnd │ lightninglabs/lnd:v0.18.0-beta    │ None    │
│ 3     │ 27.0    │ None │ -uacomment=w2 │ None     │ cln │ elementsproject/lightningd:v23.11 │ None    │
│ 4     │ 27.0    │ None │ -uacomment=w3 │ None     │     │                                   │         │
└───────┴─────────┴──────┴───────────────┴──────────┴─────┴───────────────────────────────────┴─────────┘
(.venv) --> warcli network info
Warnet:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Temp dir                    ┃ Bitcoin network ┃ Warnet network name ┃ Graph                                 ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ /root/.warnet/warnet/warnet │ regtest         │ warnet              │ MultiDiGraph with 5 nodes and 9 edges │
└─────────────────────────────┴─────────────────┴─────────────────────┴───────────────────────────────────────┘

Tanks:
┏━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┓
┃ Index ┃ Version ┃ IPv4        ┃ bitcoin conf  ┃ tc_netem ┃ LN  ┃ LN Image                          ┃ LN IPv4     ┃
┡━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━┩
│ 0     │ 27.0    │ 10.1.21.205 │ -uacomment=w0 │ None     │ lnd │ lightninglabs/lnd:v0.17.5-beta    │ 10.1.21.214 │
│ 1     │ 27.0    │ 10.1.21.209 │ -uacomment=w1 │ None     │ lnd │ lightninglabs/lnd:v0.18.0-beta    │ 10.1.21.206 │
│ 2     │ 27.0    │ 10.1.21.210 │ -uacomment=w2 │ None     │ lnd │ lightninglabs/lnd:v0.18.0-beta    │ 10.1.21.211 │
│ 3     │ 27.0    │ 10.1.21.207 │ -uacomment=w2 │ None     │ cln │ elementsproject/lightningd:v23.11 │ 10.1.21.212 │
│ 4     │ 27.0    │ 10.1.21.208 │ -uacomment=w3 │ None     │     │                                   │             │
└───────┴─────────┴─────────────┴───────────────┴──────────┴─────┴───────────────────────────────────┴─────────────┘

@m3dwards
Copy link
Collaborator

Closing for now because of the new structure which may not have RPC

@m3dwards m3dwards closed this Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

tank IPs are still 100.0.0.0/8 in K8s
5 participants