This is handy if you want to quickly create a cluster
with lots of filesystems, for playing with e.g. what
the ceph status output looks like when multiple filesystems
are in play.
This changes the default filesystem/pool names to be
e.g. cephfs_data_a instead of just `cephfs_data`, but anything
who relied on those names in a vstart environment houldn't have
been (this won't affect teuthology tests, of course, where we
still have a few annoying hardcoded pool names).
Signed-off-by: John Spray <john.spray@redhat.com>
These were just dumping JSON as a placeholder.
Not strictly necessary to have the extra non-machine-readable
variants of these outputs, but some users will probably appreciate
it, so why not.
Signed-off-by: John Spray <john.spray@redhat.com>
Only for use in extremis, where we have encountered
a bug that generates an invalid FSMap, but the way
to resolve it might be to proceed anyway and stay
up long enough to use commands to fix it.
Fixes: #15063
Signed-off-by: John Spray <john.spray@redhat.com>
...from Filesystem. This will prepare us for if
MDSMap gets any more feature-sensitive encoding
in the future.
Fixes: #15062
Signed-off-by: John Spray <john.spray@redhat.com>
This broke with 4ad8f7254 ('features' gets
output as an item in the 'export_targets' list),
which wasn't the fsmap branch, but fix it while
I'm tidying.
Signed-off-by: John Spray <john.spray@redhat.com>
Not used for anything currently, but let's make
this class pass through the features to FSMap's
encode method for the benefit of the future
generations.
Signed-off-by: John Spray <john.spray@redhat.com>
We tell the client that the content has not changed. If we
send a Content-Length header RFC2616 describes that the client
MUST use that new value:
"If a cache uses a received 304 response to update a cache entry,
the cache MUST update the entry to reflect any new field values
given in the response."
Therefor we should not send a Content-Length header
Fixes: #15119
Signed-off-by: Wido den Hollander <wido@42on.com>
When we say the Content has not changed we should not respond
with a content type which defaults to binary/octet stream.
Fixes: #15119
Signed-off-by: Wido den Hollander <wido@42on.com>
Currently if a zone is not a part of a zonegroup, an error message
is printed that zone doesn't exist, and the zone gets deleted anyway.
Since this is exhibited only if the zone isn't a part of a zonegroup
and we allow creation of such zones, clarify that the zone wasn't a
part of zonegroup instead
Fixes: #14951
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
1. only attempt auth on tokens which pass valid() check
2. ignore false positive search result (and fix result in that case)
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Though this error message is hard to reach, it is still wrongly printed
as failed to create instead of failed to delete.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Encode old-style until mon quorum features indicate
jewel, forbid creating multiple filesystems, and
when creating a single filesystem use the legacy fscid.
Fixes: #15223
Signed-off-by: John Spray <john.spray@redhat.com>
If we have a pending pg update from the OSD with a newer epoch
than the one we're processing in map_pg_creates, we shouldn't
update, as we'll warp the PG back in time (clobbering the PG
state).
Signed-off-by: Sage Weil <sage@redhat.com>
Before a7a3658 the rbdmap script was logging bogus messages and not working
on systemd platforms because the unit file was not defining the RBDMAPFILE
environment variable.
This workunit asserts that the bug has been fixed.
http://tracker.ceph.com/issues/14984 References: #14984
Signed-off-by: Nathan Cutler <ncutler@suse.com>
This operation is already implemented (OPT_ZONE_DELETE), however not
mentioned in the help, just adding to the help options
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Latest accelio code removes the attribute to call xio_init on load
and XioMessenger will first try to initialize portals and create xio context.
This commit will fix this behavior and call xio_init first.
Signed-off-by: Roi Dayan <roid@mellanox.com>
First, make the Debian package description mention that RGW aims to
implement the Swift API.
Second, replace the RPM package description with the Debian one, both for
consistency and because the Debian one is better.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
