Refactor the stack services command to be uniform#2131
Refactor the stack services command to be uniform#2131rumpl wants to merge 1 commit intodocker:masterfrom
stack services command to be uniform#2131Conversation
ea95cdd to
f7b6ff3
Compare
|
Force pushed to add comments on exported functions |
silvin-lubecki
left a comment
There was a problem hiding this comment.
LGTM, thank you @rumpl 👍
thaJeztah
left a comment
There was a problem hiding this comment.
I left some comments; one nit, and one (slightly) bigger change.
Code looks good in its current form, but (if it's not super-urgent to have this merged right away), I'd like to see if we can incorporate the changes from moby/moby#39231, so that we don't have to change the signature of these functions (twice)
| // RunServices is the kubernetes implementation of docker stack services | ||
| func RunServices(dockerCli *KubeCli, opts options.Services) error { | ||
| // GetServices is the kubernetes implementation of listing stack services | ||
| func GetServices(dockerCli *KubeCli, opts options.Services) ([]swarm.Service, map[string]service.ListInfo, error) { |
There was a problem hiding this comment.
I'm looking at the extra return here; the service.ListInfo is basically generated from information that's in []swarm.Service, combined with information about the number of tasks running / desired. If I see it correctly, the service.ListInfo here is needed, because swarm.Service has no field for task status ("mode" is already part of the Service spec).
I just (finally) merged moby/moby#39231, which is a PR that adds exact those fields to the Service struct, which means we could just return ([]swarmService, error), and have the presentation code either convert it to a ListInfo or adjust that code to use []swarm.Service directly.
There was a problem hiding this comment.
Let me prepare a vendor bump to bring in the changes from moby/moby#39231
There was a problem hiding this comment.
Sure, I can wait for the vendor bump, thanks!
| _, err = stacks.Get(stackName) | ||
| if apierrs.IsNotFound(err) { | ||
| return fmt.Errorf("nothing found in stack: %s", stackName) | ||
| return []swarm.Service{}, nil, nil |
There was a problem hiding this comment.
I was looking if we should return the error here, and have it handled by the caller 🤔. That way, this function (when used in different situations) would not hide this information.
I think that's ok for a follow-up, because we should have a function to convert Kubernetes API errors to errdef errors. In that case we would map (if possible) / standardise these errors, so that the non-k8s specific code understands them;
cli/vendor/k8s.io/apimachinery/pkg/api/errors/errors.go
Lines 456 to 459 in 0b6685b
// statusCodeFromContainerdError returns status code for containerd errors when
// consumed directly (not through gRPC)
func statusCodeFromContainerdError(err error) int {
switch {
case containerderrors.IsInvalidArgument(err):
return http.StatusBadRequest
case containerderrors.IsNotFound(err):
return http.StatusNotFound
case containerderrors.IsAlreadyExists(err):
return http.StatusConflict
case containerderrors.IsFailedPrecondition(err):
return http.StatusPreconditionFailed
case containerderrors.IsUnavailable(err):
return http.StatusServiceUnavailable
case containerderrors.IsNotImplemented(err):
return http.StatusNotImplemented
default:
return http.StatusInternalServerError
}
}There was a problem hiding this comment.
The reason I didn't return an error here is because the same code for swarm returns an empty slice when no services are found. We can do it one way or the other, we should just make sure that errors are returned in the same places for kubernetes and swarm.
f7b6ff3 to
ab837de
Compare
|
Rebased with master and changed the imports of |
Running `docker stack services <STACK> --orchestrator swarm would yield the message "Noting found in stack: asdf" with an exit code 0. The same command with kubernetes orchestrator would yield "nothing found in stack: adsf" (note the lower-case "nothing") and a non-zero exit code. This change makes the `stack services` command uniform for both orchestrators. The logic of getting and printing services is split to reuse the same formatting code. Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
ab837de to
71eef01
Compare
|
carrying in #2167 - which is now ready for review 👍 |
|
👍 thanks a bunch! |
- What I did
Running
docker stack services <STACK> --orchestrator swarmwould yield the message "Noting found in stack: asdf" with an exit code 0. The same command with kubernetes orchestrator would yield "nothing found in stack: adsf" (note the lower-case "nothing") and a non-zero exit code. This change makes thestack servicescommand uniform for both orchestrators. The logic of getting and printing services is split to reuse the same formatting code.- How to verify it
Run:
Both commands should return
0and show the error messageNoting found in stack: unknown.- Description for the changelog
Stack services will return the same exit code for all orchestrators.
- A picture of a cute animal (not mandatory but encouraged)
