Our test code uses CEPH_VERSION but (at least for now) the quay.ceph.io
ci container no longer sets that environment variable.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
In pr#1045 we disabled the test for main. It seems that the change
has now been backported to many other branches as the test began
failing on all pre-{quincy,reef,squid} cli jobs too.
Disable the test for pretty much all the active ceph branches.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Recent changes to the ceph ci images are removing the repo files, as
well as some other minor changes. We're working with ceph maintainers
to come up with a clean solution for all, but in the meantime
re-installing the ceph-release rpm recreates the file we need to
continue.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Now that we have removed the `yum update` step, it doesn't make sense to
install the matching development packages based on the version already
present with the base container image. This is due to the fact that
their availability is not always guaranteed. Instead leave it up to DNF
to figure out if higher versions are available with the repositories.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
In general it is not desirable to blindly update packages as a whole
while building another from a base container image.
Historically this step was required due to the introduction of version
specific installation[1] of packages i.e, we extract the package version
that comes with the base container image and try to install the matching
development libraries which might be unavailable close to a new release
happening in upstream. In order to overcome this short gap we came up
with the idea of `yum update`[2] to fetch whatever is the latest and
then extract the version for further installation of development
libraries.
This seemed to work until we discovered a different issue where updated
versions for particular dependencies are pushed to standard repositories
causing problems[3] during `yum update`.
Ceph repositories(and packages) are now more robust and DNF is capable
of handling such situations to figure out the new/updated versions for
packages even if a match is not found with the already installed package
versions. Ideally it can never be the case that matching packages for
each version are missing from a particular repository directory(only the
links to the directories is supposed to change).
Thus in our best interest we avoid running `yum update`.
[1] https://github.com/ceph/go-ceph/pull/331
[2] https://github.com/ceph/go-ceph/pull/510
[3] https://github.com/ceph/go-ceph/pull/1038
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Fix for https://tracker.ceph.com/issues/47287 is now available with
quincy and above releases. Therefore do not skip GetSnapTimestamp
API test for an invalid snap ID.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
There are backports created for fallocate API changes[1] that got merged
recently. Considering the time taken for these backports to get in to
release branches and finally as a released version we create a separate
test file to have more fine grained control over various pre-release CI
jobs with the help of corresponding build tags.
Modification of build tags should go hand-in-hand with the version
detection logic used in file_test.go once a backport is available in
released version.
[1] https://github.com/ceph/ceph/pull/59725
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
There has been an internal change with fallocate API[1] forcing us not
to run those fallocate tests which uses mode as 0. For now we skip those
tests on main branch.
[1] https://github.com/ceph/ceph/pull/59725
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Work around errors related to protobuf package locations on centos.
This is triggered by our squid jobs failing with errors like:
```
22.40 Problem: protobuf-3.14.0-13.el9.i686 from appstream does not
belong to a distupgrade repository
22.40 - package protobuf-compiler-3.14.0-13.el9.x86_64 from @System
requires protobuf = 3.14.0-13.el9, but none of the providers can be
installed
22.40 - cannot install both protobuf-3.14.0-14.el9.x86_64 from
appstream and protobuf-3.14.0-13.el9.x86_64 from @System
22.40 - cannot install both protobuf-3.14.0-14.el9.x86_64 from
appstream and protobuf-3.14.0-13.el9.x86_64 from appstream
22.40 - cannot install the best update candidate for package
protobuf-3.14.0-13.el9.x86_64
22.40 - problem with installed package
protobuf-compiler-3.14.0-13.el9.x86_64
22.40 (try to add '--allowerasing' to command line to replace
conflicting packages or '--skip-broken' to skip uninstallable packages
or '--nobest' to use not only best candidate packages)
------
```
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Following APIs have been replaced with more generic cephError type to
jointly indicate the source and error.
cephFSError.Error
cephFSError.ErrorCode
radosError.Error
radosError.ErrorCode
rbdError.Error
rbdError.ErrorCode
Therefore remove corresponding entries from API docs.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
The new GroupSnapGetInfo function can be used to get a list of the RBD
image snapshots that were created as part of the RBD group snapshot.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
man dlsym(3) says the following:
. . .
The _GNU_SOURCE feature test macro must be defined in order to obtain
the definitions of RTLD_DEFAULT and RTLD_NEXT from <dlfcn.h>.
. . .
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Certain operations with RBD can return the C errno EEXIST. Applications
using go-ceph benefit from easily detecting this error.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
'len' is already a standard library function. revive v1.4.0[1] started
looking into function related variables for such standard names as part
of redefines-builtin-id rule. Therefore use a different variable name
instead of 'len'.
[1] https://github.com/mgechev/revive/releases/tag/v1.4.0
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
'len' is already a standard library function. revive v1.4.0[1] started
looking into function related variables for such standard names as part
of redefines-builtin-id rule. Therefore use a different variable name
instead of 'len'.
[1] https://github.com/mgechev/revive/releases/tag/v1.4.0
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
- bump github.com/gofrs/uuid from v4.4.0+incompatible to v5.3.0
- bump golang.org/x/sys from v0.24.0 to v0.25.0
Signed-off-by: Pankaj Thapa <pk.thapa66@gmail.com>
!! Action Required !!
The configuration uses the deprecated merge_method attribute of the
queue action in one or more pull_request_rules. It must now be used
under the queue_rules configuration.
A brownout is planned on August 26th, 2024.
This option will be removed on September 23rd, 2024.
For more information: https://docs.mergify.com/configuration/file-format/#queue-rules
!! Action Required !!
The configuration uses the deprecated update_method attribute of the
queue action in one or more pull_request_rules. It must now be used
under the queue_rules configuration.
A brownout is planned on August 26th, 2024.
This option will be removed on September 23rd, 2024.
For more information: https://docs.mergify.com/configuration/file-format/#queue-rules
ref: https://docs.mergify.com/workflow/actions/queue/#parameters
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Add rados/striper to the implements tool. It needs to be recognized
as a new C-API wrapping library.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a package doc comment that also points out some things I learned
about how `rados` command line tool lists striped objects to preempt
being asked later on. :-)
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Start a new `rados/striper` package that wraps Ceph's libradosstriper.
The libradosstriper library builds on top of the librados library to
support striping large "objects" over multiple RADOS objects.
Fixes: #1011
Signed-off-by: John Mulligan <jmulligan@redhat.com>
