I want to allow a single user to run two concurrent sessions of the same Workspace (same image_id, same user, so the same S3 persistent profile path). This doesn't happen very often but sometimes I just need to start another session with the same image and user on a different Agent host.
To be clear about what I'm asking: I don't care about last-write-wins. If two sessions each upload a complete, self-consistent snapshot and one simply overwrites the other, that's fine - my profiles rarely hold any real data. Losing a few settings is acceptable for me. What would not be acceptable is if an upload writes individual chunks that can interleave with a concurrent upload's chunks, since that could leave the stored profile unrestorable rather than merely stale.
So the question is only about the write granularity, which lives inside the closed-source kasm-profile-sync binary and doesn't appear to be documented.
From kasm_pre_shutdown_user.sh, session end runs one invocation over the whole home dir:
/usr/bin/kasm-profile-sync --upload /home/kasm-user --insecure \
--filter "${KASM_PROFILE_FILTER}" --remote ${KASM_API_HOST} \
--port ${KASM_API_PORT} -c ${KASM_PROFILE_CHUNK_SIZE} --token ${KASM_API_JWT}
-c (KASM_PROFILE_CHUNK_SIZE, default 100000) plus the docs' description of a manifest with presigned URLs "for each layer of the profile" suggests the profile is packed and chunked, and that the chunks are the layers. What happens to that object set on a second, overlapping upload is what I can't determine.
Questions
- Does an upload replace the profile's whole object set, or write only changed chunks?
- Are chunks content-addressed (hash-named) or positional (
chunk_0001)? Is there a manifest committed atomically as the final step?
- Does the API serialize concurrent uploads for the same profile path, or do they race?
- If two sessions upload at nearly the same time, is the result a coherent snapshot from one of them, or possibly a mix of chunks from both?
I want to allow a single user to run two concurrent sessions of the same Workspace (same
image_id, same user, so the same S3 persistent profile path). This doesn't happen very often but sometimes I just need to start another session with the same image and user on a different Agent host.To be clear about what I'm asking: I don't care about last-write-wins. If two sessions each upload a complete, self-consistent snapshot and one simply overwrites the other, that's fine - my profiles rarely hold any real data. Losing a few settings is acceptable for me. What would not be acceptable is if an upload writes individual chunks that can interleave with a concurrent upload's chunks, since that could leave the stored profile unrestorable rather than merely stale.
So the question is only about the write granularity, which lives inside the closed-source
kasm-profile-syncbinary and doesn't appear to be documented.From
kasm_pre_shutdown_user.sh, session end runs one invocation over the whole home dir:-c(KASM_PROFILE_CHUNK_SIZE, default100000) plus the docs' description of a manifest with presigned URLs "for each layer of the profile" suggests the profile is packed and chunked, and that the chunks are the layers. What happens to that object set on a second, overlapping upload is what I can't determine.Questions
chunk_0001)? Is there a manifest committed atomically as the final step?