MOSDOpReply: set reassert_version for very old clients

I think this must make every sufficiently-old client fail on replay --
very bad!

Signed-off-by: Greg Farnum <greg@inktank.com>
docs: document how the current OSD PG/object versions work

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: rename reassert_version -> replay_version

Because that's what it's for. reassert_version is a bit ambiguous.

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: rename *_version() -> *_replay_version()

We have been returning the object's "user version" and using that
for replay, but that is in fact incorrect. In preparation for fixing
up the user version semantics, rename get_version to get_replay_version
and set_version to set_replay_version.

Signed-off-by: Greg Farnum <greg@inktank.com>
ReplicatedPG: remove long-dead branch

This was confusing the heck out of me when trying to figure out
why I was hitting an assert. So replace the if-else block with
a more appropriate assert and don't include any misleading calls
to prepare_transaction() from sub_op_modify().

Signed-off-by: Greg Farnum <greg@inktank.com>
ReplicatedPG: do not do a redundant set of ctx->new_obs.oi.version

We set this in the if below for writes, and for reads it doesn't need to
be updated (and isn't). Remove the confusing double-set so future code
inspectors don't get concerned there's a bug like I did.

Signed-off-by: Greg Farnum <greg@inktank.com>
doc: include plan for new user_version support

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: add user_version field

Signed-off-by: Greg Farnum <greg@inktank.com>
Objecter: rename Op::version to Op::replay_version

This is used for replay, so let's be more precise!

Signed-off-by: Greg Farnum <greg@inktank.com>
Objecter: librados: mass switch from eversion_t to version_t

There are a lot of pointers throughout our request infrastructure used solely
for exporting the version to users. The interfaces we actually expose only
provide a uint64_t (leaving off eversion_t's epoch), and that's all we're
going to maintain in our new user_version scheme, so don't pretend we'll
have more in our internal interfaces.

I audited this pretty carefully; in particular:
Op::objver is only used for passing data back to users via the calling
functions IoCtxImpl::last_objver, etc
IoCtxImpl::last_objver is used only for the set_sync_op_version() call, which
provides data only for the uint64_t get_last_version() and
rados_get_last_version() calls.
AioCompletionImpl::objver is used only for the uint64_t get_version() call.
LingerOp::pobjver is used only for referencing things that are now version_t.

Signed-off-by: Greg Farnum <greg@inktank.com>
Objecter: expose MOSDOp's new user_version instead of the replay_version

We don't want users to ever see the replay_version, which is about
to become private RADOS data.

Signed-off-by: Greg Farnum <greg@inktank.com>
ReplicatedPG: set the replay version based on the at_version

The replay version is not for users to consume, so we don't want
to use the user_version for it.

Signed-off-by: Greg Farnum <greg@inktank.com>
ReplicatedPG: Fill in the MOSDOpReply's user_version

As part of this, rename OpContext::reply_version->reply_user_version.
The semantics that necessitate the reply_version are only for user versions,
so rename it for clarity. Then use the reply_user_version in
set_user_version() (if the op succeeded).
For now we use the PG version for ENOENT (preserving the previous
semantics), but that will get changed to the pg's user_version soon
as well.

Signed-off-by: Greg Farnum <greg@inktank.com>
osd: switch object_info_t::user_version to be a version_t

We never expose the full eversion_t data to users, and do not want to.
However, we pull some tricks in the encode/decode functions to avoid
having to change the object_info_t disk format for this change.
When we can break compatibility, we should simplify this.

Signed-off-by: Greg Farnum <greg@inktank.com>
ReplicatedPG: remove OpContext::reply_user_version

ctx->new_obs.oi.user_version is initialized to ctx->obs.oi.user_version,
and for read ops it won't be changed. That means
reply_user_version == ctx->new_obs.oi.user_version in all cases, which
means we don't want it.

Signed-off-by: Greg Farnum <greg@inktank.com>
osd: add last_user_version to pg_info_t

We add a corresponding user_version to pg_log_entry_t, and the logic
to assign from one to the other and to recover last_user_version from
a master's log. We aren't yet setting it to anything, though.

Signed-off-by: Greg Farnum <greg@inktank.com>
osd: actually fill in user_version in pg_log_entry_t

We now require it when creating a pg_log_entry_t. The user_version
is the version which info.last_user_version should be set to
after the transaction is applied, which for everything except for
a user-modify op is going to be the version it was already at.
For now we are filling in the user-modify op's changing user_version
to be ctx->at_version.version

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: add enough fields to be backwards compatible.

The system we've been building up works out very nicely for new clients,
but they could not have interoperated with old clients that were only
referring to our replay_version. In order to deal with this, we add
a bad_replay_version to MOSDOpReply which is encoded where we used
to encode replay_version. bad_replay_version will follow the same semantics
as reassert_version used to (except that it is filled in on reads), but
is not accessible to new clients, who can see only our properly-controlled
replay_version and user_version. This will let old and new clients
interoperate correctly when communicating about watches, etc.

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: switch to comprehensive instead of individual version setters

There's little point to updating versions individually when we can
do so en masse and avoid mistakes in duplication.

Signed-off-by: Greg Farnum <greg@inktank.com>
MOSDOpReply: stop filling in replay_version from the MOSDOp to begin with

It's just asking for trouble.

Signed-off-by: Greg Farnum <greg@inktank.com>