Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virt-customize: do not inject any RPMs #686

Open
ignatenkobrain opened this issue Jul 20, 2018 · 12 comments
Open

virt-customize: do not inject any RPMs #686

ignatenkobrain opened this issue Jul 20, 2018 · 12 comments

Comments

@ignatenkobrain
Copy link
Contributor

This would not work if there are conflicting subpackages. Also it's much better to leave decision of which packages to install to the job.

@johnbieren
Copy link
Contributor

Leave decision of which packages to install to the job? So package foo is built in Koji. It creates 5 rpms. foo-bar.rpm, foo-baz.rpm, foo-one.rpm, foo-two.rpm, foo-three.rpm. How is this fully automated system supposed to know which rpms to install? How is the pipeline job supposed to know? Should it have a static list for every single package that exists so it knows when curl comes through, don't install curl minimal? I don't see any fix for this that can be written in an automated way that is better than trying to install whatever rpms get pulled down from the completed koji build.

@ignatenkobrain
Copy link
Contributor Author

Leave decision of which packages to install to the job?

Exactly!

@johnbieren
Copy link
Contributor

Job == Jenkins Pipeline. How is it supposed to know?

@ignatenkobrain
Copy link
Contributor Author

@johnbieren just do not install any RPMs in virt-customize.sh

@johnbieren
Copy link
Contributor

Then when will they be installed? They need to be installed to test them

@ignatenkobrain
Copy link
Contributor Author

Playbook which runs from package-test.sh could install them.

@johnbieren
Copy link
Contributor

Hmm interesting. That would have to be taken up with Miroslav's team, as that would be a change to standard-test-roles playbooks. If the installation was moved there, the check that the proper nvrs are installed would hopefully be moved inside as well.

@johnbieren
Copy link
Contributor

@thrix ^^

@thrix
Copy link

thrix commented Jul 27, 2018

@Andrei-Stepanov ^^ :)

@thrix
Copy link

thrix commented Jul 27, 2018

the thing is, the staging of the packages to install is currently defined as a responsibility of the test system (the ci pipeline). Most packages which we have tests for are relying on the installation of the koji build. So we cannot just remove it. I believe the correct solution is to give @ignatenkobrain a solution to specify which packages to install (or blacklist). Or even, in the most extreme case, just do not install the packages at all and let the test handle it.

@thrix
Copy link

thrix commented Jul 27, 2018

We should start defining a ci.yml file for these cases. this is just one of the stuff we will need to custumize. This file than should be used by the CI system to customize the test environment preparation etc.

@Andrei-Stepanov
Copy link
Contributor

Andrei-Stepanov commented Jul 27, 2018

Playbook which runs from package-test.sh could install them.

Playbook is STR/STI.
Playbook doesn't not prepare test-environment.
STR takes test-environment as an input.

From: https://fedoraproject.org/wiki/CI/Standard_Test_Interface
Test environment: environment where actual test run takes place. Test has direct impact on test environment.

STI/STR tests test-environment.
Test-environment preparation is not part of STI/STR (playbook).
Test-environment preparation is out of scope STI/STR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants