Skip to content

rgw/test/lua: add lua integration tests suite#52931

Merged
yuvalif merged 2 commits intoceph:mainfrom
yuvalif:wip-yuval-lua-teuthology
Nov 24, 2023
Merged

rgw/test/lua: add lua integration tests suite#52931
yuvalif merged 2 commits intoceph:mainfrom
yuvalif:wip-yuval-lua-teuthology

Conversation

@yuvalif
Copy link
Contributor

@yuvalif yuvalif commented Aug 10, 2023

tested only locally, not tested in teuthology yet. copy&paste from the bucket notification test suite

Checklist

  • Tracker (select at least one)
    • References tracker ticket
    • Very recent bug; references commit where it was introduced
    • New feature (ticket optional)
    • Doc update (no ticket needed)
    • Code cleanup (no ticket needed)
  • Component impact
    • Affects Dashboard, opened tracker ticket
    • Affects Orchestrator, opened tracker ticket
    • No impact that needs to be tracked
  • Documentation (select at least one)
    • Updates relevant documentation
    • No doc update is appropriate
  • Tests (select at least one)
Show available Jenkins commands
  • jenkins retest this please
  • jenkins test classic perf
  • jenkins test crimson perf
  • jenkins test signed
  • jenkins test make check
  • jenkins test make check arm64
  • jenkins test submodules
  • jenkins test dashboard
  • jenkins test dashboard cephadm
  • jenkins test api
  • jenkins test docs
  • jenkins render docs
  • jenkins test ceph-volume all
  • jenkins test ceph-volume tox
  • jenkins test windows

@yuvalif
Copy link
Contributor Author

yuvalif commented Aug 10, 2023

@yuvalif yuvalif added the DNM label Aug 10, 2023
@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from 561a45a to 083a6eb Compare August 13, 2023 17:01
@yuvalif
Copy link
Contributor Author

yuvalif commented Aug 13, 2023

@yuvalif yuvalif marked this pull request as ready for review August 13, 2023 17:39
@yuvalif yuvalif requested a review from a team as a code owner August 13, 2023 17:39
@yuvalif yuvalif added needs-review and removed DNM labels Aug 13, 2023
@yuvalif
Copy link
Contributor Author

yuvalif commented Aug 14, 2023

jenkins test make check



@contextlib.contextmanager
def pre_process(ctx, config):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function was created for AMQP, so I think it's not needed here



#####################
# lau scripting tests

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cbodley can we add a symlink for this file as this is exactly same as we use it in bucket notifications?

@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from 083a6eb to c896495 Compare August 14, 2023 07:47

with contextutil.nested(
lambda: download(ctx=ctx, config=config),
lambda: pre_process(ctx=ctx, config=config),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed

@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from c896495 to 894e3e3 Compare August 14, 2023 08:22
return conn


def connection2():

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from 894e3e3 to 29e43e3 Compare August 15, 2023 06:53
@yuvalif yuvalif requested a review from TRYTOBE8TME August 15, 2023 06:53
parameters in your teuthology-suite command. Example command for this is as follows::

teuthology-suite --ceph-repo https://github.com/ceph/ceph-ci.git -s rgw:lua --ceph your_ceph_branch_name -m smithi --suite-repo https://github.com/your_name/ceph.git --suite-branch your_branch_name

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be great if you can add an example here of how we can use extra_attr in the yaml file.

@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch 4 times, most recently from 04a6154 to 595192c Compare October 16, 2023 05:48
@yuvalif yuvalif added the DNM label Oct 16, 2023
@yuvalif
Copy link
Contributor Author

yuvalif commented Nov 14, 2023

Comment on lines +181 to +190
attr = []

if 'extra_attr' in client_config:
attr = client_config.get('extra_attr')

args = ['cd', '{tdir}/ceph/src/test/rgw/lua/'.format(tdir=testdir), run.Raw('&&'),
'LUATESTS_CONF=./lua-tests.{client}.conf'.format(client=client),
'tox',
'./test_lua.py',
'-v']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those final two args are for pytest rather than tox, so didn't get used in the teuthology run; you need to put them after a -- to forward them to pytest

attr above is unused, but you might want to use it for filtering the pytest markers

the invocation in qa/tasks/s3tests.py looks like this:

args += ['tox', '--', '-v', '-m', ' and '.join(attrs)]

Copy link
Contributor

@cbodley cbodley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, merge when you're satisfied with the teuthology results

the packaging changes probably need backports, but i'm not sure about the suite itself - what do you think?

@cbodley
Copy link
Contributor

cbodley commented Nov 14, 2023

the run-tox-qa check is linting the python stuff and complains about:

./tasks/lua_tests.py:184:13: F841 local variable 'attr' is assigned to but never used

@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from c4df11e to 95cbb6a Compare November 20, 2023 11:45
@yuvalif
Copy link
Contributor Author

yuvalif commented Nov 20, 2023

the packaging changes probably need backports, but i'm not sure about the suite itself - what do you think?

it would probably be good to backport everything. in the future, when we fix bugs with lua we would probably add matching tests, so bug backports would be simpler if we backport the test suite

@yuvalif
Copy link
Contributor Author

yuvalif commented Nov 20, 2023

Signed-off-by: Yuval Lifshitz <ylifshit@redhat.com>
@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from 95cbb6a to eb21bc6 Compare November 23, 2023 16:34
Signed-off-by: Yuval Lifshitz <ylifshit@redhat.com>

Fixes: https://tracker.ceph.com/issues/63616
@yuvalif yuvalif force-pushed the wip-yuval-lua-teuthology branch from eb21bc6 to 46500ca Compare November 23, 2023 16:36
@yuvalif
Copy link
Contributor Author

yuvalif commented Nov 24, 2023

jenkins test api

@yuvalif yuvalif merged commit 2139231 into ceph:main Nov 24, 2023
@batrick
Copy link
Member

batrick commented Nov 28, 2023

This broke all testing on RHEL:

https://pulpito.ceph.com/rishabh-2023-11-28_13:00:50-fs-rishabh-2023nov26-testing-default-smithi/

"lua-devel" does not exist.

@batrick
Copy link
Member

batrick commented Nov 28, 2023

@yuvalif
Copy link
Contributor Author

yuvalif commented Nov 29, 2023

This broke all testing on RHEL:
https://pulpito.ceph.com/rishabh-2023-11-28_13:00:50-fs-rishabh-2023nov26-testing-default-smithi/
"lua-devel" does not exist.

https://tracker.ceph.com/issues/63672

we need the "codeready-builder" to be enabled for rhel8 in order to find that repo.
i see that in "install-deps.sh" but not in the teuthology logs above.
not sure where it should be set for it to work in teuthology.

@ThomasLamprecht
Copy link
Contributor

This adds liblua5.3-dev and luarocks as transitive dependency to ceph-common, as that depends on python3-rgw which depends on librgw2 where this PR adds the lua stuff as hardcoded dependency.

The liblua5.3-dev and luarocks packages themselves pull in a lot of development related dependency.
For example, on a Debian based system with ceph only used as a client, upgrading to Ceph Squid will install the following 65 (!) new packages:

autoconf automake autotools-dev cpp cpp-12 gcc gcc-12 libabsl20220623 libaom3 libasan8 libatomic1 libavif15 libc-dev-bin libc-devtools libc6-dev libcc1-0 libcrypt-dev libdav1d6 libde265-0 libdeflate0 libgav1-1 libgcc-12-dev libgd3
  libgomp1 libheif1 libisl23 libitm1 libjbig0 liblerc4 liblsan0 libltdl-dev liblua5.3-dev libmpc3 libmpfr6 libncurses-dev libnsl-dev libpkgconf3 libquadmath0 librav1e0 libreadline-dev libsvtav1enc1 libtiff6 libtirpc-dev libtool
  libtool-bin libtsan2 libubsan1 libwebp7 libx265-199 libxpm4 libyuv0 linux-libc-dev lua-any lua-sec lua-socket lua5.1 luarocks m4 manpages-dev pkg-config pkgconf pkgconf-bin rpcsvc-proto unzip zip

If this is only used for test suites, isn't there a better option for these dependencies? E.g., from top of my head the following might be a better fit (depending on how this is used exactly):

  • the Build-Depends field, if only run combined with a build
  • a new package that is intended to be installed if such tests are done, e.g. named ceph-integration-tests
  • the manifest defining the environment where this test a run, e.g. some docker file or the like.

@yuvalif
Copy link
Contributor Author

yuvalif commented Oct 28, 2024

This adds liblua5.3-dev and luarocks as transitive dependency to ceph-common, as that depends on python3-rgw which depends on librgw2 where this PR adds the lua stuff as hardcoded dependency.

The liblua5.3-dev and luarocks packages themselves pull in a lot of development related dependency. For example, on a Debian based system with ceph only used as a client, upgrading to Ceph Squid will install the following 65 (!) new packages:

autoconf automake autotools-dev cpp cpp-12 gcc gcc-12 libabsl20220623 libaom3 libasan8 libatomic1 libavif15 libc-dev-bin libc-devtools libc6-dev libcc1-0 libcrypt-dev libdav1d6 libde265-0 libdeflate0 libgav1-1 libgcc-12-dev libgd3
  libgomp1 libheif1 libisl23 libitm1 libjbig0 liblerc4 liblsan0 libltdl-dev liblua5.3-dev libmpc3 libmpfr6 libncurses-dev libnsl-dev libpkgconf3 libquadmath0 librav1e0 libreadline-dev libsvtav1enc1 libtiff6 libtirpc-dev libtool
  libtool-bin libtsan2 libubsan1 libwebp7 libx265-199 libxpm4 libyuv0 linux-libc-dev lua-any lua-sec lua-socket lua5.1 luarocks m4 manpages-dev pkg-config pkgconf pkgconf-bin rpcsvc-proto unzip zip

If this is only used for test suites, isn't there a better option for these dependencies? E.g., from top of my head the following might be a better fit (depending on how this is used exactly):

  • the Build-Depends field, if only run combined with a build
  • a new package that is intended to be installed if such tests are done, e.g. named ceph-integration-tests
  • the manifest defining the environment where this test a run, e.g. some docker file or the like.

adding lua-devel and luarocks is not for test suite.

  • lua-devel is needed for the lua scripting feature we have on the RGW: https://docs.ceph.com/en/latest/radosgw/lua-scripting/
  • luarocks (which, I assume, pull in most of the other dependencies) is needed for lua package support in the above feature. this is an optional feature, and can be disabled at build level by setting WITH_RADOSGW_LUA_PACKAGES=OFF.
    when building ceph with the above flag, lua-devel is still needed, but luarocks is not.

@ThomasLamprecht
Copy link
Contributor

Thanks for your reply.

lua-devel is needed for the lua scripting feature we have on the RGW: https://docs.ceph.com/en/latest/radosgw/lua-scripting/

Just to be sure: Is this a hard requirement on running ceph (client related) stuff or does it simply fail if one uploads a script without the Lua stack being available?
If it isn't a hard requirement on runtime then would you be fine with downgrading this to a Suggests for the Debian packaging control files, which is for optional dependencies that enhance the feature set.

If it is a hard requirement then I just have to ask if requiring Lua, including a whole c/cpp development stack that it pulls in by default, for every ceph client user isn't a bit overkill?
I mean, if this is a frequent use case and runtime availability detection is really not possible then I'm not sure if python3-rgw should be a dependency of the ceph-common package.

luarocks (which, I assume, pull in most of the other dependencies) is needed for lua package support in the above feature. this is an optional feature, and can be disabled at build level by setting WITH_RADOSGW_LUA_PACKAGES=OFF.
when building ceph with the above flag, lua-devel is still needed, but luarocks is not.

For Debian it's really lua-devel (well liblua5.3-dev), as that recommends pkg-config and libtool-bin which pulls in the rest, and installing recommends is enabled by default in Debian based systems. Now if that dependency relation is 100% correct/warranted is another question, changing that is definitely less doable for us, so I'm asking about other options.

FWIW, we exposed Ceph Squid on our test repos and users immediately noticed and increased package installations and compiler does mean bigger exposure of systems, so this all is stemming from real user concern, not just pure cosmetic ones; just to give you some context on why I bother with my questions.
Thanks!

@yuvalif
Copy link
Contributor Author

yuvalif commented Oct 28, 2024

@ThomasLamprecht in the RPM world (e.g. https://rhel.pkgs.org/8/okey-x86_64/lua-devel-5.3.4-10.el8.x86_64.rpm.html) I see that it also pulls in pkg-config (havn't seen anything on libtool-bin, but i think it is a debian package).

but regardless, for the RGW it is a hard requirement, the code won't compile without the lua header and won't load without the lua .so runtime.
if you don't need the RGW in your package, you can build without it (using WITH_RADOSGW=OFF). This should eliminate the lua requirement. If it does not, we should fix it.
if you do need the RGW, the only option is to add a new cmake flag that disables lua functionality completly.

@ThomasLamprecht
Copy link
Contributor

the code won't compile without the lua header

That part would be fine, as Debian can have this as build-dependency but not as (runtime) dependency,

and won't load without the lua .so runtime.

bummer, that isn't ideal for us, FWIW we probably could provide a no-op .so and document how to disable that if one really requires Lua scripted RGW response hooks.

if you do need the RGW, the only option is to add a new cmake flag that disables lua functionality completly.

We provide a more general distribution of Ceph, and while most of our users really do not need the RGW some still do, and we do not want to block them out completely.

if you do need the RGW, the only option is to add a new cmake flag that disables lua functionality completly.

That might be good to have for us as stop-gap. Out of interest, what are some common use cases for Lua scripting in RGW?

And could dynamically loading the Lua library only if required be another alternative here?

I did not check how this feature is implemented, so I might miss some rather obvious way this cannot work, but I imagine something along the lines of manually using dlopen and friends only if there is a Lua script is configured might allow having this functionality while not requiring a hard-dependency on the Lua related packages and all they pull in.

@yuvalif
Copy link
Contributor Author

yuvalif commented Oct 29, 2024

That might be good to have for us as stop-gap.

this would be the simplest to implement

Out of interest, what are some common use cases for Lua scripting in RGW?

And could dynamically loading the Lua library only if required be another alternative here?
I did not check how this feature is implemented, so I might miss some rather obvious way this cannot work, but I imagine something along the lines of manually using dlopen and friends only if there is a Lua script is configured might allow having this functionality while not requiring a hard-dependency on the Lua related packages and all they pull in.

we don't do that for other parts of the code, but it sounds possible

@cbodley
Copy link
Contributor

cbodley commented Oct 29, 2024

This adds liblua5.3-dev and luarocks as transitive dependency to ceph-common, as that depends on python3-rgw which depends on librgw2 where this PR adds the lua stuff as hardcoded dependency.

@ThomasLamprecht those rgw python bindings only cover the file-based rgw-nfs interface, which most rgw users won't need. dropping that from the ceph-common package may be the simplest solution

@ThomasLamprecht
Copy link
Contributor

Ah, thanks for that pointer, this was indeed an option that we wanted to evaluate as one of the short-term solutions for us here, so your comment saved us a bit of investigation time.

Ps. a colleague pointed out that the liblua5.3-dev dependency recorded in debian/control might be overkill, in Debian library packages are split in user (provides the .so file) and development (provides headers and possibly dev man pages) packages, so it could be good to switch that over to liblua5.3-0 and thus reduce what gets pulled in.

Further, it seems that luarock is not called if there isn't an allowlist at all, and if there is one gets an explicit error message logged if luarocks is not available, so this package dependency could be downgraded to a Recommends or maybe even a Suggests. I can prepare patches for this if you have no objection?

ThomasLamprecht added a commit to ThomasLamprecht/ceph that referenced this pull request Nov 7, 2024
One can attach lua scripts as sort of hooks to implement dynamic
checks or transformations of RGW requests since Ceph Pacific. Thus, a
lua library is now required for base support and optionally one can
use the luarocks deployment and management system for Lua modules to
use more advanced scripts/modules.

With commit 46500ca ("rgw/test/lua: add lua integration tests
suite") the dependency relations where cleaned up, as the respective
entries where missing completely from debian/control.

But that commit is pulling in much more than required due to adding
the devel package `liblua5.3-dev` instead of the library-only
`liblua5.3-0` one, and having `luarocks` as hard dependency compared
to an optional Suggests. Fixing that avoids pulling in a whole
build/compiler/autotools/... stack with 65 new packages just when one
wants to use librgw2 or python3-rgw for simple RGW requests, or just
needs the ceph-common package, which pulls in librgw2 transitively.

This was reported by prolific community member Neobin on the Proxmox
forum [0], and then discussed on the original PR, adding the
dependencies [1].

[0]: https://forum.proxmox.com/threads/156433/post-715148
[1]: ceph#52931 (comment)

Fixes: https://tracker.ceph.com/issues/68873
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
ThomasLamprecht added a commit to ThomasLamprecht/ceph that referenced this pull request Nov 7, 2024
One can attach lua scripts as sort of hooks to implement dynamic
checks or transformations of RGW requests since Ceph Pacific. Thus, a
lua library is now required for base support and optionally one can
use the luarocks deployment and management system for Lua modules to
use more advanced scripts/modules.

With commit 46500ca ("rgw/test/lua: add lua integration tests
suite") the dependency relations got cleaned up, as the respective
entries were missing completely from debian/control.

But that commit is pulling in much more than required due to adding
the devel package `liblua5.3-dev` instead of the library-only
`liblua5.3-0` one, and having `luarocks` as hard dependency compared
to an optional Suggests. Fixing that avoids pulling in a whole
build/compiler/autotools/... stack with 65 new packages just when one
wants to use librgw2 or python3-rgw for simple RGW requests, or just
needs the ceph-common package, which pulls in librgw2 transitively.

This was reported by prolific community member Neobin on the Proxmox
forum [0], and then discussed on the original PR, adding the
dependencies [1].

[0]: https://forum.proxmox.com/threads/156433/post-715148
[1]: ceph#52931 (comment)

Fixes: https://tracker.ceph.com/issues/68873
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
tchaikov pushed a commit to ceph/ceph-ci that referenced this pull request Jan 7, 2025
One can attach lua scripts as sort of hooks to implement dynamic
checks or transformations of RGW requests since Ceph Pacific. Thus, a
lua library is now required for base support and optionally one can
use the luarocks deployment and management system for Lua modules to
use more advanced scripts/modules.

With commit 46500ca ("rgw/test/lua: add lua integration tests
suite") the dependency relations got cleaned up, as the respective
entries were missing completely from debian/control.

But that commit is pulling in much more than required due to adding
the devel package `liblua5.3-dev` instead of the library-only
`liblua5.3-0` one, and having `luarocks` as hard dependency compared
to an optional Suggests. Fixing that avoids pulling in a whole
build/compiler/autotools/... stack with 65 new packages just when one
wants to use librgw2 or python3-rgw for simple RGW requests, or just
needs the ceph-common package, which pulls in librgw2 transitively.

This was reported by prolific community member Neobin on the Proxmox
forum [0], and then discussed on the original PR, adding the
dependencies [1].

[0]: https://forum.proxmox.com/threads/156433/post-715148
[1]: ceph/ceph#52931 (comment)

Fixes: https://tracker.ceph.com/issues/68873
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Jayaprakash-ibm pushed a commit to Jayaprakash-ibm/ceph that referenced this pull request Jan 9, 2025
One can attach lua scripts as sort of hooks to implement dynamic
checks or transformations of RGW requests since Ceph Pacific. Thus, a
lua library is now required for base support and optionally one can
use the luarocks deployment and management system for Lua modules to
use more advanced scripts/modules.

With commit 46500ca ("rgw/test/lua: add lua integration tests
suite") the dependency relations got cleaned up, as the respective
entries were missing completely from debian/control.

But that commit is pulling in much more than required due to adding
the devel package `liblua5.3-dev` instead of the library-only
`liblua5.3-0` one, and having `luarocks` as hard dependency compared
to an optional Suggests. Fixing that avoids pulling in a whole
build/compiler/autotools/... stack with 65 new packages just when one
wants to use librgw2 or python3-rgw for simple RGW requests, or just
needs the ceph-common package, which pulls in librgw2 transitively.

This was reported by prolific community member Neobin on the Proxmox
forum [0], and then discussed on the original PR, adding the
dependencies [1].

[0]: https://forum.proxmox.com/threads/156433/post-715148
[1]: ceph#52931 (comment)

Fixes: https://tracker.ceph.com/issues/68873
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants