During the refactor of various daemon type classes some of the tests had
been converted to funkypatch in order to deal with imports occuring over
multiple files. However, this conversion was done piece by piece in
order to make clear what was changing. This left the functions in this
file inconsistent. Change all the remaining function to use funkypatch
for consistency.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Move the ceph classes (Ceph, OSD, CephExporter) along with a few heavily
linked functions to a new ceph.py file under the daemons dir.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Update tests to import should_log_to_journald from context_getters - the
module that actually defines that function. This makes later refactoring
easier.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Update the test that import dict_get and dict_get_join to use the
context_getters module - the module that actually defines the functions.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a shim function and convert to the use of the FunkyPatcher class in
the test_deploy.py test functions. Use a shim as to not have to change
all the tests (yet).
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The test_mon_crush_location test always seems to have me tinkering
with it during refactoring. Re-do the fixtures to use funkpatch instead
of mock.patch and normal monkeypatch. This looks nicer (IMO) and should
avoid having to frequently mess with it when moving functions during future
refactoring.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This fixture acts like a combination of mock.patch and pytest's
monkeypatch fixture. It has the additional feature of automatically
finding and patching the same object imported in other modules. If you
have 'from x import y', where y is a function or class, in both a.py and
b.py it will patch both instances (so long as both a and b are already
imported).
This behavior is useful for cephadm because of the heavy use of the
`from x import y` idiom and how cephadm is being actively refactored.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This function is roughly the same as make_var_run only it doesn't rely
on shelling out to the install command. Eventually, it will be used
to replace make_var_run in certain locations.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
allow admin users to repair broken iam policies that would otherwise
reject access on PutBucketPolicy/DeleteBucketPolicy requests
Fixes: https://tracker.ceph.com/issues/63485
Signed-off-by: Casey Bodley <cbodley@redhat.com>
use of `ACLGrant::get_id()` was awkward because most grantee types
returned nothing, but emails were returned as `struct rgw_user`. change
the internal representation into a variant, and expose getters for each
grantee type so callers can handle each type specifically. the encoded
format of `ACLGrant` remains unchanged
Signed-off-by: Casey Bodley <cbodley@redhat.com>
we no longer rely on polymorphism for the s3/swift variants of
`RGWAccessControlPolicy`, so `req_state` can store `bucket_acl`,
`object_acl` and `user_acl` by value
most functions now take these acls by const- or mutable reference
instead of pointers since they won't be nullptr
some code paths won't initialize some of these bucket/object/user acl
variables, and we rely on `RGWAccessControlPolicy::verify_permissions()`
to return false for those because we won't match an empty owner or
array of grants
in only one case, `verify_user_permissions()` has to return true when
`user_acl` is uninitialized, because S3 doesn't have user acls so
uninitialized user acls should not deny access
Signed-off-by: Casey Bodley <cbodley@redhat.com>
s3 acl parsing classes no longer inherit from the acl classes
themselves, and are all encapsulated in rgw_acl_s3.cc behind a single
rgw::s3::parse_policy() function
Signed-off-by: Casey Bodley <cbodley@redhat.com>
