Google Testing Framework is included by default within the Google
C++ Mocking Framework. Update makefiles to use new gmock/gtest
libraries and remove old gtest source code.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
install-deps.sh installs the dependencies based on the content of
debian/control (if apt-get is found) or ceph.spec.in (if yum is
found). The manually maintained list of dependencies for deb based
operating systems (deps.deb.txt) and rpm based operating
systems (deps.rpm.txt) are deprecated.
http://tracker.ceph.com/issues/10175Fixes: #10175
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Use sftp to upload to a directory that only this user and ceph devs can
access.
Distribute an ssh key to connect to the account. This will let us revoke
the key in the future if we feel the need. Also distribute a known_hosts
file so that users have some confidence that they are connecting to the
real ceph drop account and not some third party.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
Wheezy's udev (175-7.2) has broken rules for the /dev/disk/by-partuuid/
symlinks that ceph-disk relies on. Install parallel rules that work. On
new udev, this is harmless; old older udev, this will make life better.
Fixes: #4865
Backport: cuttlefish
Signed-off-by: Sage Weil <sage@inktank.com>
Two fixes for Centos 6.3 and other systems with udev versions
prior to 172. The disk peristant name using the GPT UUID does
not exist, so use the by_path persistent name instead for the
journal symlink.
The gpt label fields are not available for use in udev rules. Add
ceph-disk-udev wrapper script that extracts the partition
type guid from the label and calls ceph-disk-activate if it is
a ceph guid type. (Bug #4632)
Signed-off-by: Gary Lowell <gary.lowell@inktank.com>
The problem:
- the unittests link against gtest, and gtest is not installed. that's
normally fine, but...
- rbd and rados api unit tests link against gtest, and are installed
by 'make install'. they are needed for teuthology runs, etc.
- if we build gtest as an .la library, we can only control whether *all*
or *no* .la libraries are linked statically.
- we want librados to be linked dynamically.
The solution:
- build gtest as .a instead of a libtool library
- link it statically, always.
Unit test binaries are bigger now. Oh well...
Fixes: #2331
Signed-off-by: Sage Weil <sage@inktank.com>
Apparently "make distcheck" has been broken for 3 months;
I find that hard to believe, but that's what it looks like.
Signed-off-by: Tommi Virtanen <tommi.virtanen@dreamhost.com>
Formerly, we only built gtest when doing 'make check'. However, the
librados-api tests, which are built in debug mode for the 'all' target,
also use gtest. So build it when needed.
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
An optional argument points can tell it where to put
generated files (in this case, virtualenv). Provide
the argument in Makefile.am.
Options are still passed to cram, so you can say
"./src/test/run-cli-tests -i".
Uses a python package "cram" as test runner.
Requires PIP (python-pip.deb) installed on the
build machine, to actually run these tests.
The cram application itself is included as a
tarball that gets installed in a virtualenv
when the tests are run. cram is GPL.
Use ``make check`` to run the tests.
The src/gtest directory comes from ``svn export
http://googletest.googlecode.com/svn/tags/release-1.5.0 src/gtest``
and running "git add -f src/gtest".
gtest is licensed under the New BSD license, see src/gtest/COPYING.
For more on Google Test, see http://code.google.com/p/googletest/
Changed autogen.sh regenerate gtest automake files too. Make sure to
run ``./autogen.sh && ./configure`` after merging this commit, or
incremental builds may fail. The automake integration is inspired
heavily by the protobuf project, and may still be problematic.
Make git ignore files generated by gtest compilation.
Currently putting in just one new-style unit test, refactoring old
tests to fit will come in separate commits.
Note: if you are starting daemons, listening on TCP ports, using
multiple machines, mounting filesystems, etc, it's not a unit test
and does not belong in this setup. A framework for system/integration
tests will be provided later.
