-
Notifications
You must be signed in to change notification settings - Fork 106
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
cloudapi: git sha version api and journal for workers #4484
base: main
Are you sure you want to change the base?
Conversation
} | ||
return ctx.JSON(http.StatusOK, version) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have the very same code in image-builder too, this is a copy-paste literally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick drive-by wondering inline
internal/common/runtime.go
Outdated
import "runtime/debug" | ||
|
||
var ( | ||
// Git SHA commit (first 4 characters) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment (4 chars) seems to not match the implementaion AFACIT
internal/common/runtime.go
Outdated
BuildCommit = "HEAD" | ||
} | ||
|
||
BuildGoVersion = bi.GoVersion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is bi
actually defined (i.e. non-nil) if we get a !ok
before (if not we would crash here)? I wonder if it wouldn't be cleaner to define the defaults directly in var BuildCommit = "N/A"
and just return on if !ok { return }
(?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No major comment additionally to the already mentioned ones.
In image builder we changed the way some paths are handled so they don't need authentication, which might be neat for /version
but I'd approve as this might be easier in a followup PR
c1efe97
to
5df2627
Compare
internal/cloudapi/v2/server.go
Outdated
RegisterHandlers(e.Group(path, mws...), &handler) | ||
|
||
// no auth endpoints | ||
e.GET("/status", func(c echo.Context) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the paths without auth 😎
But should it be
e.GET("/status", func(c echo.Context) error { | |
e.GET("/version", func(c echo.Context) error { |
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know right, but this is what is in the image-builder :-) Do you want me to break this pattern? I am fine with that, can also create both maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think /version
exists as it's in the openapi.v2.yml
so this might already result in both existing (which is good)
Rather somehow assure /version
not to be authenticated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok added /version
with non-auth middleware and also adding status/ready as fixed paths that simply return 200 without ANY middleware because we do not this to be logged or have metrics as k8s calls this every now and then.
5953c49
to
ac5e75d
Compare
@@ -1,3 +1,6 @@ | |||
exclude-dirs: | |||
- vendor | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For full transparency, I sneaked this hunk in with the last amend, I realized that go linter lints also vendor directories and that slows it significantly. Can do a separate PR if requested.
@@ -17,6 +17,21 @@ servers: | |||
description: current domain | |||
|
|||
paths: | |||
/version: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good, but when thinking about it … that's the version of osbuild-composer
not the worker, right? (in contrast to the PR title and commit subject :-/ )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API is "push" in this case - so the worker would have to "push" it's version, maybe?
properties: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah I started the patch with intention to include sha git in all log messages which was done. Then the version endpoint was added, yeah, this is just for the composer.
We can definitely add workers at some point, out of scope for this patch I would say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this could be either split in two commits or at least the description (PR and commit) should denote that this is touching worker and composer?
e229e0d
to
c4c9682
Compare
I have split it into multiple commits, rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks!
The only test failing is edge-farm, rebasing. |
@croissanne @ezr-ondrej @mvo5 please re-review tests are good I want to get this one merged to increase readability of logs from composer and continue further improving logs with standardized correlation thanks! |
switch bs.Key { | ||
case "vcs.revision": | ||
if len(bs.Value) > 6 { | ||
BuildCommit = bs.Value[0:6] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nitpick/drive-by) I wonder if we should use a slightly longer string here for the rev - for the osbuild-composer repo with many commits git log --oneline
gives me 9 chars for the git commit, this is dynamically calculated but usually the minimum is 7. So maybe just follow git and use 9 to avoid possible collisions?
Adds a runtime information similarily as in image builder and a logrus hook that is used to put git sha to every single log message. This way we can tell which version was log created with since composer and workers sometimes are running different versions.
This data is then leveraged in a new simple /version cloud API call that returns the data similarily to IB. My plan is to call this from IB too so IB reports both its and composer version info.
Finally, I noticed that workers create pretty unreadable logs, it is a string-encoded JSON:
This patch builds on top of native journald capability which I added last year and is used in on-prem mode. Instead using standard output/err worker now detects if there is a systemd-journald running and uses its native API to send logs in structured form.
This means all logs are native now, it can be inspected with journalctl and what is more important they should get into Kibana/Splunk as regular JSON improving our searching capabilities:
I know this is sort of two features in one PR but these are tiny changes, the API endpoint is super small and I wrote a test.