test: add testkit

[gavinbarnard]

Please let me know if you want this testkit. I wrote it to test while I'm making updates.

create_test_env.sh - creates the runtime environment

launch.sh - builds and starts the pool services for testing, $1=branchname $2=buildtype if not specified they will default to master/debug

run_integ_tests.sh - run all integration tests or specify a single test file to run at $1

launch_and_test.sh - launches, and runs integration tests, and then kills the environment takes the same parameters as launch.sh

kill_all_test_env_processes.sh - used to kill any stray processes

A private stagenet with fixed diff of 300000 can pass all tests in two minutes with a hashrate of 2500h/s

If you want to setup your own stagenet see: example stagenet https://github.com/moneroexamples/private-testnet/blob/master/make_private_stagenet.sh

If you start an empty blockchain stagenet or testnet you may want to edit the src/hardforks/hardforks.cpp before you compile your private [stage|test]net to quickly get to the latest version. Mine in monerod after the [stage|test]net is setup, and then start mining with the pool software after hitting the latest version of the block. See the below changes to stagenet_hard_forks. Only do this on a private [state|test]net.

const hardfork_t stagenet_hard_forks[] = {
  // version 1 from the start of the blockchain
  { 1, 1, 0, 1341378000 },

  // versions 2-7 in rapid succession from March 13th, 2018
  { 2, 2, 0, 1521000000 },
  { 3, 3, 0, 1521120000 },
  { 4, 4, 0, 1521240000 },
  { 5, 5, 0, 1521360000 },
  { 6, 6, 0, 1521480000 },
  { 7, 7, 0, 1521600000 },
  { 8, 8, 0, 1537821770 },
  { 9, 9, 0, 1537821771 },
  { 10, 10, 0, 1550153694 },
  { 11, 11, 0, 1550225678 },
  { 12, 12, 0, 1571419280 },
  { 13, 675405, 0, 1598180817 },
  { 14, 676125, 0, 1598180818 },
};

[jtgrassie]

I like the intent behind this, but I have a couple of gripes:

1) tools/local and test/integ seem odd places to store all this. Really it should all be under one tests/ directory so as not to pollute the rest of the repository. 2) I'd expect it to be driven from the Makefile (so being able to run make test or similar). 3) I'd expect it to be self contained (i.e. how the Monero functional_tests are organized and run). 4) Have you tested this across multiple versions of Python and operating systems?

It's also already very simple to just use a different pool.conf and xmrig conf for each network/test-type one wants to perform (which is what I already do), hence I'm not completely sold on the value of this. That said, if you can address the above points and confirm you'll ensure this works and is tested across a variety of systems, and plan to maintain it, I won't be a blocker to merging.

[gavinbarnard]

1. definitely can merge this path set is a pattern from work
2. Can add there
3. I'll review how this is setup
4. Just ubuntu 20.04 and python 3.7 so far, please let me know which platforms need testing.

[jtgrassie]

Just ubuntu 20.04 and python 3.7 so far, please let me know which platforms need testing.

I test the pool on clean versions of: Debian stable, Ubuntu 16, 18 (x86_64+ARM), 20, macOS 10.14 and FreeBSD release + current. But as this test stuff is mostly Python, I'd recommend at least testing on 2.7+ (many OSs still default to 2.7).

From a quick glance at your shell scripts, they look mostly portable but there's quite a few things will want changing as are not particularly robust (e.g. places where you're grep'ing PIDs are erroneous).

[gavinbarnard]

I can do all of those but macOS due to lack of hardware.

Any chance we can drop the 2.7 python requirement. 2.x is sunset, but I could test with 3.5/6/7/8 I am not sure all the libraries are compatible in 2.x.

[jtgrassie]

Any chance we can drop the 2.7 python requirement. 2.x is sunset, but I could test with 3.5/6/7/8 I am not sure all the libraries are compatible in 2.x.

Yes I'm well aware of the status of python 2, but as I mentioned, it's still the default install on many distros. That's one of the unfortunate problems of releasing python code (and will be for years to come): making things work on 2+3. It's your call though, because as I also mentioned, I'm not sold on the need for this test code (I test in other, simpler ways), and so you'll be the one that ends up supporting/maintaining this test code if it gets merged.

I can do all of those but macOS due to lack of hardware.

Oh don't worry about macOS, I can't imagine anyone uses macOS to run a pool on! I only test the pool on a mac as I have a couple of old ones kicking about.

[gavinbarnard]

Closing this out per our discussion on IRC

[trasherdk]

Python 2.7 is only option on Slackware python-2.7.17-x86_64-1_slack14.2 :smiley: