Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[FIX] Ensure that health check output is available via HTTP gateway
With #5866, we inadvertently broke the output of the HTTP gateway when retrieving health check hook information. The overall health of a service was still returned, but neither the standard output nor the standard error were included. Because the addition of `install` (and later, `unintsall`) hooks introduced a situation in which hooks could be executed without having a service group present (that is, outside of a running Supervisor process), the common logic for finding the path to the log output of hooks was changed to accept a `&str` rather than a `&ServiceGroup`. The value that is ultimately used should have only been the "service name" portion (e.g., "redis" and not "redis.default"). Unfortunately, because `ServiceGroup` implements `Deref<Target=String>`, the calls to `stdout_log_path` and `stderr_log_path` in the `http_gateway` module could continue to compile. Since `Deref` is automatically invoked, the compiler was able to coerce the `&ServiceGroup` reference all the way to a `&str`, thus satisfying the new code. However, this `&str` was the _full_ name of the `ServiceGroup` (e.g., "redis.default"), which ended up silently breaking this HTTP gateway functionality. Rather than looking for the files at `/hab/svc/$SERVICE/logs`, we were instead looking at `hab/svc/$SERVICE.$GROUP/logs`. Now, we explicitly call `service_group.service()` at this callsite, thus restoring the prior functionality. A "proper" fix would involve more extensive refactoring to ensure that we have stricter typing to ensure the right "kind" of string is making its way down to `stdout_log_path` and `stderr_log_path`, and possibly removing the `Deref<Target=String>` implementation for `ServiceGroup`, since there is clearly more than one kind of string-like thing we could conceivably want out of a `ServiceGroup`. Such an approach appears to get us rather far afield into the workings and usage of our `outputln!` macros, which is an entirely different can of worms that is best left unopened here (see #6584 for more on that). Signed-off-by: Christopher Maier <cmaier@chef.io>
- Loading branch information