Navigation Menu

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

lightningd: add topology and lightningd statuses #1800

Closed
wants to merge 8 commits into from

Conversation

jb55
Copy link
Collaborator

@jb55 jb55 commented Aug 3, 2018

This patchset adds a status field to getinfo. This field tracks various statuses such as the new toplogy_status in chain_toplogy:

  • TOPOLOGY_INITIALIZING
  • TOPOLOGY_SYNCING
  • TOPOLOGY_AT_TIP

These states are mapped to the "high-level" status of lightningd. Right now there's a 1-to-1 mapping between chain_topology statuses and lightningd statuses:

TOPOLOGY_INITIALIZING -> LIGHTNINGD_STATUS_INITIALIZING
TOPOLOGY_SYNCING      -> LIGHTNINGD_STATUS_SYNCING
TOPOLOGY_AT_TIP       -> LIGHTNINGD_STATUS_READY

but in the future we may want to map other subsystem statuses to lightningd's status.

See #1652 for motivation.

Fixes #1652

This is a rework of #1789 to use enums instead of bit flags for the status, and a rework of #1792 to keep track of topology's status separately as recommended by @rustyrussell.

This will be used to indicate the status of lightningd at a high-level. It will
be computed from various internal statuses such as chain_topology.

Signed-off-by: William Casarin <jb55@jb55.com>
Add topology_status

This will be used for keeping track current status of the chain topology. Right
now we track if it's initializing, syncing, or at a tip.

Suggested-by: rusty
Signed-off-by: William Casarin <jb55@jb55.com>
Set topology status to TOPOLOGY_SYNCING when adding new blocks. Right now this
happens at the same time the "Adding block ..." log happens.

Set status to TOPOLOGY_AT_TIP when syncing is finished in updates_complete.

Suggested-by: rusty
Signed-off-by: William Casarin <jb55@jb55.com>
This should give us enough flexibility for future statuses

Signed-off-by: William Casarin <jb55@jb55.com>
Will be used for rendering the status for getinfo

Signed-off-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
@rustyrussell
Copy link
Contributor

OK, I apologize for spinning my wheels on this for so long. It's not your code (which can be changed anyway), it's that the JSON API is so hard to change, we need to make sure it's (1) correct, and (2) extensible.

There are two things here:

  1. Should we fail (some/most) JSON requests until we're synced? That actually fixes the "I opened a channel but them I'm waiting for sync and I can't see it" issue which motivated this.

  2. Imagine if we indicated that our bitcoind is not on the current tip? How would we add such a status without breaking things which assumed what the status string was?

So, I think 'status: ready' is a bad API. We almost want a 'not-ready-because' field, which is clearly non-programmatic. So, maybe 'startup' and a string field? Which vanishes once we're ready? It would be a more global version of the peer billboard; later topology would post to it saying how many blocks to go, for example? And if we did the 'is bitcoind synced' test we could similarly guesstimate how we're going there. We could similarly have a gossip startup with messages, or whatever; it would all fit in the same API...

@jb55
Copy link
Collaborator Author

jb55 commented Aug 6, 2018

sounds good 👍 I'll take a new stab at this the next chance I get

@jb55 jb55 closed this Aug 6, 2018
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.

None yet

2 participants