Kefu Chai [Fri, 30 Aug 2019 11:49:28 +0000 (19:49 +0800)]
ceph.spec.in: s/pkgversion/version_nodots/
`python3_pkgversion` is now defined as 3, while we don't have packages
like python3-Cython yet in EPEL7. but we do have `python36-Cython`. so
let's use `python3_version_nodots` instead.
tl;dr: this change addresses the failures of "make check" runs on arm64
builders when they try to build `mgr-dashboard-test-venv` target.
long story: without this change, we will fail to pull in
setuptools >= 36, and as a result pip will fail to import
`setuptools.build_meta` in `pip/_vendor/pep517/_in_process.py`. and will
a `BackendUnavailable` exception thrown by `_call_hook()` in
`pip/_vendor/pep517/wrappers.py`. since the issue addressed by 30ce5e55
has been addressed since setuptools >= 36.0.1, we should be safe to
upgrade to the latest setuptools now.
Kefu Chai [Wed, 19 Dec 2018 08:37:55 +0000 (16:37 +0800)]
install-deps.sh: skip unavailable repos
as centos-sclo-rh-source leads us to 404 at this moment. and we are not
using the source repo for building ceph. so we can just skip any
unavailable repo.
Kefu Chai [Sat, 10 Nov 2018 21:33:43 +0000 (13:33 -0800)]
install-deps: install setuptools before upgrading virtualenv
this should address the failures when running install-deps.sh, like
Downloading/unpacking virtualenv
Running setup.py egg_info for package virtualenv
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'python_requires'
warnings.warn(msg)
error in virtualenv setup command: 'extras_require' must be a
dictionary whose values are strings or lists of strings containing valid
project/version requirement specifiers.
Complete output from command python setup.py egg_info:
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'python_requires'
warnings.warn(msg)
error in virtualenv setup command: 'extras_require' must be a dictionary
whose values are strings or lists of strings containing valid
project/version requirement specifiers.
this only happens on very old virtualenv shipped with RHEL7.4
Nathan Cutler [Wed, 1 Aug 2018 10:33:58 +0000 (12:33 +0200)]
build/ops: unify command substitution in install-deps.sh
The $() form is preferable to `` because folks (like me) might be using
` as a keyboard shortcut to GNU Screen, causing havoc to ensue whenever
copy-pasting the ` character.
install-deps.sh: install `python*-devel` for python*rpm-macros
in 087ea813, we installed '*rpm-macros' for the macros, so we can have
access to the latest python packaging related macros for preparing the
build dependencies.
but we could run into https://bugs.centos.org/view.php?id=16379, if
we already have an old version of python-devel installed. as the newer
version of python-rpm-macros conflicts with it.
it was a chicken-and-egg problem, as we don't know the exact name of
*rpm-macros packages. that's why we chose to install all of them. but
we have to upgrade the existing python-devel package to resolve the
conflict. but the since there is no python3-devel in RHEL7/CentOS7,
what they have is python36-devel. so we have to hardwire the
`%{python3_pkgversion}` to "36" even before we have access to this
macro, and upgrade the python36-devel package beforehand. but this
renders installing the rpm-macro package less useful -- we intend to
use the macro offered by the package to figure out "36".
as a workaround, we pretend that we know the "main" version of python3
in current RHEL/CentOS. and always install python36-devel for
python-rpm-macros. as the former requires the latter.
once all python3*-devel on all builders are upgraded, we will be safe
to install '*rpm-macros' again without installing python36-devel first.
by then, we could revert this change, or continue installing
python36-devel until the distro bumps up the "main" python version to 3.7
Brad Hubbard [Thu, 22 Nov 2018 00:07:22 +0000 (10:07 +1000)]
install-deps.sh: Remove CR repo
Remove the continuous release repos for CentOS and Virtuozzo 7 as they
should no longer be needed since http://tracker.ceph.com/issues/13997 is
no longer relevant and the newer versions of selinux packages pulled in
by the build system are causing problems for systems without CR repos
enabled.
Nathan Cutler [Wed, 1 Aug 2018 10:52:45 +0000 (12:52 +0200)]
build/ops: refrain from installing/using lsb_release in install-deps.sh
Unfortunately the mapping between release number and codename (which is only
relevant for Debian and Ubuntu btw) is not available from /etc/os-release.
In that one respect, lsb_release was "better".
However, when I weigh the advantages of obtaining that mapping from an external
tool, with the (substantial) risk that the external dependency might cause
trouble on one or more supported distros (to say nothing of the non- or
semi-/pseudo-supported ones), against the work involved in maintaining a
hard-coded mapping (negligible), the needle on my scale immediately swings
toward eliminating the dependency.
Also, I see this commit as part of the longer-term effort to completely expunge
lsb_release from our codebase. See git log --grep lsb_release.
For another example of an external distro-detection tool (albeit one that was
included in Python 2) gone awry, see http://tracker.ceph.com/issues/18163.
Kefu Chai [Thu, 28 Dec 2017 02:18:11 +0000 (10:18 +0800)]
install-deps.sh: check if have access to stdout
$- is "hB" if launched via command line, and it is "himBH" only when
we are actually *in* an interactive shell. so checking "test -t 1" is
what we want.
Kefu Chai [Fri, 8 Dec 2017 08:34:59 +0000 (16:34 +0800)]
install-deps.sh: use DTS on centos if GCC is too old
please note, run-make-check.sh sources install-deps.sh here to import
the $PATH and other environmental variables, which could be changed by
the the DTS "enable" script.
Nathan Cutler [Wed, 2 Oct 2019 12:19:04 +0000 (14:19 +0200)]
qa/rados/upgrade/jewel-x-singleton: do not run on Bionic
The test was failing because it did not explicitly set "os_type" and
"os_version", and teuthology defaulted to Ubuntu Bionic.
Jewel is not supported on Ubuntu Bionic, so we should not try to run tests on
that Ubuntu version.
NOTE: This commit is not cherry-picked from master because the fix is
luminous-specific (there is no "rados/upgrade/jewel-x-singleton" test after
luminous).
qa/rados/upgrade/jewel-x-singleton: set RBD_FEATURES
This commit cannot be cherry-picked from master because luminous is the only
non-EOL stable branch that still includes the
qa/rados/upgrade/jewel-x-singleton suite.
Kefu Chai [Wed, 7 Aug 2019 09:46:13 +0000 (17:46 +0800)]
admin/build-doc: use python3
to address https://github.com/sphinx-doc/sphinx/issues/3620, we need to
use sphinx with its fix at
https://github.com/sphinx-doc/sphinx/commit/e049f86b2de1cfdf8a74c88dc9593d047c85d5cb
in other words, we need to use sphinx v2.0.0 and up. but sphinx 2.0
requires python >= 3.5, so we have to use python3 for building the
documents.
in this change:
* doc-requirements.txt: install python3 packages on debian derivatives
* build-doc: install python3.6 packages from EPEL7, and use python3
venv for using sphinx2
* doc-requirements.txt: bump up all python packages to latest
stable.
ceph-volume: do not fail when trying to remove crypt mapper
In a containerized context, at some point, need to run `simple scan` on a device
from a separate container (not the existing and running corresponding container
to that device), but this can't work because when it tries to remove the
mapper which is still in use by the corresponding running osd container,
it fails.
This can be a bit more permissive and simply throw a warning.
This caused problems in environments where stderr was redirected, since
stderr sets the encoding to None. Getting it back again allows
everything to work correctly, and keeps all the current unit tests
passing
Brad Hubbard [Thu, 22 Nov 2018 00:07:22 +0000 (10:07 +1000)]
install-deps.sh: Remove CR repo
Remove the continuous release repos for CentOS and Virtuozzo 7 as they
should no longer be needed since http://tracker.ceph.com/issues/13997 is
no longer relevant and the newer versions of selinux packages pulled in
by the build system are causing problems for systems without CR repos
enabled.
Ilya Dryomov [Wed, 20 Feb 2019 21:30:29 +0000 (22:30 +0100)]
osdc/Objecter: invalidate crcs on preallocated rx buffers
Both simple and async messengers use c_str() when copying the data from
the socket into the receive buffer, going behind bufferlist's back. If
the receive buffer is preallocated, we need to invalidate its crc cache
by hand to avoid possible data crc mismatches on the client side.
Conflicts:
src/test/librados/io_cxx.cc
- In master, 3730d10623650ce8569be96b28cbba599a9a0db6 renamed this file from
src/test/librados/io.cc but that commit is not being backported to luminous.
Manually cherry-picked the test mods into src/test/librados/io.cc.
Josh Durgin [Sat, 24 Aug 2019 02:52:52 +0000 (22:52 -0400)]
os/bluestore: record gifts < expected size in superblock
Returning 0 from _balance_bluefs_freespace() skips recording
allocations in the superblock, so we fail the consistency check on
startup. The elseif branch handles this case already, so just remove
it from the first branch. This is luminous/mimic specific, since
bluefs extents are not recorded in the superblock in later releases.
Kefu Chai [Tue, 29 May 2018 07:51:07 +0000 (15:51 +0800)]
mds,osd,mon,msg: use intrusive_ptr for holding Connection::priv
See-also: http://tracker.ceph.com/issues/20924 Signed-off-by: Kefu Chai <kchai@redhat.com> Signed-off-by: Samuel Just <sjust@redhat.com>
(cherry picked from commit 72883956c26fdc4345324e9b27b45c3dfac17fa2)
Sage Weil [Mon, 19 Aug 2019 15:09:36 +0000 (10:09 -0500)]
os/bluestore: try to gift large extents, then fall back to small extents
First try to gift using the larger alloc_size (normally bluefs_alloc_size,
but here max(bluefs_alloc_size,bluefs_shared_alloc_size) just in case the
settings are weird. If that fails, then try the shared_alloc_size. If
that fails, fail and complain as before, with an more accurate error
message.
Sage Weil [Mon, 19 Aug 2019 13:46:09 +0000 (08:46 -0500)]
os/bluestore/BlueFS: apply shared_alloc_size to shared device
Keep an alloc_size vector so that we have this value handy at all times.
Allow bluestore to fetch this value directly instead of looking at the
bluefs_* config options since this encapsulates things a bit better, and
also isn't vulnerable to the config setting changing at runtime.
Sage Weil [Fri, 16 Aug 2019 21:44:57 +0000 (16:44 -0500)]
os/bluestore: cleanup around allocator calls
Both stupid and bitmap allocator returs -ENOSPC if they're
unable to allocate any space. Existing callers aren't always
respect this - hence doing some cleanup.
Kefu Chai [Sun, 24 Mar 2019 09:11:31 +0000 (17:11 +0800)]
ceph-volume: terminal: encode unicode when writing to stdout
python determins the encoding of stdout and stderr based on the LC_CTYPE
and PYTHONIOENCODING env variable, by default, python3's sys.stdout uses
'utf-8' as its encoding, so it will be able to write unicode string even
the stdout is not attached to a tty device. but when it comes to
python2, it will default to ascii if neither of these variabls is set.
so, if we are writing unicode using `_Write` in an environment where
LC_CTYPE and/or PYTHONIOENCODING are using non UTF-8 encoding, it chokes
by raising `UnicodeEncodeError` exception.
in this change, we add a wrapper around `_Write._writer` so it is able
to write unicode string in such a non-unicode-friendly environment.
for more info related the encoding of stdout and stderr, see
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONIOENCODING .
projects / ceph.git / log