Choose final object version encoding

[mniewrzal]

Currently we are encoding int64 version into 16 bytes to be valid UUID. We need to decide if we want more data stored into our version or if we want to encode it in a different way.

[shaupt131]

We can do this in parallel to QA sprint 29.

[mniewrzal]

Michał Niewrzał
So in regards to version encoding. Currently we are just encoding int64 into 16 byte. Its 16 bytes because in some cases minio code is validating VersionID as UUID. Before moving versioning to beta and give it to customers we should decide if we want to keep this simple encoding or make it more sophisticated. Egon proposed to put stream_id into encoded version. With limitation to 16 bytes we can include half of stream_id. Of course we could modify minio (we forked it) to accept longer VersionID but is it really important?
Egon
Yes, we'll need stream id to be part of the api version to provide better uniqueness. e.g. otherwise it's easy to get the same version number on the same object
Michał Niewrzał
so only question is if we need full stream_id or partial stream_id will be good enough
Egon
partial should be good enough
Although, use the last 8 bytes of the stream id rather than the first. Delete marker first 6 bytes are 0xFF

[storj-gerrit]

Change satellite/metabase: include part of stream id into encoded version mentions this issue.

[iglesiasbrandon]

@mniewrzal @egonelbre it looks like the PR for this issue has been deployed to production. I am going to close this issue. @shaupt131