toolshed/organising
toolshed/organising
8
1
Fork 0
Code Issues 120 Pull Requests Releases Activity

crash when running commands on the "default" context for local operation #175

New Issue
Closed
opened 2021-09-25 01:12:41 +00:00 by 3wordchant · 4 comments
3wordchant commented 2021-09-25 01:12:41 +00:00
Owner
Copy Link

Steps to reproduce

  1. Set up a VPS
  2. Install abra using the installer script
  3. Run abra server add default
  4. Run abra server init default
  5. Deploy some apps

Describe the expected behavior

Step 3 does nothing because the default context already exists.

Step 4 creates ~/.abra/servers/default

Describe the current behavior

3-5 all crash with variations of:

$ abra app deploy disorganizing_work
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xa166bb]

goroutine 1 [running]:
github.com/docker/cli/cli/command.resolveDefaultDockerEndpoint(0x0)
	/go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/cli.go:324 +0x3b
github.com/docker/cli/cli/command.ResolveDefaultContext(0x7f18ddb64108, 0x30, {0xde5438, 0xc0003b52c0}, {0xec3fa0, 0xc00000e028})
	/go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/defaultcontextstore.go:65 +0x165
coopcloud.tech/abra/pkg/client.NewDefaultDockerContextStore.func1()
	/drone/src/pkg/client/context.go:124 +0x2f
github.com/docker/cli/cli/command.(*ContextStoreWithDefault).GetMetadata(0x10000c00038eeeb, {0xc00038eeeb, 0x8})
	/go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/defaultcontextstore.go:133 +0x7e
coopcloud.tech/abra/pkg/client.GetContext({0xc00038eeeb, 0x7})
	/drone/src/pkg/client/context.go:88 +0x6b
coopcloud.tech/abra/pkg/client.New({0xc00038eeeb, 0x7})
	/drone/src/pkg/client/client.go:14 +0x3e
coopcloud.tech/abra/cli/app.glob..func4(0xc0003a8ba0)
	/drone/src/cli/app/deploy.go:21 +0x6f
github.com/urfave/cli/v2.(*Command).Run(0x14c0240, 0xc0003cc080)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:163 +0x64a
github.com/urfave/cli/v2.(*App).RunAsSubcommand(0xc000396d00, 0xc000387ec0)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:434 +0x9a6
github.com/urfave/cli/v2.(*Command).startApp(0x14c1b00, 0xc000387ec0)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:278 +0x713
github.com/urfave/cli/v2.(*Command).Run(0xc000387c00, 0x7ffc3851179e)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:94 +0x7bc
github.com/urfave/cli/v2.(*App).RunContext(0xc000396b60, {0xed9cd8, 0xc000034078}, {0xc000030080, 0x4, 0x4})
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:313 +0x81e
github.com/urfave/cli/v2.(*App).Run(...)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224
coopcloud.tech/abra/cli.RunApp({0xeb47c0, 0xb}, {0xecf620, 0xc0000001a0})
	/drone/src/cli/cli.go:85 +0x467
main.main()
	/drone/src/cmd/abra/main.go:23 +0xbb

Additional information

Think it's 0.14-alpha?

## Steps to reproduce 1. Set up a VPS 2. Install abra using the installer script 3. Run `abra server add default` 4. Run `abra server init default` 5. Deploy some apps ## Describe the expected behavior Step 3 does nothing because the default context already exists. Step 4 creates `~/.abra/servers/default` ## Describe the current behavior 3-5 all crash with variations of: ``` $ abra app deploy disorganizing_work panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xa166bb] goroutine 1 [running]: github.com/docker/cli/cli/command.resolveDefaultDockerEndpoint(0x0) /go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/cli.go:324 +0x3b github.com/docker/cli/cli/command.ResolveDefaultContext(0x7f18ddb64108, 0x30, {0xde5438, 0xc0003b52c0}, {0xec3fa0, 0xc00000e028}) /go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/defaultcontextstore.go:65 +0x165 coopcloud.tech/abra/pkg/client.NewDefaultDockerContextStore.func1() /drone/src/pkg/client/context.go:124 +0x2f github.com/docker/cli/cli/command.(*ContextStoreWithDefault).GetMetadata(0x10000c00038eeeb, {0xc00038eeeb, 0x8}) /go/pkg/mod/github.com/docker/cli@v20.10.8+incompatible/cli/command/defaultcontextstore.go:133 +0x7e coopcloud.tech/abra/pkg/client.GetContext({0xc00038eeeb, 0x7}) /drone/src/pkg/client/context.go:88 +0x6b coopcloud.tech/abra/pkg/client.New({0xc00038eeeb, 0x7}) /drone/src/pkg/client/client.go:14 +0x3e coopcloud.tech/abra/cli/app.glob..func4(0xc0003a8ba0) /drone/src/cli/app/deploy.go:21 +0x6f github.com/urfave/cli/v2.(*Command).Run(0x14c0240, 0xc0003cc080) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:163 +0x64a github.com/urfave/cli/v2.(*App).RunAsSubcommand(0xc000396d00, 0xc000387ec0) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:434 +0x9a6 github.com/urfave/cli/v2.(*Command).startApp(0x14c1b00, 0xc000387ec0) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:278 +0x713 github.com/urfave/cli/v2.(*Command).Run(0xc000387c00, 0x7ffc3851179e) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:94 +0x7bc github.com/urfave/cli/v2.(*App).RunContext(0xc000396b60, {0xed9cd8, 0xc000034078}, {0xc000030080, 0x4, 0x4}) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:313 +0x81e github.com/urfave/cli/v2.(*App).Run(...) /go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:224 coopcloud.tech/abra/cli.RunApp({0xeb47c0, 0xb}, {0xecf620, 0xc0000001a0}) /drone/src/cli/cli.go:85 +0x467 main.main() /drone/src/cmd/abra/main.go:23 +0xbb ``` ## Additional information Think it's 0.14-alpha?
3wordchant added the
bug
abra
 labels 2021-09-25 01:12:41 +00:00
decentral1se commented 2021-09-28 19:59:18 +00:00
Owner
Copy Link

Hmmmm right yep. I think we have some code in places that just skips the default context but now I realise that yes, this does break the abra on the server mode of use. We should fix that.

As an aside, is abra server add default intuitive for "run things on this machine locally abra"? Perhaps we'd want to use another keyword like "local"? We don't have to use what Docker uses.

Hmmmm right yep. I think we have some code in places that just skips the `default` context but now I realise that yes, this does break the `abra` on the server mode of use. We should fix that. As an aside, is `abra server add default` intuitive for "run things on this machine locally `abra`"? Perhaps we'd want to use another keyword like "local"? We don't have to use what Docker uses.
decentral1se self-assigned this 2021-09-28 20:01:13 +00:00
decentral1se added this to the Beta release (software) project 2021-09-29 13:42:06 +00:00
decentral1se added this to the (deleted) milestone 2021-09-29 13:43:04 +00:00
decentral1se commented 2021-09-30 11:17:43 +00:00
Owner
Copy Link

I wasn't able to reproduce the stack trace on step 3, I got:

root@testservermode:~# abra server add default
FATA[0000] default context cannot be created nor updated

It does explode on step 4 indeed. On the bash impl. I see this:

➜  src (main) ✔ ./abra server add default
"default" is a reserved context name

And I can't remember being able to manage the local machine but I thought it did work?

abra server add assumes a working DNS entry and SSH server for <domain> (if you run abra server add -h). So what kind of UI/UX do we expect here?

abra server add --local mymachine could be a thing? Then we can check Docker is installed locally, create all the ~/.abra/... machinery and mark it for local connections.

I wasn't able to reproduce the stack trace on step 3, I got: ``` root@testservermode:~# abra server add default FATA[0000] default context cannot be created nor updated ``` It does explode on step 4 indeed. On the bash impl. I see this: ``` ➜ src (main) ✔ ./abra server add default "default" is a reserved context name ``` And I can't remember being able to manage the local machine but I thought it did work? `abra server add` assumes a working DNS entry and SSH server for `<domain>` (if you run `abra server add -h`). So what kind of UI/UX do we expect here? `abra server add --local mymachine` could be a thing? Then we can check Docker is installed locally, create all the `~/.abra/...` machinery and mark it for local connections.
decentral1se commented 2021-09-30 12:11:20 +00:00
Owner
Copy Link

abra server add --local mymachine seems workable then!

Discussed in Autonomic internal co-work.

`abra server add --local mymachine` seems workable then! Discussed in Autonomic internal co-work.
decentral1se commented 2021-10-01 10:15:01 +00:00
Owner
Copy Link

Fixed in 3688ea9d69.

Fixed in https://git.coopcloud.tech/coop-cloud/abra/commit/3688ea9d69de559de8f76c408207e7d419630c4c.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abra
Everything to do with abra
abra-gandi
Abra Gandi plugin
awaiting-feedback
Ping/pong on comms
backups
bug
Something is not working
build
Go build related issues
ci/cd
Getting the robots into the mix
community organising
Opening this thing up
contributing
Contributors stuff
coopcloud.tech
Our main website
democracy
Democratic decision making
design
Design thinking required
documentation
Let's write things together
duplicate
This issue or pull request already exists
enhancement
New feature
finance
Money things
funding
Anything related to grant funding
good first issue
Easy start with development
help wanted
Need some help
installer
Installation related issues
kadabra
performance
Performance related
proposal
Large change which requires feedback & decisin making
question
More information is needed
recipes.coopcloud.tech
Our recipes catalogue
security
Securing our shit
test
Unit or integration test suite
wontfix
This won't be fixed
No Label
abra
bug
Milestone
No items
No Milestone
Projects
Clear projects
No project Beta release (software)
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas decentral1se fauno kawaiipunk knoflook lambdabundesverband moritz p4u1 simon trav val yksflip
No Assignees decentral1se
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/organising#175
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?