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

internal/libhive: client definitions, metadata file loading, client-roles #443

Merged
merged 5 commits into from
Mar 16, 2021

Conversation

protolambda
Copy link
Contributor

Changes:

  • Load clients into single collection of definitions, don't separate versions, images, metadata into different maps.
  • List the definitions in the API clients listing, except docker image: metadata such as the role is important for test-suites, docker-strings not so much.
  • Update client loading, no changes required to clients. Default metadata is an "eth1" role.

Eth1 simulators should update like:

	suite.Add(hivesim.ClientTestSpec{
+               Role: "eth1',
		Run: runDiscoveryTest,
		Parameters: hivesim.Params{
			"HIVE_LOGLEVEL": "5",
		},
	})

To ensure the test only ever runs against the intended kind of client. If the test runner does not provide eth2 client names by accident, the old behavior still works.

Next, we can make other tests that consume "beacon", "validator", "shard-node", etc. roles.

For an Eth2 testnet, or Eth1-Eth2 merge test, multiple roles may be involved. The CLI does not change, just give it a list of involved clients. The simulator can e.g. find the first beacon node, first validator, first shard-node to run a simple testnet. Or parametrize by role, to try different combinations (e.g. for Eth2 validator <> beacon API tests, and beacon <> eth1 RPC tests).

TODO:

  • Update docs to describe hive.yaml in clients.
  • More testing. Chicken-egg problem when using it in a simulator and having it in hive.
  • Suite files only list the client versions. I kept that as-is, since changing it breaks viewing of existing suite-outputs, and the recent versions support broke the old format already (but gracefully). We have full client info now though, maybe worth listing it in the suite output?
  • Thinking of best build-target approach. The metadata file is useful to define builds of the same client and version, but different compile-time arguments (e.g. eth2 minimal/mainnet configuration choice). For another later PR.

@fjl
Copy link
Collaborator

fjl commented Feb 12, 2021

I think we should support multiple roles per client.

@fjl fjl force-pushed the meta-and-roles branch from bec0b35 to d173d13 Compare March 15, 2021 14:24
@fjl fjl merged commit 9c4ae0d into ethereum:master Mar 16, 2021
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.

2 participants