[drbd-build-svr]: add readme #332
Conversation
| - `kernel_version` (optional): Kernel version (alternative to header) | ||
|
|
||
| **Response:** | ||
| - `202 Accepted`: Build job created or already in progress |
There was a problem hiding this comment.
Should we mention error responses here?
There was a problem hiding this comment.
I suppose later we should make an open API spec later.
| "created_at": "2024-01-01T12:00:00Z", | ||
| "completed_at": "2024-01-01T12:05:00Z", | ||
| "duration": "5m0s", | ||
| "cache_path": "/var/cache/drbd-build-server/abc123....tar.gz", |
There was a problem hiding this comment.
This looks like server internal info we should not leak. Maybe keep as debug header configured on server side?
There was a problem hiding this comment.
Yes we should refactor API later as written above
| Initiates a build request for DRBD kernel modules. | ||
|
|
||
| **Request:** | ||
| - **Body**: Kernel headers as `tar.gz` archive |
There was a problem hiding this comment.
Should we give an example of header archive structure?
There was a problem hiding this comment.
Now we don't use a specific archive structure. So, I don't think we should explain it. Perhaps it would be more convenient to provide more detailed examples at the MVC stage.
|
|
||
| The server uses an intelligent caching mechanism: | ||
|
|
||
| - **Cache Key**: SHA256 hash of kernel version + kernel headers data |
There was a problem hiding this comment.
So if user do not specify the version and specified exact version as in headers will it be different cache record and builds?
Also I guess we could specify that headers hash calculated on uncompressed headers
There was a problem hiding this comment.
May be it would be more correct to not explain hashing algorithm
| Initiates a build request for DRBD kernel modules. | ||
|
|
||
| **Request:** | ||
| - **Body**: Kernel headers as `tar.gz` archive |
There was a problem hiding this comment.
I'm sure we also need from the user the body Content-Type: application/gzip or maybe Content-Type: application/x-tar and Content-Encoding: gzip. I guess the first one is the correct way.
There was a problem hiding this comment.
I suppose later we should make an open API spec . We should get information how it will be useful and fix one. Now for prototype stage we can skip it.
asergunov
left a comment
asergunov
left a comment
There was a problem hiding this comment.
So it should be at least two requests. One is POST to give headers to server and receive the hash based download link and job status link. Second request is GET of artefact blocking while it's building. Optionally user can ask for job status with separate parallel request but I'd make RESTless option when user should not invent its own timeouts but receive the status messages to the opened connection.
|
|
||
| **Response:** | ||
| - `202 Accepted`: Build job created or already in progress | ||
| - `200 OK`: Cached module found, returns module file immediately |
There was a problem hiding this comment.
Do we have the same json response both return codes? May be give download link right away? What if we give download link even if it's not done yet? I mean we can give an option to keep connection opened while it's building. So user will not have to write loop and invent timeout values.
There was a problem hiding this comment.
I think we should conduct a few tests, evaluate the build speed, and then make a decision based on the results. This is beyond the scope of the PR. Actually we need refactor API almost I suppose
| } | ||
| ``` | ||
|
|
||
| ### GET `/api/v1/download/{job_id}` |
There was a problem hiding this comment.
It should be a hash instead of job id here. So proxies can cache it.
There was a problem hiding this comment.
Now job id is the first 16 digets of hash
|
I actually can't see any reason to have job id. Because in our logic it's the same as build hash. I mean we should mention that job id is not a number, but string. This way we could change server behaviour without changing client |
|
Let's just add todo sections to this document and some explanation: that's what we have now and that's what we going to change, why we want it. So we can merge this PR |
sklyarevsky
force-pushed
the
feature/drbd-build-server-readme
branch
2 times, most recently
from
0f90bb7 to
448f5fc
Compare
duckhawk
force-pushed
the
feature/drbd-build-server-readme
branch
from
448f5fc to
b530c9a
Compare
sklyarevsky
force-pushed
the
feature/drbd-build-server-readme
branch
from
b530c9a to
568b150
Compare
sklyarevsky
force-pushed
the
vkarpochev-drbd-build-server
branch
6 times, most recently
from
49fc3d5 to
c6f2207
Compare
|
Need close because the API and design are outdated. Useful comments should be moved to PR328. |
Please do |
No description provided.