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

Allow more granular configuration of Hermes modes of operation #1518

Closed
5 tasks done
Tracked by #1562
ancazamfir opened this issue Oct 28, 2021 · 0 comments · Fixed by #1539
Closed
5 tasks done
Tracked by #1562

Allow more granular configuration of Hermes modes of operation #1518

ancazamfir opened this issue Oct 28, 2021 · 0 comments · Fixed by #1539
Assignees
Labels
I: documentation Internal: improvements or additions to documentation O: new-feature Objective: cause to add a new feature or support O: usability Objective: cause to improve the user experience (UX) and ease using the product
Milestone

Comments

@ancazamfir
Copy link
Collaborator

ancazamfir commented Oct 28, 2021

Crate

relayer

Summary

Allow more granular configuration of hermes client operation.
[cc @mankenavenkatesh]

Problem Definition

[Principal problem is described in #1489. This issue is a first step over one track towards fixing #1489. There will be others, e.g. migration to async, that will deal with performance.]

  • client misbehaviour worker impacts performance of the packet relaying
  • there are applications that require live packets to be relayed in real-time while old packets can be left to timeout, clear at a later stage, etc. An example is injective chains that send requests periodically to get token pricing information

Proposal

Allow the user to specify at a lower granularity the mode of operation for a given instance. For this issue we want to be able to specify if client workers should run misbehaviour and/or periodic client refresh.
After an initial discussion with @romac and @adizere, the proposal here is that we take this opportunity and remove strategy and add new configuration section mode (or something else). We also add a clients and packets sections to the configuration.
Ideally the config will be changed to something like:

[global]
log_level = 'info'

[mode]

[mode.clients]
enabled = true
refresh = true
misbehaviour = true

[mode.connections]
enabled = false

[mode.channels]
enabled = false

[mode.packets]
enabled = true
clear_interval = 100
clear_on_start = true 
filter = false
tx_confirmation = true

[rest]
...

[telemetry]
...
  • for example hermes instance that runs refresh and misbehavior only
[mode]

[mode.clients]
enabled = true
refresh = true
misbehaviour = true

[mode.connections]
enabled = false

[mode.channels]
enabled = false

[mode.packets]
enabled = false

Acceptance Criteria

Ability to disable client misbehavior.
Ability to not clear packets on start.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@adizere adizere changed the title Allow more granular configuration of hermes client operation Allow more granular configuration of Hermes modes of operation Oct 28, 2021
@adizere adizere added I: documentation Internal: improvements or additions to documentation O: new-feature Objective: cause to add a new feature or support O: usability Objective: cause to improve the user experience (UX) and ease using the product labels Oct 28, 2021
@adizere adizere modified the milestones: 12.2021, 11.2021 Nov 3, 2021
@adizere adizere added P-high and removed P-high labels Nov 3, 2021
@romac romac mentioned this issue Nov 11, 2021
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: documentation Internal: improvements or additions to documentation O: new-feature Objective: cause to add a new feature or support O: usability Objective: cause to improve the user experience (UX) and ease using the product
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants