Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

docs/research/flows.md, line 38 at r1 (raw file):

https://github.com/istalker2/ac-etcd

I'm not 100% sure if linking to 3rd party repo (looking from AC repo perspective) is right there, but it's not that I'm against it.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 9 unresolved discussions.

docs/research/flows.md, line 5 at r1 (raw file):

Flow is a way to designate a part of AC resource graph (i.e. its subgraph) and then use
it as a atomic in other parts of a graph. Thus the deployment of a bigger system may be

as a atomic seems to not be correct. as an atomic, but I would also change atomic to vertex, so my final proposal is as vertex.

docs/research/flows.md, line 13 at r1 (raw file):

and an application, that depends on it, both database and the application become such
components and the main graph has just these two nodes, whereas there are separate
subgraphs for each of them. If then one want to change the database subgraph he is free

s/If then one want/If then one wants

docs/research/flows.md, line 14 at r1 (raw file):

components and the main graph has just these two nodes, whereas there are separate
subgraphs for each of them. If then one want to change the database subgraph he is free
to do say without a need to make any changes to the application subgraph since it doesn't

s/say/so

docs/research/flows.md, line 18 at r1 (raw file):

whole.

Flows are a means to define such components, their scope within the graph and their

s/are a means/are means

docs/research/flows.md, line 26 at r1 (raw file):

  AppController CLI
* Can be replicated, i.e. produce more than one deployment of the subgraph
* Each flow replica has a unique name which can be substituted into dependent resource

probably s/substituted into/substituted with

docs/research/flows.md, line 27 at r1 (raw file):

* Can be replicated, i.e. produce more than one deployment of the subgraph
* Each flow replica has a unique name which can be substituted into dependent resource
  names or anywhere in their definition. Thus each flow replica might produce both

I don't understand this sentence. "Each flow replica has a unique name which can be substituted into dependent resource names or anywhere in their definition." I don't know what "or anywhere in their definition" means in this context.

docs/research/flows.md, line 30 at r1 (raw file):

  different resources (if the replica name is used as part of its name) and share
  common resources
* Can be parametrized. Parameter values can be used in resource defiitions the same

s/defiitions/definitions

docs/research/flows.md, line 36 at r1 (raw file):

https://docs.google.com/document/d/1UH9r9X3AaOND_KZO0Qslp6iPkt526PMDpG29B4L1sVQ/edit?usp=sharing
Not sure about putting google doc here, maybe @jnowak what do you think?

docs/research/flows.md, line 38 at r1 (raw file):

I am OK with that, google doc above makes me more nervous TBH.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 9 unresolved discussions.

docs/research/flows.md, line 38 at r1 (raw file):

GDoc can be merged when everything will be finished.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 10 unresolved discussions.

docs/research/flows.md, line 33 at r1 (raw file):

May be stable (idempotent) or not. Stable flows produce the same replica names on each run, which result in the same resource graph

I'm not sure if I understand this English :)

docs/research/flows.md, line 36 at r1 (raw file):

gdoc is ok at this stage, later we will export and merge it there.

Comments from Reviewable

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 11 unresolved discussions.

docs/research/flows.md, line 5 at r1 (raw file):

as a vertex?

docs/research/flows.md, line 6 at r1 (raw file):

Flow is a way to designate a part of AC resource graph (i.e. its subgraph) and then use
it as a atomic in other parts of a graph. Thus the deployment of a bigger system may be
split into smaller reusable components and then compose the overall deployment from these

Thus the deployment of a bigger system may be split into smaller reusable components. imo rest should be dropped.

docs/research/flows.md, line 14 at r1 (raw file):

to do this without a need to do any changes in the application subgraph

docs/research/flows.md, line 33 at r1 (raw file):

Missing explanation for unstable part even if it's opposite for same graph. Maybe this should be rephrased as: May be unstable, which results in different graphs with different replica names on each run, or stable (idempotent), resulting in same replica names (so in effect same resource graph) for each run.

Comments from Reviewable