It is possible that the ceph user/group will not have fixed UID/GID in SUSE.
Instead, it is possible that the ceph package will depend on a separate package
whose sole purpose will be to create the ceph user/group if they do not exist.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The openSUSE Build Service runs a number of "post-build checks" after the RPMs
have been generated. One of these tests the RPM scriptlets for idempotence.
Without this line in the specfile, the check fails on SLE_12 because it cannot
find the systemd-tmpfiles binary.
http://tracker.ceph.com/issues/13375Fixes: #13375
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Currently, the main ceph package and the ceph-radosgw behave
differently on upgrade. This commit unifies their behavior
to the following:
On package removal, disable and stop all related systemd units.
On package upgrade, do nothing unless there is a file /etc/sysconfig/ceph
containing a parameter CEPH_AUTO_RESTART_ON_UPGRADE. If parameter is set
to "yes", restart the systemd units iff they are running.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Add "--param ggc-min-expand=20 --param ggc-min-heapsize=32768"
to RPM_OPT_FLAGS, ensuring gcc does not add debug symbols and is
more aggressive about garbage collection.
Thanks to Berthold Gunreben for debugging this issue.
http://tracker.ceph.com/issues/13352Fixes: #13352
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The -o option to groupadd/useradd is not recognized in SLE12. For
SLE/openSUSE, follow the openSUSE packaging guidelines.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Since the ceph user and group are created in the ceph-common
%pre scriptlet, the systemd-tmpfiles --create command needs
to run in that package.
tracker.ceph.com/issues/13346 Fixes: #13346
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Over in the SUSE sector, we are trying to enable the SLE_12 and openSUSE_13.2
build targets. The lttng/babeltrace stuff is currently available only in
SLE_12.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
In Fedora, RHEL and CentOS there is a package called boost-random.
In SLE/openSUSE, there is no such package.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Allow librados users to opt to receive ENOSPC or EDQUOT when they submit
an operation against a full cluster. This should only be used if the
librados app can handle those errors gracefully (librbd, for example,
cannot).
Also note that this allows savvy librados users to send delete operations;
they will get either a success or EDQUOT, depending on whether the
operation results in a net drop in space utilization.
Signed-off-by: Sage Weil <sage@redhat.com>
We may send a notify to the cluster multiple times due to OSDMap
changes. In some cases, earlier notify attempts may complete with
an error, while later attempts succeed. We need to only pay
attention to the most-recently send notify's completion.
Do this by making note of the notify_id in the initial ACK (only
present when talking to newer OSDs). When we get a notify
completion, match it against our expected notify_id (if we have
one) or else discard it.
This is important because in some cases an early notify completion
may be an error while a later one succeeds.
Note that if we are talking to an old cluster we will simply not record a
notify_id and our behavior will be the same as before (we will trust any
notify completion we get).
Fixes: #13114
Signed-off-by: Sage Weil <sage@redhat.com>
The OSD assigns a unique ID to each notify it queues for
processing. Include this in the reply to the notifier so that
they can match it up with the eventual completions they receive.
This is necessary to distinguish between multiple completions
they may receive if there is PG peering and the notify is resent.
In particular, an earlier notify may return an error when a later
attempt succeeds.
This is forwards and backwards compatible: new clients will make use of
this reply payload but older clients ignore it.
Signed-off-by: Sage Weil <sage@redhat.com>
This was uncovered by 7532194372. Since
rbd_create() does a stat, the obc is cached as a whiteout, and the
subsequent create(EXCL) would fall through to return false from
maybe_create_new_object(). This would then skip adding a touch() to
the transaction.
Fixes: #13281
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
An ObjectStore::Sequencer provided to an ObjectStore must not be
deallocated before umount. The ObjectStore::Sequencer may hold a pointer
to the instance with no reference counting. If a Context completes after
the ObjectStore::Sequencer is deleted, it could try to use it and fail.
http://tracker.ceph.com/issues/13176Fixes: #13176
Signed-off-by: Loic Dachary <ldachary@redhat.com>