Allow for a storage node to perform planned maintenance

  • Guest
  • May 24 2019
  • Attach files
  • Mike Kirk commented
    29 Mar 01:47pm

    (SNO's can already perform planned maintenance. Knock yourself out. But if we're talking about maintenance that results in data going offline with no consequences, then...)

    This isn't a good idea.

    Rewarding SNOs that contribute to data-availability with payment and reputation... and withholding those benefits from those that don't (e.g. are offline) is a good idea. It's simple, doesn't require trust of SNO's (like a promise to come back online later), and encourages behavior that helps the Storj network (like configs that don't go down for maintenance, or that perform it quickly).

    A SNO with an offline node isn't helping the network, and shouldn't expect to maintain the same reputation as a SNO that stays online. And I'm not sure a preregistered-downtime system (like mentioned in other comments in this Idea) is something that Storj-as-a-company could endorse either. They're making availability claims to customers, and those claims can't be jeopardized by random SNO's that say "Pretty please believe me I'll be back later, trust me dude" . Storj has to start rebuilding as soon as they detect data is less durable than their guidelines.

    TL;DR - Data durability should never depend on pinky-swear-promises from SNOs

  • Pierre-Antoine Charrier commented
    3 Dec, 2019 06:59am

    I do support Valentijn van Achte's idea too! Very well explained.

  • Gorki Heister commented
    31 Oct, 2019 02:47pm

    I support Valentijn van Achte's idea!

  • Valentijn van Achte commented
    31 Oct, 2019 02:43pm

    This can be a great idea, if its worked out in a correct way.

    In my eyes i see it more like this:

    A SNO can requests a planned maintenance. This has to happen X time in advance, given ample time for the node to drain its storage resources. The time in advance should depend on the amount of data that needs to be moved + a fixed value. During this 'Drain period' the node will not be able to create tokens for this SNO. In return the network will not give any penalties to the SNO reputation. 

    When the SNO cancels the maintenance period or it auto-expires after a set X time ( This to prevent abuse ). The node will became available to the network and count towards the reputation of the SNO. ( Even if the node itself is still offline! ) If the node is operational, it will start as an empty node again! This will help as a incentive for the SNO's to keep there nodes running.

    There should also be a max. amount of scheduled maintenance per node possible. Any more will result in reputation loss for the SNO. Again this is against abuse of the system.

    This type of construction would allow any size of SNO to do major maintenance on there nodes and keep the network more stable ( less random node drops for maintenance ).

    It does have a drawback, draining a node can create a high amount of recovery traffic. And this means we will need to take a look at the costs associated with this. It might cause a lowering in reward money of recovery traffic. Or a small fee required to put a node on planned maintenance.

     

    This is just my 2cents.

     

    Kind Regards.

  • Guest commented
    2 Jul, 2019 08:02pm
    good idea, my docker gets restartet every day at the same time
  • Guest commented
    24 May, 2019 08:00pm
    Storage node can submit a planned maintenance request to the network. The network check if this can be allowed without disrupting client data according on how many other nodes have a copy of the same data on the node making the maintenance request. If conditions are met the node can go in maintenance mode for the specified amount of time
  • and 30 more