Local Host

[willr3]

We talked about having a host that executes the scripts in a local terminal. I found the magic incantation to start an interactive shell in a java Process and have a poc working.

yaml

we discussed using the mapping syntax and adding local: true which is supported but the test suite uses the one line scalar so it would help if we supported that for the local shell as well. I propose we use the !local yaml tag to tell qDup to create a local connection.

hosts:
  oneLine: !local
  multiLine:
    local: true

both of the above options will work and the shell will be transparent to the script. We should probably update Local (which uploads and downloads from the SUT) to detect a !local shell and use cp rather than rsync or scp.

Any comments or concerns?

[willr3]

@johnaohara @rvansa pinging you for feedback before I finish the POC

[rvansa]

I've already mentioned in #165 , I wouldn't use a tag here; I perceive tags as an annotation to the value that's empty in this case. Is there any issue with using plain local as a 'special' hostname?

Do you expect to support running the local shell as a different user (root@local), too?

[willr3]

I had not thought about running the local shell as a different user but I will see if that is something we could support.

I wanted to avoid a special or reserved host name so that we don't place limits on supported host names and to make it easier on the yaml parser to identify the local shell. Yaml tags start with ! which is not a valid hostname character so we avoid any potential collision. This could still work with root@!local because the parser could see that !local uses the reserved value.

The Yaml spec mentions using single exclamation marks as an application specific tag.
yaml 1.2.2 example 2.23
You are right, the example uses a value after the tag and in our case we are supporting an empty value.
The double !! places the tag in the !tag:yaml.org,2002: namespace (if I read the spec correctly) which would work but I worried about any changes to the default namespace.

You mentioned you perceive it as an annotation to an empty value and I feel that fits this use case well. We are annotating the value of the host alias as a local host shell and that annotation happens to work with an empty value. If we go on to support containers then perhaps that would be the value we annotate with !local (e.g. !local quay.io/foo/bar)

[johnaohara]

I understand the concern about using tags as meta-data for empty node values, but I think tags could be useful for expressing the intended execution environment using a shortened notation, e.g.

hosts:
  localhost-proc-user: !local
  localhost-different-user: !local root@
  remote: !remote [email protected]
  local-container: !local quay.io/foo/bar
  local-container-different-user: !local quay.io/foo/bar:user@
  remote-container: !remote  quay.io/foo/bar:[email protected]

For backward compatibility, If no tag is present, we assume !remote

local-container-different-user only would make sense starting a podman container under a specific user

Tags are intended as Type information for the application to process, in this case the Type would be the class of env. I see localhost-proc-user: !local as a "special" case, with assumed defaults for user and localhost

---

wrt other concerns

1. Do we want to support the reboot command in local mode? it doesn't make sense in that context
2. What are the risk of changing the command prompt on the local machine through a process? i.e. if qDup dies, is the user's ssh terminals left with the <_#%@_qdup_@%#_> prompt? are the risks the same as on a remote machine?
3. How would the Exec command and cmd's with async: true work? woud another Java proc be spawed to execute these in the same way a new ssh connection is opened atm?