Merge branch ‘gh-pages-deploy’ into gh-pages

a3b81642f9064ea2ca2da5a36d467ec640ded90a

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

remove redundant dependencies from migration tests

weekly report - week 03

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

fixup! 8c4c43d35 use ‘tableName’ instead of ‘fieldName’

fixup! 8c4c43d35 use ‘tableName’ instead of ‘fieldName’

Merge #1190

1190: Add database migration test r=KtorZ a=rvl

Relates to #1177.

Overview

Adds a migration test that can be run against different versions of the wallet.

The idea is to use an api client to set up the database on a wallet server running one version. Then start up the wallet server on the current version and use the api client to check the database.

All the possible upgrade paths from previous released versions to the current version could be exhaustively tested. However, in this initial version, only the direct upgrade from each release to latest is tested.

At present the testing actions are quite basic. It first restores a wallet, migrates, then lists the wallets.

The migration tests are run as part of nightly CI.

Co-authored-by: Rodney Lorrimar [email protected] Co-authored-by: KtorZ [email protected]

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

use latest available genesis config for ALL migration tests

Use the genesis block from the latest release only. Having different genesis block (hash) across releases will basically make all wallets incompatible with each others. Prior to now workers would simply loop ad-infinitum trying to rollback to (0, 0).

Now, workers would simply exit complaining about a different genesis hash. To work around this, we use the same genesis configuration for all nodes in the migration tests, so that the hash remains the same across all tests.

control genesis hash inside known wallet upon restarting workers

control genesis hash inside known wallet upon restarting workers

control genesis hash inside known wallet upon restarting workers

Merge branch ‘gh-pages-deploy’ into gh-pages

5b06b37f492bc84091ff24069f8feeac9a8a4a71

Merge #1266

1266: Add a manual DB migration step for active_slot_coeff. r=KtorZ a=jonathanknowles

Issue Number

#1251

Overview

This PR:

• [x] Adds the ability to perform manual DB migration actions after connecting to a SQLite database.
• [x] Uses this ability to detect whether or not the active_slot_coeff field is present in the checkpoint table.
• [x] Adds the active_slot_coeff field manually, if it was not present already, using a default value that is passed down from the network layer.
• [ ] Figure out the cause of repeated log entries of the form:

[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Try rolling back to 0.0
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Rolled back to 0.0

Comments

Co-authored-by: Jonathan Knowles [email protected] Co-authored-by: KtorZ [email protected]

Merge #1266

1266: Add a manual DB migration step for active_slot_coeff. r=KtorZ a=jonathanknowles

Issue Number

#1251

Overview

This PR:

• [x] Adds the ability to perform manual DB migration actions after connecting to a SQLite database.
• [x] Uses this ability to detect whether or not the active_slot_coeff field is present in the checkpoint table.
• [x] Adds the active_slot_coeff field manually, if it was not present already, using a default value that is passed down from the network layer.
• [ ] Figure out the cause of repeated log entries of the form:

[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Try rolling back to 0.0
[cardano-wallet.wallet-engine:Info:29] [2020-01-16 09:05:14.78 UTC] e834cdb3: Rolled back to 0.0

Comments

Co-authored-by: Jonathan Knowles [email protected] Co-authored-by: KtorZ [email protected]

avoid name duplication for fields in manual migrations

• And re-located logging output near to other logs in the meantime

avoid name duplication for fields in manual migrations

• And re-located logging output near to other logs in the meantime

Merge branch ‘gh-pages-deploy’ into gh-pages

5e6ff00f3f18f8a32dfd0c474a0521bf53d08f44

Merge pull request #1278 from input-output-hk/rvl/1273/registry-tracer

Wallet: Change Trace IO Text -> Tracer IO WalletLog

Try #1278:

Typed ‘Tracer’ for workers

• Added the key and msg to the worker context as a type-family
• Simplified how the tracer got passed down to the worker context
• Merged ‘StakePoolLayerLog’ and ‘StakePoolMonitorLog’ into a single ‘StakePoolLog’
• Reworked a bit top-levels tracers for more consistency

Merge branch ‘gh-pages-deploy’ into gh-pages

84bf9935dda026f2e66def0922625b5b74b479b1

Bump iohk-nix to latest master

Fix pc/w64 nixpkgs issue

1. Rename x86_64-pc-mingw32 to x86_64-w64-mingw32 in release.nix.

2. Let iohk-nix rust-packages use its own package sets. Pass through the system variable, but don’t do any cross-compiling whatsoever.

fixup! unused variable in Cardano.Wallet.Network

rename ‘MsgMetadata’ to ‘MsgWalletMetadata’

Merge #1275

1275: Removing lenses from integration tests (state, addressPoolGap, balance*) r=KtorZ a=piotr-iohk

Issue Number

#1237

Overview

• b43b949ffa63acf4e7f8a7d88da0d7df92dc1844 Remove addressPoolGap lens

• 24d318ca75b8eccf732f1b0bfbbf01fde4944e92 Remove state lens

• 446f7812916ca96380fb7f4946a4a057e6f7b634 Remove balance lenses: - byronBalanceAvailable - balanceAvailable - byronBalanceTotal - balanceTotal - balanceReward

• 9d2e67981eeb63698dc69994c758013601e8802f get rid of duplicate magic constants

  • addressPoolGapMin
  • addressPoolGapMax
  • passphraseMinLength
  • passphraseMaxLength

Also got rid of an extra print statement that slipped through

Comments

Co-authored-by: Piotr Stachyra [email protected] Co-authored-by: KtorZ [email protected]

get rid of duplicate magic constants

• addressPoolGapMin
• addressPoolGapMax
• passphraseMinLength
• passphraseMaxLength

Also got rid of an extra print statement that slipped through

use total block production instead of epoch length for performance

use total block production instead of epoch length for performance

use total block production instead of epoch length for performance

Merge branch ‘gh-pages-deploy’ into gh-pages

8b3b8c5a07d1665ef615aca4a0ed9f3d832c5a08

Merge branch ‘gh-pages-deploy’ into gh-pages

65ce087223d8d0f690bc86f382eb2e515e28c6e4

Merge #1259

1259: Calculate pool desirability according to delegation design spec r=Anviking a=Anviking

Issue Number

#1250

Overview

• [x] New completely isolated module implementing ~nonMyopicMemberRewards~ desirability and related helper functions from the spec.
• [x] Some simple unit/property tests as sanity checks

Comments

• To be squashed before merging. Leaving a couple un-squashed for now, for history.

⬇️ Now reverted. Coming in a later PR! (Task #1276 )

Work in progress example ranking (without averaging, and with some hard-coded slightly off values)

With basic averaging (not exponential):

A newer screenshot (lots of 1PCT pools at the top now):

Co-authored-by: Johannes Lund [email protected] Co-authored-by: KtorZ [email protected]

Merge #1272

1272: Fix failed metadata download error handling r=KtorZ a=rvl

Relates to #1256.

Overview

• Add more error handling, logging, clean up.
• Adds SSL root certificates to the docker image so that metadata registry downloads work.

Co-authored-by: Rodney Lorrimar [email protected]

Remove prop_oversaturationDoesNotInfluenceDesirability

It is currently a tautology. May be re-added when there is a stake-field in the Pool record.

Tweak comment

revise apparent performance specification and documentation

We’ll now allow pool performance to go beyond 1, effectively showing if pools are over performing.

revise apparent performance specification and documentation

We’ll now allow pool performance to go beyond 1, effectively showing if pools are over performing.

revise apparent performance specification and documentation

We’ll now allow pool performance to go beyond 1, effectively showing if pools are over performing.

additional property to visualize the influence of the production on the performance