PG: do not use role == 0 as a determinant of primacy

We already have an is_primary() function to use instead.

Signed-off-by: Greg Farnum <greg@inktank.com>
osd: do not misuse calc_pg_role

We've been using the role returned from this to determine if we're
the primary or not. Don't.
This is mostly about removing a few asserts; while in there I also
redirected some calls to use static dereference instead of going through
the osdmap lookup path.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: doc the different pg->OSD mapping functions

Some of these look like what you should use for mapping and they absolutely
are not suitable for that. Make it clearer.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: use pg_to_acting_osds() in get_pg_primary()

This function was inappropriately skipping all the up/temp/etc checks.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: unify the pg_to_acting_osds and pg_to_up_acting_osds implementations

These were the same except for a call to _raw_to_up_osds(). Move the
existing pg_to_up_acting_osds into a private function taking a pointer,
only fill in the up vector if it's a non-NULL pointer, and call it via
the obvious header implementations.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: rename _raw_to_temp_osds() -> _get_temp_osds()

This function does not (and never has!) used the raw vector, so remove it
and don't use a name which implies it is doing any sort of conversion.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: switch pg_to_osds to have an explicit primary param

Use pointers instead of references for the out params, too!

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: implement pg_to_up_acting_osds with primary interface

Use our pointer calling conventions instead of a reference for the
new version of the function.

Right now we're just setting the primaries equal to the first member
of up and acting (or -1 if none), but very shortly we'll modify our
private OSDMap functions to export them based on the contents of temp_primary.
While in general anybody querying for the mapping information will
need to pay attention to whom the primary is as well, we have lots
of callers who will need real code changes to do so. To serve them,
we keep a version that does not export the primary, but asserts
that the primary matches the first entry in its list.

Signed-off-by: Greg Farnum <greg@inktank.com>
mon, osdmaptool: switch to primary-specifying pg_to_up_acting_osds

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: add primary-specifying pg_to_acting_osds

This works the same as pg_to_up_acting_osds

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: add primary out param to pg_to_raw_up, and use pointers instead of refs

The only user is in the OSDMonitor, and it's going to want that
information anyway.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: add a CEPH_FEATURE_OSDMAP_ENC feature, and use new encoding

Bring our OSDMap encoding into the modern Ceph world! :) This is
fairly straightforward, but has a few rough edges:
Previously we had a "struct_v" which went at the beginning of the
OSDMap encoding, and then later on an ev "extended version" which
was used to store the more-frequently-changed OSDMap pieces. There
was no size information stored explicitly to let clients skip this,
but osd maps were always encoded into their own bufferlist before
being sent to clients, which had the same effect.
We now use the modern ENCODE_START three times:
1) for the overall OSDMap encoding,
2) for the client-usable portion of the map,
3) for the "extended" portion of the map

This will let us independently rev everything, which may come in
useful if we want to (for instance) add a "monitor" portion to the
map that the OSDs don't care about. It also makes adding new
client information a lot easier since older clients will still
be able to decode the map as a whole.

We may want to merge this OSDMAP_ENC feature with one of the others
we are creating during this cycle, since they're all very closely
related. That will also let us protect more naturally against old
clients getting a map they need to understand but can't (because
we only need the new map features-to-come when used with erasure-encoded
PGs, etc).

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: update Incremental encode/decode to match the full map's

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: add [new_]primary_temp to the map and Incremental

It's not used actively yet, but there it is.

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: add primary_temp to apply_incremental()

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: dedup the primary_temp

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMap: expose the primary_temp in print()

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMonitor: remove primary_temp entries when you remove their pool

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMonitor: make remove_redundant_pg_temp clear primary, too

Signed-off-by: Greg Farnum <greg@inktank.com>
OSDMonitor: implement remove_down_primary_temp()

Same as remove_down_pg_temp()

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