Conversation
|
Not gonna lie, this one was quite painful |
|
Oh, LVM seems to be behaving differently, but the behavior didn’t appear on my machine. |
|
So two questions come up:
|
In the case of an ISO which is write-once, it'd be safe to truncate it to the size we have in the database. For any other volume type, not so much as actual data (GPT table mostly) may have been written all the way at the end of the volume (post-rounding/alignment). |
Oh I see. But doesn’t it mean that we’re exposing in the API a size that may be wrong? (thinking about vol.config["size"]) |
|
Nah, it really looks like |
255cfd8 to
50c5860
Compare
|
I’ll add a commit to patch the command description tomorrow |
|
@bensmrs can you add an API extension for this one? |
|
I’m always confused whether we need an extension or not… Here, clients won’t behave differently (as in: it’s the server that tells whether things worked; the clients don’t have to adapt) with or without this extension, so what’s exactly the point? |
|
@bensmrs sorry, needs a rebase because of the API extension. |
The reason for this one is so for example a web UI can tell whether to show a download button next to that ISO image or not. Doesn't really matter for the CLI as we had a clear error, but it does allow for providing a better user experience in some situations. |
Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
…ossible Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
Signed-off-by: Benjamin Somers <[email protected]>
|
Ok thanks for the clarification |
Closes: #2506