raiden icon indicating copy to clipboard operation
raiden copied to clipboard

Raiden Settings Management - to be able to set fees and monitoring during run time

Open Dominik1999 opened this issue 4 years ago • 6 comments

Abstract

As a user I want to be able to set fees and enable monitoring per channel on my Raiden node. A user wants to set those settings while Raiden is running via the command line and via the WebUI. The user also wants to see how much she earned with fees.

This is a meta issue and needs to be divided into several sub-issues to be tracked on the Raiden Client project board.

Motivation

At the moment a user can only set fees and monitoring for all channels during start-up and cannot change those settings anymore. For monitoring a user might want to be able to set this when there is a critical amount of balance on her channel side or when she plans to go to vacation. The same flexibility is requested when it comes to setting fees. Different channels might have different fee schedules to be set.

Specification

to be defined

  • [ ] architecture to be specified with @rakanalh

Backwards Compatibility

It should be backwards compatible.

Sub-Tasks:

  • [ ] https://github.com/raiden-network/raiden/issues/4755
  • [ ] https://github.com/raiden-network/raiden/issues/4951

Dominik1999 avatar Oct 01 '19 13:10 Dominik1999

Just two links:

  • https://github.com/raiden-network/raiden/issues/4951
  • https://github.com/raiden-network/raiden/issues/4755

palango avatar Oct 02 '19 09:10 palango

My thoughts on this issue:

  • We have a table in the DB that looks like:
CREATE TABLE setting (
    name VARCHAR[24],
    value TEXT,
    chain_identifier int NULL,
    token_network_identifier VARCHAR[32] NULL,
    channel_identifier VARCHAR[32] NULL,
);
  • On raiden's bootstrap, all settings in settings.py would be populated into that table.
  • Query function would look like this:

def get_setting(name, canonical_identifier):
    query_arg_names = ['name']
    query_arg_values = [name]
    if canonical_identifier.chain_id is not None:
        query_arg_names.append('chain_id')
        query_arg_values.append(canonical_identifier.chain_id)

    if canonical_identifier.token_network_id is not None:
        query_arg_names.append('token_network_identifier')
        query_arg_values.append(canonical_identifier.token_network_id)

    if canonical_identifier.channel_id is not None:
        query_arg_names.append('channel_identifier')
        query_arg_values.append(canonical_identifier.channel_id)

    while query_arg_values:
        ## Perform query using all `query_arg_names` and `query_arg_values`
        result = query()

        if result:
            return result
        else:
            # Pop the last element so that we fallback
            # to query the upper level value
            query_arg_names = query_arg_names[:-1]
            query_arg_values = query_arg_values[:-1]

    return None

The idea behind this is that, it enables us to query a certain value for a channel. If the value for a specific channel does not exist, then we remove the channel identifier and try to query again with network_identifier. We keep poping off arguments from the list until we're left with a query that tries to see if a setting with a certain name exists regardless of which chain/network/channel we want (we tried the values before and failed to find values for those). If none of the above finds any settings, we return None.

  • The setting API endpoint would let you list all settings or set a setting for a specific chain / network / channel.

rakanalh avatar Oct 11 '19 08:10 rakanalh

After some quick discussion with @rakanalh, we are considering instead to use the {Chain,TokenNetwork,Channel}State classes as the store of information about the resources themselves and just expose these attributes in the endpoints. The settings values as defined on settings.py should also be migrated to settings table on the database and treated as default parameters that are to be used when creating the specific resources.

So, quick outline of tasks:

  • Create NodeSettingsResource to represent all of the existing settings
  • Create ChainResource to represent all attributes that we want to be configurable by the user
  • Create TokenNetworkResource to represent all attributes that we want to be configurable by the user
  • Create API endpoint to get/patch Node settings/attributes
  • Create API endpoint to get/path chain settings/attributes
  • Create API endpoint for listing all Token Networks
  • Create API endpoint for get/patch/delete token network attributes
  • Create Action{Chain/Token/Channel/}Set{Attribute} state changes for all attributes that are user-configurable
  • Implement state change handlers for the above state changes

lullis avatar Oct 11 '19 10:10 lullis

After the first demo on 16th October:

Stefan wants that a hub can upgrade 1 channel or 500 channels with any parameter information at once per token network

Parameter information is fee settings (flat, prop and imbalance fee), monitoring and more (to be specified)

One important point is to think about the data structure that can reflect that general goal of setting many channels at once and also an only a single channel with all channel properties

@lullis @rakanalh is this user story sufficient for the moment?

Dominik1999 avatar Oct 16 '19 15:10 Dominik1999

Just a remark: The endpoint for the node settings should include the block confirmation interval in order to solve https://github.com/raiden-network/webui/issues/96.

manuelwedler avatar Oct 06 '20 09:10 manuelwedler

This issue should probably be respecified. Storing it in a table seems like a needless departure from what we're doing currently. Instead we should consider updating the config file.

ulope avatar Oct 20 '20 09:10 ulope