Run resource prototype

[0xbase12]

• creation from java of deployment resource in parallel of run java resource
  This will allow to test lifecycle of new run resource in current SlipStream without affecting the functionality

[0xbase12]

Type of queries to deployment parameter resource

• Get a specific run parameter by composing a unique run-parameter-id (run-parameter/run-id%node-name%node-index%name [TODO compose unique run- parameter-id]

• Set a specific run parameter value with unique run-parameter-id [TODO compose unique run- parameter-id]

• Get updates of a specific run parameter (SSE) [TODO compose unique run- parameter-id]

• Search by filtering run-parameter for run-id XXX node-name YYY, node index ZZZ (json or SSE)

• Search by filtering run-parameter for run-id XXX parameter-name GGG (json or SSE)

• Search by filtering value of run-parameter (example search for cloud instance id done by the collector) [TODO store values also in elasticsearch and maintain value in both db => ES and zookeeper]

• How should be a difference between (mutable) runtime parameter or (immutable) run parameter [ TODO No, use ACL to let user update or not the run-parameter???]

Type of queries to run resource

• Creation of a run by giving nodes name and cloudservices, list of run parameters, runtime parameter and initial multiplicity for each node

• Start the run by using CIMI action

• To scale up/down the run, CIMI actions should be used

• How to filter active runs [TODO put state in run parameter with type Global and allow search by value]

[mebster]

How to filter active runs [TODO put state in run parameter with type Global and allow search by value]

I thought we also decided to update the state in the run, such that we can filter runs by state.

Search by filtering run-parameter for run-id XXX node-name YYY, node index ZZZ (json or SSE)

I would clarify (and perhaps separate) the call that an SSE client will make to request notifications for value updates on run-parameter for run-id XXX node-name YYY, node index ZZZ, which will map to the Zookeeper index parent node.

We also agreed that special run parameters would be created to host:

• nodename
• index set

As well as current ss: global parameters.

[schaubl]

I thought we also decided to update the state in the run, such that we can filter runs by state.

👍

[0xbase12]

Yes special run parameter type will be created, here is a list of those types:

• run (hold run global parameter)
• node (hold ids, multiplicity, etc.)
• node-instance (hold all parameters of node instance)

[konstan]

List of ss-* commands related to Run (Deployment) and queries they make.

ss-get, ss-run-get

• Get single run parameter. Expects run parameter with value. SSE capable.

  • ss-get --run run-uuid worker.1:hostname or ss-get --run run-uuid worker.1 hostname
    • GET /api/run-parameter/run-uuid%worker%1%hostname (SEE)
      or
    • GET /api/run-parameter?$filter=run-href='run/run-uuid' and node-name='worker' and node-index='1' and name='hostname' (SSE)
  • ss-get hostname (if context file is present)
    • GET /api/run-parameter?$filter=run-href='run/run-uuid' and node-name='mynode' and node-index='my-index' and name='hostname' (SSE)

• Get run parameter values from active node instances. SSE capable.

  • ss-get --run run-uuid worker ready ready state over all workers
    • GET /api/run-parameter?$filter=run-href='run-uuid' and param-type='node' and node-name='worker' and name='ids' - get active node instance ids as JSON list, then
    • PUT /api/run-parameter?$filter=run-href='run-uuid' and node-name='worker' node-index='1' or node-index='5' or ... - get values (SSE).

• Get full run. Such a get is needed on VM executors as well.

  • ss-run-get run-uuid
    • GET /api/run/run-uuid - returns run and its attributes;
    • GET /api/run-parameter?$filter=run-href='run/run-uuid' - returns run parameters with values

ss-set and alike

• ss-set worker.3:ready true, ss-display.

  • PUT /api/run-parameter/run-id%node-name%node-index%name + value

• ss-abort reason, ss-cancel-abort - sets ss:abort by name

  • PUT /api/run-parameter/run-id%name + value

• TODO: ss-scale-disk, ss-scale-resize - current implementation: sets corresponding run parameter and then updates ss:state (this triggers state transition).

ss-node-add

• TODO: ss-node-add via run action
  • PUT /api/run/uuid/scale-up + JSON; this also updates /api/run-parameter/run-uuid%node-name%multiplicity and /api/run-parameter/run-uuid%node-name%ids.

ss-node-remove

• TODO: ss-node-remove via run action
  • PUT /api/run/uuid/scale-down + JSON; this also updates /api/run-parameter/run-uuid%node-name%multiplicity and /api/run-parameter/run-uuid%node-name%ids.

[konstan]

Updated #1111 (comment)