Orchestrator knows which steps are missed, but doesn't then just do them

[m8pple]

The orchestrator is very much focused on an interactive user experience, to the point where scripting and automation is hard. Fine - that's a design decision, so the entire thing is designed around helping a human sitting at a terminal and typing in commands interactively. However, when one has to drop into the interactive mode I've always found it weird to use compared with other interactive command line interfaces. I think in part this is because the user interface is quite modal without clearly advertising it's current mode, with all the problems that brings.

The following is partially a suggestion on how to make it more user friendly, while also trying to articulate why it can be confusing.

So there are a number of steps that have to be performed in order to get a graph running, such as type linking, mapping, and composing. The need for these steps is understandable, and the ability to perform them individually can be useful, but a lot of the time there are really only two things the user wants to actually do:

1. load /app = +"ring_test.xml"
2. run /app = *

However, if you do that, it will tell you that it is not deployed:

POETS> 11:28:55.36:  23(I) load /app = "/home/dt10/POETS/Orchestrator/Tests/ReferenceXML/v4/PEP20/apps/betweeness_centrality_16_16_20_20_v4.xml"
POETS> 11:28:55.36:  20(I) The microlog for the command 'load /app = "/home/dt10/POETS/Orchestrator/Tests/ReferenceXML/v4/PEP20/apps/betweeness_centrality_16_16_20_20_v4.xml"' will be written to '../Output/Microlog/Microlog_2021_06_13T11_28_55p0.plog'.
POETS> 11:28:55.36: 235(I) Application file /home/dt10/POETS/Orchestrator/Tests/ReferenceXML/v4/PEP20/apps/betweeness_centrality_16_16_20_20_v4.xml loading...
POETS> 11:28:55.36: 933(U) File ../../Source/OrchBase/XMLProcessing/DS_XML.cpp line 490: OutputPin has indexed=true, which is not supported by orchestrator
POETS> 11:28:55.36:  65(I) Application file /home/dt10/POETS/Orchestrator/Tests/ReferenceXML/v4/PEP20/apps/betweeness_centrality_16_16_20_20_v4.xml loaded in 3361 ms.
POETS>run /app = *
POETS> 11:29:20.04:  23(I) run /app = *
POETS> 11:29:20.04:  20(I) The microlog for the command 'run /app = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_29_20p0.plog'.
POETS> 11:29:20.04: 169(W) Attempt to issue 'run' command for graph instance 'betweeness_centrality_16_16_20_20::betweeness_centrality_16_16_20_20', but it has not been deployed.

So it knows that it needs to be deployed first, and is telling you the user to do it (I'm not completely sure if that is correct - maybe initialise is done automatically).

Ok, so we try to deploy it:

POETS>deploy /app = *
POETS> 11:31:15.86:  23(I) deploy /app = *
POETS> 11:31:15.86:  20(I) The microlog for the command 'deploy /app = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_31_15p0.plog'.
POETS> 11:31:15.86: 107(W) Task betweeness_centrality_16_16_20_20::betweeness_centrality_16_16_20_20 not found

In this case it doesn't seem to realise what step needs to be performed, so the user has to realise that it needs to be composed:

POETS>compose /app = *
POETS> 11:32:16.22:  23(I) compose /app = *
POETS> 11:32:16.22:  20(I) The microlog for the command 'compose /app = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_32_16p0.plog'.
POETS> 11:32:16.22: 802(W) Graph instance 'betweeness_centrality_16_16_20_20' has not been placed. Not composing.

Now again it is telling us, it is impossible to do step X without doing Y first - it knows what Y is, but won't just do it. So we dutifully type it in:

POETS>place /tfill = *
POETS> 11:33:16.26:  23(I) place /tfill = *
POETS> 11:33:16.26:  20(I) The microlog for the command 'place /tfill = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_33_16p0.plog'.
POETS> 11:33:16.26: 324(W) Graph instance 'betweeness_centrality_16_16_20_20' has not been type-linked. Not placing.

Again, orchestrator knows that step Z is necessary for step Y, but requires the user to type it in.

POETS>tlink /app = *
POETS> 11:35:19.73:  23(I) tlink /app = *
POETS> 11:35:19.73:  20(I) The microlog for the command 'tlink /app = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_35_19p0.plog'.

Yay, it worked. So now the user has to go back up the command stack, again running each command explicitly:

POETS>place /tfill = *
POETS> 11:36:05.34:  23(I) place /tfill = *
POETS> 11:36:05.34:  20(I) The microlog for the command 'place /tfill = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_36_05p0.plog'.
POETS> 11:36:05.34: 309(I) Attempting to place graph instance 'betweeness_centrality_16_16_20_20' using the 'tfil' method...
POETS> 11:36:05.34: 302(I) Graph instance 'betweeness_centrality_16_16_20_20' placed successfully.
POETS>compose /app = *
POETS> 11:36:15.17:  23(I) compose /app = *
POETS> 11:36:15.17:  20(I) The microlog for the command 'compose /app = *' will be written to '../Output/Microlog/Microlog_2021_06_13T11_36_08p0.plog'.
POETS> 11:36:15.17: 803(I) Composing graph instance 'betweeness_centrality_16_16_20_20'...
POETS> 11:36:15.17: 806(W) Graph instance 'betweeness_centrality_16_16_20_20' compose failed. Check the microlog for details.

A-ha - so in this case it failed at the compose stage.

This modality problem is a bit better than it used to be now that rlwrap gives you up-down history, but it leads to the other problem of switching to the orchestrator, doing "up-up-up-up-return, up-up-up-up-return, up-up-up-up-return", and hoping that you are doing the correct number of ups. Usually in such scenarios you might just combine those steps together into one line, e.g. by separating with ; or something, but I don't think the orchestrator allows more than one command per line.

So the concrete suggestion is:

if the user tries to do command E, and the orchestrator knows that first commands A, B, C, and D need to be successfully completed, it should just do those steps automatically with the default parameters, and stop if any one of them fails.

That would at least remove some of the modality of the user interface, and make it less surprising and frustrating when using it interactively.

[mvousden]

I think this is more of a design-mindset thing. I'm not averse to the idea, but I do refer to this behaviour in most shells:

touch /home/mark/subdir/myfile
2> touch: cannot touch '/home/mark/subdir/myfile': No such file or directory
mkdir /home/mark/subdir
touch /home/mark/subdir/myfile

The shell could happily infer that you mean to create the directory and touch a file there... but it doesn't do it for you. There are a two main reasons for this:

• touch itself has a minimal design - GNU's touch is sitting around 500 lines (supporting all it's options). If you expanded it to check for a directory, that would be duplication with other similar tools. If you expanded it to check fstab to see if the partition you meant to write to would first be mounted, that would add even more complexity.

• The designers of the shell ecosystem want the user to know about mkdir (or similar).

Your suggestion would mean:

• Each command would need to know how and when to run every other command. The duplication could be reduced via some state manager class.

• The learning curve for a user would not be more gradual, as it kicks the can down the road ("This bucket filling placement sucks! Can't we use something better?", or "Why does this softswitch not buffer messages when I want them to?"). The user then needs to learn multiple "things", rather than distributing those things. There's value in frontloading that information, as it creates a unified interface everyone can understand.

Being reasonable, the Interactive Usage section of the Orchestrator user guide is there to alleviate the initial steep difficulty curve. The three students Graeme and I have supervised managed to go through (a variant of) this guide with little trouble.

To be clear, I'm not against your suggestion, but there's a real design decision behind why you need to vagrant init before you vagrant up without a VagrantFile.

[m8pple]

I don't necessarily expect anything to be done about this, as there are more important things I'm more just trying to capture and articulate the disconnect between the idea of the orchestrator as an explicitly interactive thing, versus the reality of trying to use it in that way.

To be honest, I wouldn't mind so much if it wasn't for the "you want to do X, but Y has not been completed yet" messages, where Y is the only way to do X. In some sense it would almost be better if they weren't there, and it just said "sorry, I can't do that, but I don't know why". It would actually make it worse from a useability and productivity perspective, but slight better from a user satisfaction perspective.

So to be clear: I have zero interest in using the orchestrator interactively in this way, and would far prefer development effort goes into improvements which made it easier to use via automation and scripting.

[mvousden]

Fair enough, an interesting discussion.

[heliosfa]

From @DrongoTheDog "The granularity of the Orchestrator is far finer than any sane person would ever want. A sane person should be writing batch files, using them and forgetting what is in them."