Refactor the previous ListOmapValues logic into a new read op step
that can be used for iteration over the results of the operation. The
previous function is now based on the ReadOp.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Reimplement SetOmap in terms of a new SetOmap function on the WriteOp.
Now the actions of the write op can start to be atomically chained the
way WriteOps are supposed to.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a new error that will be returned from a op step method if the
method is called before the step is ready to provide data - like
when the operation has not yet been performed.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The WriteOp type will manage librados write operations and the
corresponding functions that ceph names like rados_write_op_*.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This utility function avoids having to have a custom finalizer for every
op step. It calls the free() function to release any allocated C memory
the step may have.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Now that the new year has arrived this test assertion has started to
fail. This is because, although I anticipated the year would eventually
change and used GreaterOrEqual, the argument order is wrong. My excuse
is that I find the argument order in testify's Equal function confusing,
it causes me to assume other functions in testify are also confusing
(even when it's the "normal" order) and/or I copy and pasted from an
Equal line and didn't change the args (both are true!).
Instead of allowing any old year, we assume that the clocks where the
test are run are in sync enough that the current year is correct for
the assertion (thanks for the suggestion Sven).
Happy new year, go-ceph!
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The "extended-review" label indicates that review is likely to take
an extended period of time and for bots to not automatically take
a PR.
This avoid the need to preemptively mark a PR as changes needed or
give a false impression with a "do-not-merge" tag, which has a subtle
lack-of-quality implication.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This flagSet type allows the user to also set the value of the retain
snapshots flag, something unique to subvolume removal (all others had
the force flag only).
Signed-off-by: John Mulligan <jmulligan@redhat.com>
To prepare for multiple flags types, we create a flagSet interface and
break out the functionality that was in Update into a per-type method
and then the common "merger" function.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a Truncate method to File type. Note the doc comment as I hit
a bug in ceph when writing the first test cases. Go-ceph will behave
as ceph here - so using go-ceph with an unfixed version of the
ceph libs will also exhibit the bug.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
In order to provide the ability to do thick provisioning of RBD images,
Image.WriteSame() can be used. The `rbd` commandline utility calls the
rbd_writesame() function when an image is created with the
`--thick-provision` option.
See-also: ceph/ceph-csi#1675
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The LIBRADOS_OP_FLAG_* constants can be passed to rbd_writesame() and
other operations that will be added in the future.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Although it seems to be stable with the current Go versions,
unsafe.Pointers that are created by applying arithmetic on nil
pointers are explicitly not allowed[1], and could potentially lead to
panics by the garbage collector. To be on the safe side, this change
goes back to minimal inline wrappers for the callback registrations,
which should be zero-cost. For the callbacks themselves fortunately
no wrappers are required, because CGo happily converts void* to
uintptr arguments. The potentially problematic VoidPtr helper is
removed again.
[1] https://golang.org/pkg/unsafe/#Pointer
Signed-off-by: Sven Anderson <sven@redhat.com>
The former code assumed a LIFO usage, and otherwise always produced
collisions. This change uses unique IDs instead, that as a
side-effect might make debugging easier.
Signed-off-by: Sven Anderson <sven@redhat.com>
We had been using setup-go@v2-beta for a while, before v2 was out.
Now v2-beta is out of data and generating warnings in the github
actions ui.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Enabling Smart-mode for "Strict Merge" causes Mergify to do a rebase of
the PR before merging. The rebase will trigger CI runs again, and
merging will be done only when the CI results are successful.
See-also: https://docs.mergify.io/actions.html#merge
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The function is named ListMetadata but returns a map of all
the metadata assigned to the rbd image. It is named ListMetadata to
match the C librbd api call.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Like the metadata functions were recently moved to a separate file,
move TestImageMetadata to a matching metadata_test.go file.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
As rbd.go is very long, and the get-/set-/remove- metadata functions in
rbd.go make a nice logical unit, move them to a new metadata.go file.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Unfortunately it is not recommended to use a regular expression to check
for the CI status of multiple tests. In case some tests do not run and
fail to report the status, Mergify will not know something is wrong and
PRs might get merged.
The only way to make sure all status checks have passed successfully, is
to list them all separately.
See-also: https://docs.mergify.io/conditions.html#validating-all-status-check
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Recently, changes to ceph nautilus reminded me that due to the low rate of PRs we don't always catch things that change in our dependencies right away. I propose adding a daily CI run that help catch these kind of things sooner and can help distinguish between a PR related failure and random flakiness and upstream changes.
These rules for Mergify do the following:
1. dismiss review +1's when a PR is updated
but keep any -1 reviews, so the reviewer needs to confirm the update
addresses the comment(s)
2. merge the PR when there are 2 (or more) positive reviews, and no
negative ones
don't merge when the 'do-not-merge' label is added to the PR
also require that the status checks (CI) has passed
3. in case there are merge conflicts, Mergify will leave a message
asking for a rebase
Documentation: https://docs.mergify.io/configuration.html
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Due to a new ceph nautilus the workflow test was breaking because the
existing code failed to anticipate the "subvolume uuid" in the path
to the snapshot data. This is the curse of writing code without anything
to test it against. I also add a very short delay just to give us
a chance to avoid issues in the future in case the snapshot creation
is not quite synchronous.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Apparently, this feature is being removed from all active ceph versions
and will not be present in future versions. Since we won't be able to
test it any more, and the api is provisional still, we just remove it
entirely.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This doesn't touch every call in cephfs admin, but does try to act like
a real application, or set of applications would: reading and writing
data as well as using the api to create and manage subvolumes,
snapshots, and clones.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Some versions of ceph return a list of supported features for a
subvolume. On versions that don't return this field the list will always
be empty.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
For users who need to know the pools (by name) as well as the files
systems, we add ListFileSystems which is similar to 'ceph fs ls', rather
than the existing ListVolumes as that function is simlar to 'ceph fs
volume ls' and that does not return pool information.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
