As SCT team, we would like dapp-manager to always print full state information

shadeofblue commented 1 year ago

Why?

We need to deliver a functionality where the deployment of the app components will be visualized - names and states of particular payloads. We would like to use the state information, but it's missing few information.

What needs to be changed?

When reading the state of the dapp, we would like to obtain full information about states of all payloads from the very first line, which means that instead of getting such output on the first line:

{
  "nodes":{

  },
  "app":"pending",
  "timestamp":"2023-02-14T13:52:11.253153+00:00"
}

we would rather like to receive

{
  "nodes":{
    "app":{
      "0":"pending"
    },
    "api":{
      "0":"pending"
    },
    "cache":{
      "0":"pending"
    }
  },
  "app":"starting",
  "timestamp":"2023-02-14T13:52:11.253153+00:00"
}

Right now we can even get some intermediate states like, on line 0 there's noting in nodes, on line 1 there's only app, and then on line 2 api and so on. Having everything in one call will make our lives much esier.

Acceptance Criteria

When I call dapp-manager read state, then I receive the full status information for all of the payloads
The behavior where some of the node entries appear/disappear between status updates is no longer present.

shadeofblue commented 1 year ago

@grisha87 would a stream like:

{"nodes": {"db": {}, "api": {}, "web": {}}, "app": "pending", "timestamp": "2023-03-29T06:04:36.994804+00:00"}
{"nodes": {"db": {"0": "pending"}, "api": {}, "web": {}}, "app": "starting", "timestamp": "2023-03-29T06:04:37.523187+00:00"}

resolve the issue?

pociej commented 1 year ago

@grisha87 there is difference between node being in the state pending and not being on the list at all which represents the initial state where nothing happened to node, while pending means that demand was posted on the network. The problem with having nodes empty is that we need to parse descriptor.yaml file to know what nodes are expected to run. @shadeofblue solution solves this problem IMO.

grisha87 commented 1 year ago

@shadeofblue It does address my request partially. We will know how many nodes to expect, but when I mean "full state" information, then I would expect to have these nodes populated.

For me as a developer, the natural assumption is that there's some sort of state machine behind each node, thus a initial state (set by default) is granted. If that's not the case, then it is still my request to implement the initial state, even if that's going to be something like void (from the handbook: https://handbook.golem.network/requestor-tutorials/service-development/service-model-introduction). If I may suggest something, "initialized" would do perfectly good.

{
   "nodes":{
      "db":{
         "0":"initialized"
      },
      "api":{
         "0":"initialized"
      },
      "web":{
         "0":"initialized"
      }
   },
   "app":"pending",
   "timestamp":"2023-03-29T06:04:36.994804+00:00"
}
{
   "nodes":{
      "db":{
         "0":"pending"
      },
      "api":{
         "0":"initialized"
      },
      "web":{
         "0":"initialized"
      }
   },
   "app":"starting",
   "timestamp":"2023-03-29T06:04:37.523187+00:00"
}

This way we will not only fix the issue, but also implement a more developer-friendly response.

shadeofblue commented 1 year ago

honestly, I see no difference whatsoever in the information carried by those states... but we can create artificial (fake) state information if you wish so @grisha87

shadeofblue commented 1 year ago

@grisha87 and @shadeofblue agreed to use void values for not-yet-pending service nodes

golemfactory / dapp-manager