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

Add redhat support to docker hypervisor #359

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

h0tw1r3
Copy link
Contributor

@h0tw1r3 h0tw1r3 commented Mar 13, 2024

Vendor provides universal base images with a permissive EULA.

Does UBI let me distribute my container images anywhere I want?

Yes. Building on UBI means Red Hat is never going to tell you where or how you can distribute your images. You can distribute your images wherever and however you like.

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

Nice. Do you have a PR somewhere that tests this out?

lib/beaker-hostgenerator/hypervisor/docker.rb Outdated Show resolved Hide resolved
@bastelfreak
Copy link
Member

In the past we enabled acceptance testing a few times when the OSes were already in the metadata.json. That's a bit tricky because that can break CI pipelines because there are unexpected new jobs for some OSes. We've RedHat listed quite often. I would love to see this merged, but we need to more sure that it passes on our modules and that the registry can handle some concurrent pulls (quay.io seems to be rather flaky :( )

@h0tw1r3
Copy link
Contributor Author

h0tw1r3 commented Mar 13, 2024

Will this impact existing pipelines until the puppet_metadata change is merged?

@bastelfreak
Copy link
Member

this will impact them as soon as we release beaker-hostgenerator and puppet_metadata as minor versions.

@ekohl
Copy link
Member

ekohl commented Mar 13, 2024

Looks like it fails because chrony/ntpdate isn't present in UBI. I knew it had a slightly filtered list and I guess this is one of them.

This means we need to update the packages to install.

Right now this is determined in a complex way:

I'm not sure what the best way to filter it out is without breaking non-Docker deployments. Perhaps reject some values in beaker-docker for RHEL?

Then we also find a way to exclude it from the testing matrix in https://github.com/voxpupuli/puppet-chrony. Perhaps some options to add in puppet_metadata?

@bastelfreak
Copy link
Member

I would like to see all the packages in beaker-docker moved to beaker. They really aren't docker specific.

@h0tw1r3
Copy link
Contributor Author

h0tw1r3 commented Mar 13, 2024

Looks like it fails because chrony/ntpdate isn't present in UBI. I knew it had a slightly filtered list and I guess this is one of them.

This means we need to update the packages to install.

Right now this is determined in a complex way:

* `host_packages(host)` determines which packages to install: https://github.com/voxpupuli/beaker/blob/0b477ea3f84bfdd053bad614f7a874ffbd233cf1/lib/beaker/host_prebuilt_steps.rb#L106-L153

* This is used in beaker-docker: https://github.com/voxpupuli/beaker-docker/blob/72dda38788e291394271bc186d7e20eb6ee1d241/lib/beaker/hypervisor/docker.rb#L498

I'm testing locally with a modification to https://github.com/voxpupuli/beaker/blob/0b477ea3f84bfdd053bad614f7a874ffbd233cf1/lib/beaker/host_prebuilt_steps.rb#L110 which filters time related packages if the host timesync option is disabled (which is a default I think).

I'm not sure what the best way to filter it out is without breaking non-Docker deployments. Perhaps reject some values in beaker-docker for RHEL?

Then we also find a way to exclude it from the testing matrix in https://github.com/voxpupuli/puppet-chrony. Perhaps some options to add in puppet_metadata?

Yes, filtering will need to be added. I suggest it be left up to the specific modules workflow as I suspect it will be a moving target over time.

@h0tw1r3
Copy link
Contributor Author

h0tw1r3 commented Mar 13, 2024

I would like to see all the packages in beaker-docker moved to beaker. They really aren't docker specific.

Agreed, it shouldn't be needed there as it's done in host_prebuilt_steps for all hypervisors.

@ekohl
Copy link
Member

ekohl commented Mar 13, 2024

I would like to see all the packages in beaker-docker moved to beaker. They really aren't docker specific.

As I described: we already have that since voxpupuli/beaker-docker@e126b70.

IMHO there is a benefit to installing packaging during container building: they're cached so if you rerun tests you don't need to install them again. It would be even better if we publish the built containers for even faster CI.

Though you did trigger me to look at Beaker::HostPrebuiltSteps and in validate_host it ensures the host packages are present. So just changing the definition in beaker-docker is probably insufficient.

That makes me think: can we actually refactor it so it's only installed if you actually timesync and do that for every OS? I opened voxpupuli/beaker#1853 as a start for that.

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

Successfully merging this pull request may close these issues.

3 participants