`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.
Signed-off-by: Kefu Chai <kchai@redhat.com>
When a secret and/or the mon addrs are not specified by the admin,
then mmap a MAP_SHARED buffer and spawn a child process to get that
info. For safety reasons, the child drops all capabilities other than
CAP_DAC_READ_SEARCH (to ensure that it'll be able to read the keyring,
should one be found). To achieve this, we add a new dependency on
libcap-ng.
Add a new C++ file with a single routine that will create a CephContext,
get a list of monitor addresses and scrape the keyring for a secret for
the specified cephx user.
If that info is found, then it is copied to fixed-length buffers in the
MAP_SHARED area and the child exits successfully.
The parent will then vet the returned info and copy it into the
appropriate fields if they are currently blank.
Fixes: https://tracker.ceph.com/issues/16656
Signed-off-by: Jeff Layton <jlayton@redhat.com>
On our 14GB build machines, 8 parallel jobs results in the compiler
going OOM. Reserving 2500MB per job allows it to succeed with 5 jobs.
Fixes: https://tracker.ceph.com/issues/41659
Signed-off-by: Dan van der Ster <daniel.vanderster@cern.ch>
Adds a mgr module to provide integration between
Ceph and the kubernetes events API within the rook-ceph
namespace. It provides several commands to view event
status including;
ceph k8sevents list .... show all k8s related events
ceph k8sevents ceph .... show events generated from this
module
ceph k8sevents status .. show status of the tracker threads
and counts of tracked events
Events sent to kubernetes are sourced from the
a) clog: ceph healtchecks and admin commands
b) explicit checks: hosts, pools and OSD states are checked
every 'n' seconds
Signed-off-by: Paul Cuzner <pcuzner@redhat.com>
these dependencies are only used for building python-saml which is in
turn used for the SAML support. this feature is tested using
`test_sso.py` while performing dashboard tests. we do not package or
ship python-saml along with other Ceph packages. so let's move these
dependencies to the "make check" sections in ceph.spec.in and
debian/control for simplifying install-deps.sh.
Signed-off-by: Kefu Chai <kchai@redhat.com>
but we still enable it in `run-make-check.sh`
* cmake: disable SPDK by default
* run-make-check.sh: enable WITH_SPDK so at least we can ensure it
builds
* deb,rpm: add uuid-dev / libuuid-devel as a "make check" dependency
Fixes: https://tracker.ceph.com/issues/41330
Signed-off-by: Kefu Chai <kchai@redhat.com>
since we dropped the support of xenial, we now have the luxury of using
newer CMake! and by using CMake 3.10.2, we can prevent libfmt from
assuming that we are using C++11, and hence set `CMAKE_CXX_STANDARD` to
11, which will literally append `-std=gnu++11` to `CMAKE_CXX_FLAGS`.
the last `-std` option passed to `g++` takes precendence.
since we've switched over to C++17, and we are using C++17 features.
so, using cmake older than 3.8 breaks the build. because it is CMake 3.8
which stared support `CMAKE_CXX_STANDARD` 17.
- for bionic: https://packages.ubuntu.com/bionic/cmake : 3.10.2
- for CentOS7:
https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ : 3.13.5
so in this change,
* bump up the required version to v3.10.2
* cleanups to wipe out the workaround for lower CMake versions
* use `PROJECT_VERSION` defined by `project()` command instead of
`VERSION` explicitly defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
python-common: Python common package
Reviewed-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
Reviewed-by: Ricardo Dias <rdias@suse.com>
Reviewed-by: Tim Serong <tserong@suse.com>
The recently introduced 'dashboard grafana dashboards update' command
requires the grafana dashboards for it to work properly. Adding the
dependency.
Signed-off-by: Boris Ranto <branto@redhat.com>
There is already pkgconfig(systemd) present, which, in SUSE's packaging,
translates to the same package (systemd.pc is shipped as part of the main
systemd package). Not explicitly mentioning 'systemd' as package name allows
the openSUSE Build Service though to find shortcuts by using the
bootstrap packages, i.e. systemd-mini (ABI/API complete).
Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org>
* refs/pull/22446/head:
relicense LGPL-2.1 code as LGPL-2.1 or LGPL-3.0
COPYING: add reference to a few Apache-2.0 licensed source files
debian/copyright: sync with COPYING
COPYING: LGPL2.1 -> LGPL-2.1
COPYING: extra bits from debian/copyright
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
Reviewed-by: Neha Ojha <nojha@redhat.com>
Reviewed-by: Sebastian Wagner <swagner@suse.com>
This commit adds "patch" as an explicit build dependency. Before, the RPM
build was installing it in the build environment via some mechanism that I
don't entirely understand.
The "patch" command is used by the BuildBoost cmake module.
Fixes: http://tracker.ceph.com/issues/40175
Signed-off-by: Nathan Cutler <ncutler@suse.com>
rpm: have pybind RPMs provide/obsolete their python2 predecessors
Reviewed-by: Tim Serong <tserong@suse.com>
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
The next patch adds netlink support to rbd-nbd. This patch just adds the
build related changes to bring in the netlink lib and test and build
against it.
Signed-off-by: Mike Christie <mchristi@redhat.com>
When upgrading from a Python 2 build to a Python 3 one, we need to make the
python3-* packages replace their Python 2 counterparts.
Fixes: http://tracker.ceph.com/issues/40099
Signed-off-by: Nathan Cutler <ncutler@suse.com>
rpm: Disable LTO in spec when being used.
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Tim Serong <tserong@suse.com>
Reviewed-by: Nathan Cutler <ncutler@suse.com>
Instead of self-written validation methods to validate IPv4 and IPv6 addresses.
Use Python's standard library functions `ipaddress`.
Signed-off-by: Ashish Singh <assingh@redhat.com>
The primary motivation to relicense is a desire to integrate with projects
that are licensed under the Apache License version 2.0. Although opinions
vary, there are some who argue the the LGPL-2.1 and Apache-2.0 licenses
are not fully compatible. We would like to avoid the ambiguity and
potential for controversy.
Projects we would like to consume that are Apache-2.0 licensed include
Seastar, OpenSSL (which is in the process of relicensing to Apache-2.0),
and Swagger (swagger.io). Note that some of these are dynamically linked
or consumed via a high-level language and may or may not require a change
to LGPL-3.0, but providing the option for LGPL-3.0 certainly avoids any
uncertainty.
A few other source files are already incorporated into Ceph that claim an
Apache-2.0 license:
src/common/deleter.h
src/common/sstring.h
src/include/cpp-btree
The Ceph developers would further like to provide a license option that is
more modern than the current LGPL-2.1. LGPL-3.0 includes updated,
clarified language around several issues and is widely considered
more modern, superior license.
Signed-off-by: Sage Weil <sage@redhat.com>
so user can install python3-rados, instead of python36-rados, without
specifying the minor version of python. also, we should not break our
teuthology tests with this naming scheme change. for instance, our
cephfs qa suite installs `python3-cephfs` for testing the `cephfs-shell`
Signed-off-by: Kefu Chai <kchai@redhat.com>
some of our centos7 jenkins builders are failing to build ceph master and
nautilus branches. because EPEL7 recently switched from python3.4 to
python3.6 as the native python3. see
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/message/EGUMKAIMPK2UD5VSHXM53BH2MBDGDWMO/
and one of our BuildRequires, cmake3,
was offered by EPEL7. it also followed the python3.6 switch-over to
rebuild against python3.6. as a result, the cmake3-data-3.13.4-2.el7
started to depend on /usr/bin/python3.6, which is in turn offered by
python36 package. after installing python36 as a dependency of the
updated cmake3. but in cmake, we originally checks for the latest
python3 interpreter if WITH_PYTHON3 is enabled, that's why these
builders which happen to install these updated packages started to fail
when detecting the existence of python3.6 related build dependencies.
as a fix, in d1e83082,
python%{python3_pkgversion}-{devel,setuptools,Cython} are listed as
BuildRequires to reflect this change in EPEL7. before d1e83082, we
hardwired them to python34-*.
but as following analysis puts, there are cases where `yum-builddep`
is inconsistent with `rpmbuild`. as `yum-builddep` changes the how
`python3_pkgversion` and `python3_version` macros are expanded:
- none of the packages installed by `yum-builddep` installs the python3
related rpm macros, so the system stays with whatever python3 it was
using. in this case, `rpmbuild` won't complain, as the
`python3_pkgversion` and `python_version` are consistent before and
after `yum-builddep`.
- system has python3.4 installed before `yum-builddep`. but
`yum-builddep` installed python3.6 and also the updated
`python-rpm-macros` packages, which points `python3_version` and
`python3_pkgversion` to 3.6 and 36 respectively. in this case,
`rpmbuild` will complain, because when we run `yum-builddep`,
`python3_version` was still "3.4".
- system does not have python3 installed before `yum-builddep`. so
it was using python34 for preparing the "BuildRequires". but some
of the packages installed by `yum-builddep` installs python36, and
also the updated `python-rpm-macros` packages, which points
`python3_version` and `python3_pkgversion` to 3.6 and 36 respectively.
in this case, `rpmbuild` will complain, because the python36 related
dependencies are missing. what the system has is python34
dependencies.
- system does not have python3 installed before `yum-builddep`. so
it was using python34 for preparing the "BuildRequires". but some
of the packages installed by `yum-builddep` installs python34, and
also the updated `python-rpm-macros` packages, which points
`python3_version` and `python3_pkgversion` to 3.4 and 34 respectively.
in this case, `rpmbuild` won't complain, as the
`python3_pkgversion` and `python_version` are also consistent before and
after `yum-builddep`.
as we cannot tell if the system has python3 or what the python3 version
the system has before `yum-builddep`, so what we can do is to ensure
`rpmbuild` has what it needs to build Ceph. so let's just stick with
python3.6.
Signed-off-by: Kefu Chai <kchai@redhat.com>
to force cmake to use the python3 and python3 modules for building
python3 bindings
on the debian side, it's okay to continue using "-DWITH_PYTHON3=ON", as
- cmake does normalize "ON" to 3
- debian's cmake extension lives on /usr/lib/python3/dist-packages/
not in a specific /usr/lib/python3.x/dist-packages directory
Signed-off-by: Kefu Chai <kchai@redhat.com>
ceph-common depends on librados2, but ceph-immutable-object-cache only
uses librados2's C++ API, so librados2 would suffice.
rpmbuild is able to figure out the .so dependencies, and let
ceph-immutable-object-cache depend on the package which offers
librados2, but we'd better make sure immutable-object-cache is linked
against the librados2 of the same version, to ensure that librados2
offers the correct C++ symbols. as we only version the C++ API in the
librados2 after nautilus.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* remove "libradospp1" from immutable-object-cache's runtime
dependencies. this package was removed in 65c8733b
Signed-off-by: Kefu Chai <kchai@redhat.com>
as immutable-object-cache has the prefix of "ceph", no need to use "-n"
option. so this change is but a cleanup.
* use "%package immutable-object-cache" not "%package
ceph-immutable-object-cache" for naming subpackage of
"ceph-immutable-object-cache". this would result in package name of
"ceph-immutable-object-cache". see
http://ftp.rpm.org/max-rpm/s1-rpm-subpack-spec-file-changes.html
* the same applies to other directives with "-n" options, see
http://ftp.rpm.org/max-rpm/s1-rpm-inside-package-directive.html
Signed-off-by: Kefu Chai <kchai@redhat.com>
seems devtools-8 is not packaged on aarch64. and we are suffering from
ICE on centos7 when building with GCC-7.3. so let's try GCC-8.2!
Fixes: http://tracker.ceph.com/issues/38892
Signed-off-by: Kefu Chai <kchai@redhat.com>
We do not build for RHEL 6 and below, so "rhel == 7" is just as good, while
also avoiding the bug.
In addition, "rhel == 7" is the conditional we are using everywhere else in the
spec file for this purpose.
Fixes: https://tracker.ceph.com/issues/38810
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The libstoragemgmt package is needed so we can activate the drive
blink-led feature so we should pull that package.
Signed-off-by: Sébastien Han <seb@redhat.com>
"Recommends" and other weak dependencies were introduced in rpm 4.12. it
is included by quite a few distros, including fedora 21 and up, and
recent SUSE distros. but RHEL7 still ships rpm 4.11. see
https://fedoraproject.org/wiki/Changes/RPM-4.12 and
https://software.opensuse.org/package/rpm . so we enable Recommends on
fedora and SUSE distros.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Without this patch, attempts to install the ceph-mgr-diskprediction-local RPM
fail on SUSE platforms with the following error:
can't install ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch:
nothing provides numpy needed by ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch
nothing provides scipy needed by ceph-mgr-diskprediction-local-14.1.0.402+ga396e8bf3b-3742.1.noarch
Also take into account package naming differences between Fedora and
RHEL/CentOS.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Nathan Cutler <ncutler@suse.com>
* refs/pull/26694/head:
rpm: drop use of $FIRST_ARG
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Tim Serong <tserong@suse.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
The "restful" MGR module is part of ceph-mgr, and is active by default when
deploying a Ceph cluster from scratch.
Without this patch, the cluster never reaches HEALTH_OK due to the following
health warning: "Module 'restful' has failed dependency: No module named
'OpenSSL'"
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The use of $FIRST_ARG was probably required because the SUSE-specific
%service_* rpm macros were playing tricks on the shell positional parameters.
This is bad practice and error-prone, so let's assume that no macros should do
that anymore and hence it's safe to assume that positional parameters remain
unchanged after any rpm macro call.
Thanks to Franck Bui for providing this patch.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Without this patch, the Python 2 version of python-remoto is always installed,
even on Python 3 systems.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
In very recent SUSEs (e.g. Leap 15.1), the build dependencies needed for the
lttng build are satisfied for this architecture.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Since the lttng-ust-devel and babeltrace-devel RPMs are not maintained for s390x
in openSUSE, we have to exclude the lttng build on this architecture.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
This reverts commit c32c4874e1.
An updated python2-kubernetes package that does not depend on
python-adal has made it into the epel7 repos. With that change,
we can now revert this patch.
When we readd it back though, add in %{_python_buildid} so that
this works correctly on python3-based distros as well.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
cmake,rgw: make amqp support optional
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Yuval Lifshitz <yuvalif@yahoo.com>
Reviewed-by: Willem Jan Withagen <wjw@digiware.nl>
In RHEL 8, rpmbuild does not automatically generate __pycache__
directories. Generate them explicitly with the %py_byte_compile macro.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
On RHEL 7, this package is named "pyOpenSSL", but on RHEL 8, Fedora, and
SUSE, it is named "python3-pyOpenSSL".
Prior to this change, the RHEL conditional was applying to both RHEL 7
and 8, so we would fail to resolve the "pyOpenSSL" package dependency on
RHEL 8.
Update the RPM conditionals to use "pyOpenSSL" on RHEL 7 and
"python3-pyOpenSSL" on all other distributions.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
On RHEL 8, the python34-* and Cython packages are named identically to
Fedora (eg "python3-Cython"). Move the Python 2 "Cython" and python34-*
BuildRequires lines inside a RHEL 7 conditional, so RHEL 8 falls through
to the Fedora package names.
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
* refs/pull/26237/head:
Revert "qa: update test_envlibrados_for_rocksdb.sh for libradospp split"
doc/librados: explicitly mention that the C++ API is not stable
ceph.spec: force use of upgrade devtoolset-gcc under RHEL 7
librados: add symbol versioning to the C++ API
librados: add symbol versioning to the C API
librados: revert librados3/libradoscc back to librados2
Reviewed-by: Kefu Chai <kchai@redhat.com>
The future goal would be to change the version for each Ceph major
release to ensure C++ applications will need to be recompiled against
the librados C++ API since we don't guarentee ABI stability.
Fixes: https://tracker.ceph.com/issues/38177
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
* refs/pull/26526/head:
rpm,deb: remove btrfs-tools as a build-dependency
rpm,deb: remove bc as a build-dependency
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
Reviewed-by: Nathan Cutler <ncutler@suse.com>
For backwards compatibility and upgrade reasons, the librados2
API needs to be preserved and it needs to continue to be compatible
with dependent libraries like librbd1.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
