Skip to content
This repository has been archived by the owner on Dec 16, 2021. It is now read-only.

feat: more status command output #124

Merged
merged 48 commits into from
Dec 17, 2020
Merged

feat: more status command output #124

merged 48 commits into from
Dec 17, 2020

Conversation

strophy
Copy link
Contributor

@strophy strophy commented Aug 20, 2020

Adds more output to the status command

Issue being fixed or feature implemented

Monitor dmn status, tendermint status and service versions

What was done?

  • Track more layer 1 status info
  • Track layer 2 status info
  • Track service versions

How Has This Been Tested?

  • Test output on unregistered mn
  • Test output on registered mn
  • Test output on banned mn

Breaking Changes

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

@strophy
Copy link
Contributor Author

strophy commented Aug 20, 2020

@shumkov do you think we can get version numbers for status:services from the mn-bootstrap Config object now? Or do you want to implement org.dash.version labels in each image like the original approach here?

@shumkov
Copy link
Member

shumkov commented Aug 20, 2020

@strophy Yeah, I would add an "image" column and print ${docker.image}:${version} there.

@strophy
Copy link
Contributor Author

strophy commented Aug 24, 2020

@strophy Yeah, I would add an "image" column and print ${docker.image}:${version} there.

Like this? I don't understand the syntax you are using, this code I have written looks too ugly so I assume you mean something else... Also, should we move the sentinel image into the config?

docker-compose.yml Outdated Show resolved Hide resolved
@shumkov shumkov changed the title feat: more status output feat: more status command output Aug 24, 2020
@strophy strophy marked this pull request as ready for review August 29, 2020 22:21
@strophy
Copy link
Contributor Author

strophy commented Nov 20, 2020

OK @shumkov this has been reimplemented according to the output we specified above. We could still add some colour coding with chalk I think? Should some of these functions (like figuring out the payment queue position) be factored out into separate files to avoid repetition?

src/commands/status/core.js Outdated Show resolved Hide resolved
src/commands/status/core.js Outdated Show resolved Hide resolved
src/commands/status/core.js Outdated Show resolved Hide resolved
src/commands/status/core.js Outdated Show resolved Hide resolved
src/commands/status/core.js Outdated Show resolved Hide resolved
}
if (status === 'running') {
if (mnsyncStatus.AssetName !== 'MASTERNODE_SYNC_FINISHED') {
status = `syncing ${(blockchainInfo.verificationprogress * 100).toFixed(2)}%`;
Copy link
Member

Choose a reason for hiding this comment

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

Does verification progress include blocks syncing?

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, it is just a percentage, I think this is used in the Qt GUI. We use mnsync status to see what the current sync object is, and getblockchaininfo returns information on headers, blocks and verification progress like this:

{
  chain: 'devnet',
  blocks: 129,
  headers: 19296,
  bestblockhash: '723fd5777109cc4ee2b267aacb78f5ef808153e298d2f5b4fff9b040763f2255',
  difficulty: 4.656542373906925e-10,
  mediantime: 1603983634,
  verificationprogress: 0.01129172028045482,
  initialblockdownload: true,
  chainwork: '0000000000000000000000000000000000000000000000000000000000000104',
  size_on_disk: 80417,
  pruned: false,
  softforks: [
    { id: 'bip34', version: 2, reject: [Object] },
    { id: 'bip66', version: 3, reject: [Object] },
    { id: 'bip65', version: 4, reject: [Object] }
  ],
  bip9_softforks: {
...}

src/commands/status/core.js Outdated Show resolved Hide resolved
src/commands/status/core.js Show resolved Hide resolved
src/commands/status/index.js Outdated Show resolved Hide resolved
src/commands/status/index.js Outdated Show resolved Hide resolved
}
if (status === 'running') {
if (mnsyncStatus.AssetName !== 'MASTERNODE_SYNC_FINISHED') {
status = `syncing ${(blockchainInfo.verificationprogress * 100).toFixed(2)}%`;
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, it is just a percentage, I think this is used in the Qt GUI. We use mnsync status to see what the current sync object is, and getblockchaininfo returns information on headers, blocks and verification progress like this:

{
  chain: 'devnet',
  blocks: 129,
  headers: 19296,
  bestblockhash: '723fd5777109cc4ee2b267aacb78f5ef808153e298d2f5b4fff9b040763f2255',
  difficulty: 4.656542373906925e-10,
  mediantime: 1603983634,
  verificationprogress: 0.01129172028045482,
  initialblockdownload: true,
  chainwork: '0000000000000000000000000000000000000000000000000000000000000104',
  size_on_disk: 80417,
  pruned: false,
  softforks: [
    { id: 'bip34', version: 2, reject: [Object] },
    { id: 'bip66', version: 3, reject: [Object] },
    { id: 'bip65', version: 4, reject: [Object] }
  ],
  bip9_softforks: {
...}

src/commands/status/index.js Outdated Show resolved Hide resolved
},
} = await tendermintNetInfoRes.json();

const explorerBlockHeightRes = await fetch('https://rpc.cloudwheels.net:26657/status');
Copy link
Member

Choose a reason for hiding this comment

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

Let's check it if we use network evonet.

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've fixed this by following the same pattern as in status:core to check if an external block explorer exists for the current config before running the query. This condition will currently never be reached, since there is a testnet check/abort at the top of the command and the command can never run for local config because core never reaches IsSynced status. But this check will still be useful as platform is enabled on more networks.

Copy link
Member

@shumkov shumkov left a comment

Choose a reason for hiding this comment

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

Looks good! 👍

@shumkov shumkov merged commit 6894f1e into dashevo:master Dec 17, 2020
@shumkov shumkov deleted the status-2 branch December 17, 2020 07:48
@shumkov shumkov added this to the v0.17 milestone Dec 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants