@vashirov
Hi, could you please review this when you have time?
Thanks!

Is there a better location than /tmp we could use? This could be locked down in some cases, or have other permission faults present that could influence the test? Could we instead use the instances ldif directory?

Uhhhh you can't do this. You need to have test_import_data_to_target_host be in the same file as test_export, and you probably need thedata create + export as a fixture. Imagine I ran just "test_import_data_to_target_host", this would fail in a clean env as /tmp/standalone.ldif doesn't exist.

@firstyear
I used /tmp directory because our ansible role will copy the file between hosts and it was shortest path. But I could probably move it to ldif directory because instance should be already created on target host when copying.

As for the separate files:
Both of these tests are meant to be executed with a help of ansible role, that is why we need it in separate files, because they won't be run in our "standard environment".
That's what we have the skipif for, because MIGRATION constant is meant to be created only in that environment with help of ansible.

I agree, let's change ldif file location to the default dirsrv ldif directory.

@firstyear

Uhhhh you can't do this. You need to have test_import_data_to_target_host be in the same file as test_export, and you probably need thedata create + export as a fixture. Imagine I ran just "test_import_data_to_target_host", this would fail in a clean env as /tmp/standalone.ldif doesn't exist.

To add what @bsmejkal said, think of RHDS 10 -> RHDS 11 migration. There is no easy way to do multihost tests with pytest in our case (different python versions on RHEL 7 and 8, different additional setup is required to prepare system under test, rpms vs modules, etc). So we offload all of that to ansible (which is good at it) and run only the actual migration steps in pytest.

@firstyear
I used /tmp directory because our ansible role will copy the file between hosts and it was shortest path. But I could probably move it to ldif directory because instance should be already created on target host when copying.
As for the separate files:
Both of these tests are meant to be executed with a help of ansible role, that is why we need it in separate files, because they won't be run in our "standard environment".
That's what we have the skipif for, because MIGRATION constant is meant to be created only in that environment with help of ansible.

You can't assume people have this ansible role in our upstream tests. Perhaps you should be shipping with an ldif in a data dir from exports of a specific version or something then? We have other examples of this I think.

You can't assume people have this ansible role in our upstream tests. Perhaps you should be shipping with an ldif in a data dir from exports of a specific version or something then? We have other examples of this I think.

And we don't assume! That's why these test cases are skipped by default. You won't run them by accident in your environment.
And please keep in mind, this is a first test in a series, we need to streamline our testing workflow for this.

I wonder if there is a better self contained approach here - lib389's tests are great because you can run them with very little extra setup. Given the only data needed is "an ldif" here, I still think ansible here is overkill for the purpose of testing the upgrades. Maybe there is just something about the test you have in mind that I'm not seeing.

I wonder if there is a better self contained approach here - lib389's tests are great because you can run them with very little extra setup.

That's not entirely true. Try to run them on RHEL7 or RHEL6. Only recently python3 package has appeared in RHEL7.7. Before that the best option was to use SCL. Other lib389 dependencies are also outdated on these releases, so you would need gcc and -devel packages to install python-ldap or python-nss from pypi. So it requires some non-trivial amount of efforts to make an old RHEL system ready to run pytest.

Given the only data needed is "an ldif" here, I still think ansible here is overkill for the purpose of testing the upgrades. Maybe there is just something about the test you have in mind that I'm not seeing.

It's for testing migration, not upgrade. So it involves 2 different systems. We're automating scenarios covered in https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/installation_guide/migrating_from_rhds_9_to_rhds_10

@vashirov @firstyear
Changed exported ldif file location to the default dirsrv ldif directory. Please review.
Thanks!

Thank you, LGTM.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3617

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.