Task #6512
closed
Add a PULP_UNDER_TEST setting that can enable viewsets and additional RQ tasks
Description
Motivation¶
Here are a few challenges that came up recently that we haven't been able to solve:
-
We wanted to test parent/child feature of pulpcore, but we couldn't because we couldn't write test tasks that provide basic exercising of the functionality.
-
pulp_ansible has scale testing tasks which need can only be called if RQ workers discover them during their normal startup. As it is these tasks are actually runable on production environments.
-
The migration plugin calls an the RPM publish task synchronously and not from the usual viewset that dispatches an RPM publication. The normal viewset contains assumptions which prevent a good test us from calling it like usual because that's not how the migration plugin code will use it. Thus we need "a test viewset" and a "test task" which can mimic how the migration plugin calls the task syncronously to create the publication.
Solution¶
Create an optional import codepath for pulpcore viewsets and RQ tasks. If the PULP_UNDER_TEST setting is equal to True then the test_viewset.py and test_tasks.py modules are loaded and if unset or set to anything other than True are not imported. This would be done using import_module.
The first two motivations I don't know how to solve otherwise.
For the RPM test, is there an option where we have the functional test from the migration plugin actually run? Rather than "making test viewsets or tasks" like any functional test it would actually run the migration code which would cause the syncrhonous RQ call, etc. Is that an option?
Maybe instead of an option we could provide a debugging plugin that add those views.
mdellweg wrote:
Maybe instead of an option we could provide a debugging plugin that add those views.
I like the idea of not having a setting. Having a production setting that is for testing is probably not the best idea (that I proposed). There are two challenges though with a single plugin. 1) the extra tasks and viewsets need to be versioned with the tests and 2) contributing to two repos for each test is likely unworkable. Having everything go to the plugin repo would be ideal. Still though, the "test setting" is probably not a good idea.
Another option is to have each package ship a second "test package". Maybe that is good, but then we would need to release two things to nightly, etc. Maybe that is a better outcome though if it's automated.
Ok, that was just a quick thought needed to get out. Maybe it helps to see an example of one of the tasks / views needed.
Are they plugin specific or is it only about pulpcore?
I don't know, whether publishing a debug/test plugin is a good idea. I have strong faith that the moment this is pip installable it will be used in production somewhere. Would it be sufficient to be installable from source?
- Status changed from NEW to CLOSED - WONTFIX
We will not get to this any time soon. Let's revisit when we have time.
Also available in: Atom
PDF
.