(FR) fix a certain version

[drandreaskrueger]

this morning, using parity-deploy resulted in

Parity/v1.11.11-stable-cb03f38-20180910/x86_64-linux-gnu/rustc1.28.0

now today after lunch, suddenly that switched to

Parity-Ethereum/v2.0.4-beta-e2e1d22-20180910/x86_64-linux-gnu/rustc1.28.0

not good:

• stuff just changes which then breaks other stuff.
• suddenly stable is switched for beta (sic!)
• results of e.g. benchmarking are not replicable anymore.

--> Feature Request: Allow parity-deploy.sh to fix one specific parity version.

[ddorgan]

There were no changes made to the docker images today or parity-deploy. You didn't change something in your setup?

[drandreaskrueger]

nope. I used the exact same setup as this morning.

[drandreaskrueger]

and that v2.0.4-beta is somehow faulty by the way.

I submitted 20000 transactions, as usual, but (while v1.11.11-stable processed all of them...) this new client
v2.0.4-beta processes only ~7000 transactions, and then ignores the rest, and falls down to 128 seconds blocktimes:

./tps.py 

versions: web3 4.3.0, py-solc: 2.1.0, solc 0.4.24+commit.e67f0147.Linux.gpp, testrpc 1.3.4, python 3.5.3 (default, Jan 19 2017, 14:11:04) [GCC 6.3.0 20170118]
web3 connection established, blockNumber = 4, node version string =  Parity-Ethereum//v2.0.4-beta-e2e1d22-20180910/x86_64-linux-gnu/rustc1.28.0
first account of node is 0x321130150bF376dAa19bE381EC82F5021fb06251, balance is 0 Ether

nodeName: Parity, nodeType: Parity, consensus: ???, network: 17, chainName: myaura, chainId: 17

Block  4  - waiting for something to happen
(filedate 1536673280) last contract address: 0x38399c0692A5d9f3f4b566465c58E5054c3B56D0
(filedate 1536673304) new contract address: 0x20E39316A505AB26ea329A6b8609b7D0F0A51F03

blocknumber_start_here = 5
starting timer, at block 5 which has  1  transactions; at timecode 2211.429480718
block 5 | new #TX 611 / 8000 ms =  76.4 TPS_current | total: #TX  612 /  8.2 s =  74.7 TPS_average
block 6 | new #TX 791 / 8000 ms =  98.9 TPS_current | total: #TX 1403 / 16.5 s =  85.1 TPS_average
block 7 | new #TX 727 / 8000 ms =  90.9 TPS_current | total: #TX 2130 / 24.3 s =  87.6 TPS_average
block 8 | new #TX 734 / 8000 ms =  91.8 TPS_current | total: #TX 2864 / 32.3 s =  88.5 TPS_average
block 9 | new #TX 725 / 8000 ms =  90.6 TPS_current | total: #TX 3589 / 40.3 s =  89.0 TPS_average
block 10 | new #TX 728 / 8000 ms =  91.0 TPS_current | total: #TX 4317 / 48.4 s =  89.3 TPS_average
block 11 | new #TX 719 / 8000 ms =  89.9 TPS_current | total: #TX 5036 / 56.3 s =  89.4 TPS_average
block 12 | new #TX 1496 / 24000 ms =  62.3 TPS_current | total: #TX 6532 / 80.8 s =  80.8 TPS_average
block 13 | new #TX 609 / 8000 ms =  76.1 TPS_current | total: #TX 7141 / 88.4 s =  80.8 TPS_average

block 14 | new #TX   0 / 128000 ms =   0.0 TPS_current | total: #TX 7141 / 216.4 s =  33.0 TPS_average
block 15 | new #TX   0 / 128000 ms =   0.0 TPS_current | total: #TX 7141 / 343.9 s =  20.8 TPS_average
block 16 | new #TX   0 / 128000 ms =   0.0 TPS_current | total: #TX 7141 / 471.8 s =  15.1 TPS_average
block 17 | new #TX   0 / 128000 ms =   0.0 TPS_current | total: #TX 7141 / 599.8 s =  11.9 TPS_average

You can try it yourself, and easily, with my new Amazon AWS image:

https://gitlab.com/electronDLT/chainhammer/blob/master/reproduce.md#readymade-amazon-ami

[drandreaskrueger]

docker hub f***up ?

on that mentioned AWS machine:

docker kill $(docker ps -q)
docker rm $(docker ps -a -q)
docker rmi $(docker images -q)

docker run parity/parity:stable

Unable to find image 'parity/parity:stable' locally
stable: Pulling from parity/parity
3b37166ec614: Pull complete 
504facff238f: Pull complete 
ebbcacd28e10: Pull complete 
c7fb3351ecad: Pull complete 
2e3debadcbf7: Pull complete 
662daf166064: Pull complete 
a60e70b50be1: Pull complete 
5adc87f86a2d: Pull complete 
Digest: sha256:eec8de6d7fe501268b02e02840a24d6f444a977d60e2946613b38b41f2f0708a
Status: Downloaded newer image for parity/parity:stable

2018-09-11 15:01:20 UTC Starting Parity-Ethereum/v2.0.4-beta-e2e1d22-20180910/x86_64-linux-gnu/rustc1.28.0
...

docker run parity/parity:stable but out comes v2.0.4-beta

[drandreaskrueger]

suggestion:

parity-deploy.sh --parityversion v1.11.11

[ddorgan]

@drandreaskrueger Can you please check with the latest master of parity-deploy please.

Also parity-ethereum 2.x will become stable at some stage today or tomorrow. I've also made an update to remove it relying on openssl which should fix the key issues.

[drandreaskrueger]

please check with the latest master of parity-deploy please.

Yes, can try. Tuesday. Or you take my AMI, and update it yourself to your newest code.

parity-ethereum 2.x will become stable

But that v2.0.4-beta is somehow faulty, see this - the experiment breaks after not even half of the transactions have gone through.

[drandreaskrueger]

please check with the latest master of parity-deploy please.

Done. Also updated in my newest AMI image v29.

---

I have made an issue about the faulty docker parity:stable v2.0.5

openethereum/parity-ethereum#9582

---

To make such problems disappear in the future, I suggest a switch

parity-deploy.sh --parityversion v1.11.11

[ddorgan]

Late reply sorry. You can use the -r (release) flag to use any version you want. e.g in this case:

./parity-deploy.sh --config aura -r v1.11.11

[drandreaskrueger]

the -r (release) flag to use any version you want

hooray, that is exactly what I meant.

Thanks.

[ddorgan]

Great to hear!

[drandreaskrueger]

Actually, even with the switch -r v1.11.11, I still have to manually edit the generated .yml file, otherwise docker-compose up uses the stable version:

sudo ./clean.sh
./parity-deploy.sh --config dev -r v1.11.11
docker-compose up

Pulling host1 (parity/parity:stable)...

stable: Pulling from parity/parity
3b37166ec614: Pull complete
...7f680989e46e: Pull complete
Digest: sha256:2860e5665d5ea3b56e4942c51be482321bc97a6e5acdb3d7a0a109de5a3d39c7
Status: Downloaded newer image for parity/parity:stable
Recreating host1 ... done
Attaching to host1
host1    | Loading config file from /parity/authority.toml
host1    | Error upgrading parity data: CannotCreateConfigPath
host1 exited with code 1

This way, all is cool:

sudo ./clean.sh 
./parity-deploy.sh --config dev -r v1.11.11

Custom parity build set: v1.11.11
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3856  100  3856    0     0   2622      0  0:00:01  0:00:01 --:--:--  2621
Release selected is: v1.11.11
Parity 1.11.11 already installed
using instantseal
read EC key

then I edit the output:

sed -i 's/parity:stable/parity:v1.11.11/g' docker-compose.yml
docker-compose up

Pulling host1 (parity/parity:v1.11.11)...
v1.11.11: Pulling from parity/parity
8ee29e426c26: Pull complete
...
Digest: sha256:e70608eea5f87da3c3da811de59202ef35706c4f1069a155543497fb6791f851
Status: Downloaded newer image for parity/parity:v1.11.11
Creating host1 ... done
Attaching to host1
host1    | Loading config file from /parity/authority.toml
host1    | 2018-12-03 17:52:20 UTC Starting Parity/v1.11.11-stable-cb03f38-20180910/x86_64-linux-gnu/rustc1.28.0
...

and it starts up "Parity/v1.11.11-..."

P.S.: For both attempts I am using git checkout a76a2f1b7173ff5d138e0cb66efdb939bfe33aab because of this issue #85

[drandreaskrueger]

^ @ddorgan how are you?

[drandreaskrueger]

IMHO and for consistency, your -r v2.2.3 switch should not only download that parity binary, but also and foremost always do this: sed -i 's/parity:stable/parity:v2.2.3/g' docker-compose.yml

[ddorgan]

@drandreaskrueger yip, there was an issue were some docker images were being created inconsistently but this is resolved. Also I've just used ethstore/ethkey for key generation now and just use the release version for docker.

The problem is the changing paths of the parity binary or entrypoint between versions which is a real pain. I may just script a fix of a bunch of updates for docker images to make them all consistent.

[drandreaskrueger]

I hear you. Breaking changes are tough to navigate around.

may just script a fix of a bunch of updates for docker images to make them all consistent.

Careful however when you change the docker images, because other users might already depend on their current setup ?

Actually, I had to introduce small version dependent things now in my code, see e.g. here: https://github.com/drandreaskrueger/chainhammer/blob/04ca0b6b084ea9409f6468c7e5cb86f90eaf5b97/networks/parity-configure.sh#L56 ... and it seems to work.

[ddorgan]

@drandreaskrueger I thought a bit about this yesterday and also think it's a bad idea to go updating old images. So I added an option --entrypoint which at least makes it a lot easier to deal with older or custom images.