Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build/cmd/gomote: configure instance by an environment variable #29037

Open
bcmills opened this issue Nov 30, 2018 · 10 comments
Open

x/build/cmd/gomote: configure instance by an environment variable #29037

bcmills opened this issue Nov 30, 2018 · 10 comments
Assignees
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Nov 30, 2018

I've been doing a fair amount of gomote-based debugging for the cmd/go file-locking changes, and wrote the following script to improve the ergonomics of gomote commands:

~/bin/mote:

#!/bin/sh

SUBCMD=$1
shift
gomote "${SUBCMD}" "${GOMOTE}" "$@"

That allows me to eliminate stutter in gomote commands and still keep them repeatable.
Instead of:

$ export GOMOTE=$(gomote create darwin-amd64-10_12)
$ gomote push $GOMOTE && gomote run $GOMOTE go/src/make.bash
$ gomote run $GOMOTE go/bin/go test -short cmd/go

I can run:

$ export GOMOTE=$(gomote create darwin-amd64-10_12)
$ mote push && mote run go/src/make.bash
$ mote run go/bin/go test -short cmd/go

However, there is no fundamental reason why this should be a separate bash script.
@bradfitz, @dmitshur, @aclements: what do you think of pulling this into gomote proper?

@gopherbot gopherbot added this to the Unreleased milestone Nov 30, 2018
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Nov 30, 2018
@bradfitz
Copy link
Contributor

I'd be fine with a shorter mode. Got a concrete proposal?

Keep in mind there can be multiple gomote sessions open at once.

Would you do the short magic based on $GOMOTE being set? On there being only one gomote session?

@bcmills
Copy link
Contributor Author

bcmills commented Nov 30, 2018

Keep in mind there can be multiple gomote sessions open at once.

Indeed: for example, I've been using them to test plan9, solaris, and darwin concurrently (in separate terminals).

Would you do the short magic based on $GOMOTE being set? On there being only one gomote session?

I think I would start with $GOMOTE exclusively. That works with multiple sessions, and it's trivial to run export GOMOTE=$(gomote create […]) instead of just gomote create […].

(Perhaps we could also allow inference for singleton instances, but the failure mode of running commands on the wrong machine if you forget that you had another instance up seems potentially confusing.)

@bradfitz
Copy link
Contributor

I think I would start with $GOMOTE exclusively.

SGTM.

but the failure mode of running commands on the wrong machine if you forget that you had another instance up seems potentially confusing

Agreed. That's been my main concern in the past when I've considered something like this.

So what's the rule? If the <instance> argument to gomote {destroy,gettar,ls,ping,push,put,put13,puttar,rm,run,ssh} does not contain a hyphen, then require $GOMOTE to set and fail otherwise? But there might be some ambiguity there with some of the commands, running commands with hyphens (pkg-config?), or moving around files with hyphens.

Or $GOMOTE != "" means that the <instance> argument cannot be specified (can't override $GOMOTE)?

@bcmills
Copy link
Contributor Author

bcmills commented Nov 30, 2018

Or $GOMOTE != "" means that the <instance> argument cannot be specified (can't override $GOMOTE)?

That seems like the simplest approach: it's easy enough to run GOMOTE='' gomote […] to bypass it for single commands, and then we don't have to worry about distinguishing instance names from commands.

@aclements
Copy link
Member

I don't want to let the perfect be the enemy of the good here, but I find gomote run to be difficult to use in a lot of ways. Not just that it requires the hostname, but how it implements path lookup and how it escapes things.

I use this wrapper myself, which gives me a more normal PATH (plus go/bin, which I generally want), and implements ssh-like argument splitting (which has its own problems, but at least I'm used to it):

#!/bin/bash

if [[ -z "$VM" ]]; then
    echo "VM variable not set" >&2
    exit 1
fi

pre='PATH=$PATH:$PWD/go/bin &&'

# Duplicate the quoting behavior of ssh.
exec gomote run $VM /bin/sh -c "$pre $*"

@mknyszek
Copy link
Contributor

I'm currently working on an extension to the gomote command to shorten the commands a lot by managing some state. The goal is to also allow manipulation of several gomotes at once (a la https://github.com/mknyszek/goswarm).

@mknyszek
Copy link
Contributor

@aclements I'm also working on a fix for the PATH issue.

@mknyszek mknyszek self-assigned this Jul 19, 2022
@bcmills
Copy link
Contributor Author

bcmills commented Jul 19, 2022

@mknyszek, if you're working on gomote PATH issues, also be aware of some CLs in flight: https://go.dev/cl/418104 (@ianlancetaylor) and https://go.dev/cl/367896 (me). 🙃

@mknyszek
Copy link
Contributor

Thanks. I'm mostly focused on the gomote frontend, so based on those CLs I don't think we're interfering with each other much. Talking with @cagedmantis, I think the PATH issues with run I'm gonna fix in the gomote command itself by automatically setting a reasonable baseline path (/bin, etc.). The issues goes all the way down to the stage0 binary, which is run without a PATH, and then everything spawned from it (which is everything) by default doesn't have a PATH, unless you create a shell.

@mknyszek
Copy link
Contributor

Just to avoid confusion and duplicate work, I tried to lay out what I planned to work on and what I discussed so far with Carlos in #53956. I had it in a doc, but I figured it would be more visible as an issue (and I can add it to the hotlist). Feel free to comment there if you have opinions. Nothing about that is intended to be set in stone, but more of a decent starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest
Projects
None yet
Development

No branches or pull requests

5 participants