Support to copy file from remote target to local

[koolay]

Is there any way to copy file from remote target host to local?

[umputun]

for questions and similar types of clarification, please use https://github.com/umputun/spot/discussions/categories/q-a

moved

[umputun]

the short answer is no. Technically, the copy command can be extended to support the reversed direction, and this shouldn't be a big change. However, I don't really see a valid use case for this. If you have practical cases that warrant such an extension, please share.

[koolay]

A server command outputs a string as a variable in another server command.
First copy the content from server A to the local server, and then copy it to another remote server.

[umputun]

I understand what it's technically doing, but I still struggle to see why - i.e., what problem it's trying to solve. Can you give me more details on why this deployment process needs to run something on the first server, capture the output, copy it back to local, and then copy it to another server? What is this sequence supposed to achieve?

I'm asking all of this because my goal is to keep Spot simple and minimal, avoiding the creation of another complex beast with many functions that cater to extremely rare use cases.

[koolay]

In this case, the register not work.

ssh_key: ~/.ssh/id_rsa
user: root
targets:
  master:
    hosts:
      - host: 192.168.1.10
        user: root
        port: 22
  worker:
    hosts:
      - host: 192.168.1.11
        user: root
        port: 22
tasks:
  - name: start master
    targets: [master]
    commands:
      - name: start server
        options: { sudo: true }
        script: |-
          master_token=$(cat ./start.sh | bash --start)
        register: [master_token]
  - name: start worker
    targets: [worker]
    commands:
      - name: start worker server
        options: { sudo: true }
         script: |-
           bash ./start.sh --join $master_token

[umputun]

if this is the case, it is a bug since register is supposed to work in this scenario. i'll try to reproduce it locally and investigate what's going on.

upd: this is not a bug, but intentionally designed behavior.

p.updateVars(exResp.vars, cmd, &activeTask) sets variables from command output to all commands' env in the given task.

In other words, register (or set foo=bar) is designed to work for the task's commands, not across multiple tasks. In your case, having register work cross-tasks makes sense, and I'll see what I can do about it.

[umputun]

opened a ticket for register change #196

[nickolivera]

My use case involved getting admin.conf after boostraping some kubernetes clusters, and getting the join tokens as well. I ended using scp with {local:true} to get the data, another option would have been to push to s3/vault but then it gets more complicated.