use the ubuntu_face.yaml facet for the distro used for testing. since we
are dropping the support for trusty.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* instead of using ubuntu 14.04, use ubuntu_latest.since we want
to drop the support of this release.
* refactor this test to use the facet of ubuntu_latest.yaml.
Signed-off-by: Kefu Chai <kchai@redhat.com>
the buildpackages feature is not part of ceph. and its test was moved to
teuthology in 5a43f8d5. let's remove the leftovers from ceph/ceph. BTW,
we have not run this test suite since then. and its dependency cannot be
fulfilled.
Signed-off-by: Kefu Chai <kchai@redhat.com>
When replaying slave update, inode may gets unlinked, but preserved
in memory in case of rollback. In this case, we need to detach the
inode's snaprealm from its parent.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
If inode has no parent dentry (newly created), CInode::find_snaprealm()
should try the oldest projected parent.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
These are possible because we update purged_snaps, part of the pg_info_t,
but we do not bump the pg version or match it with a log entry, which
means that the change does not reliably propagate to new OSDs during
peering etc.
Signed-off-by: Sage Weil <sage@redhat.com>
We do not want the key to show up on the command line (it may appear in
the process list or sudo log file).
Fixes: http://tracker.ceph.com/issues/22283
Signed-off-by: Sage Weil <sage@redhat.com>
Be a bit careful here because the mon has to do some bookkeeping to avoid
pruning things twice. If the PGMapDigest set appears obviously stale,
skip some work (looking at this particular interval) until it is not
obviously stale--move onto the next interval instead.
Signed-off-by: Sage Weil <sage@redhat.com>
On the first mimic map, consider previously removed_snaps to be removed
in that epoch (since we don't easily know when it happened).
Signed-off-by: Sage Weil <sage@redhat.com>
Explicitly track whether we are a pool snaps pool or a selfmanaged
snaps pool. This was inferred from removed_snaps.empty() before, but
that was fragile and kludgey and removed_snaps is going away.
The upgrade/compat behavior is a bit tricky:
- on decode, we set the flags based on the legacy condition. This lets us
use and rely on the flags in memory.
- on encode, we exclude the flags if decoding an older pg_pool_t
Signed-off-by: Sage Weil <sage@redhat.com>
- update snap_trimq and purged_snaps based on new mimic OSDMap fields
- improve debug output to include both trimq and purged
Signed-off-by: Sage Weil <sage@redhat.com>
This dependency on the ondisk version dates back before argonaut, and no
longer makes sense. Once the snap is trimmed by the primary, and
purged_snaps is updated, the replica can (must!) blindly follow suit.
Signed-off-by: Sage Weil <sage@redhat.com>
If we are about to lose our primary status, we don't want to do *any*
of this stuff... especially share_pg_info(), which would get tagged with
the current epoch but confuse our peers!
Signed-off-by: Sage Weil <sage@redhat.com>
If we are so laggy that we aren't contiguous with the mon's latest
map, the mon will provide a summary of removed_snaps for the gap.
Apply those to our in-flight ops.
Signed-off-by: Sage Weil <sage@redhat.com>
Instead of maintaining a set of snapids that have been removed over
all time, instead note just the newly removed and newly purged snaps
in each OSDMap epoch. This is easier to consume for both the Objecter
and OSD.
Also keep the interval of snaps that have been removed but not perged
in each OSDMap. This is extremely convenient because it frees the OSDs
from having to maintain this information in parallel even when they may
not have PGs belonging to those pools. These structures will be large
right when the ugprade happens and the pg_pool_t::removed_snaps gets copied
to the new fields, but in the steady state it will be relatively small,
reflecting only the set of snaps that are currently being removed.
This also provides convenient visibility into the "trimming snaps" set
that the cluster is working on.
Signed-off-by: Sage Weil <sage@redhat.com>
This ensures we don't have any cruft left over in fields that decode()
assumes are initialized from the ctor (and not a previous instance).
Signed-off-by: Sage Weil <sage@redhat.com>
In reality we only call this when the PG is peered and thus past_intervals
is empty, but this is more defensive in case that changes someday!
Signed-off-by: Sage Weil <sage@redhat.com>
