Refactor the stack services command to be uniform

[rumpl]

- What I did

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.

- How to verify it

Run:

$ docker stack services unknown --orchestrator swarm
$ docker stack services unknown --orchestrator kubernetes

Both commands should return 0 and show the error message Noting 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)

[rumpl]

Force pushed to add comments on exported functions

[silvin-lubecki]

LGTM, thank you @rumpl 👍

[thaJeztah]

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)

[thaJeztah]

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.

[thaJeztah]

Let me prepare a vendor bump to bring in the changes from moby/moby#39231

[rumpl]

Sure, I can wait for the vendor bump, thanks!

[thaJeztah]

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

	// IsNotFound returns true if the specified error was created by NewNotFound.
	funcIsNotFound(errerror) bool {
	returnReasonForError(err) ==metav1.StatusReasonNotFound
	}

Similar to https://github.com/moby/moby/blob/81dbed4c8b87d99824eecea68c95f10056fd3d2a/errdefs/http_helpers.go#L172-L191

// statusCodeFromContainerdError returns status code for containerd errors when// consumed directly (not through gRPC)funcstatusCodeFromContainerdError(errerror) int {
switch {
casecontainerderrors.IsInvalidArgument(err):
returnhttp.StatusBadRequestcasecontainerderrors.IsNotFound(err):
returnhttp.StatusNotFoundcasecontainerderrors.IsAlreadyExists(err):
returnhttp.StatusConflictcasecontainerderrors.IsFailedPrecondition(err):
returnhttp.StatusPreconditionFailedcasecontainerderrors.IsUnavailable(err):
returnhttp.StatusServiceUnavailablecasecontainerderrors.IsNotImplemented(err):
returnhttp.StatusNotImplementeddefault:
returnhttp.StatusInternalServerError
}
}

[rumpl]

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.

[rumpl]

Rebased with master and changed the imports of swarmtypes to be consistent with the rest of the code.

[thaJeztah]

carrying in #2167 - which is now ready for review 👍

[rumpl]

👍 thanks a bunch!