Fixes #35270 - Enable boot image download

[bastian-src]

Manage ISO images as Installation media. Refers to this PR.

Includes the following changes:

• Implement fetch and extract boot image
• Apply correct file permissions
• Implement classes for file extraction and permission changes

ToDo: Add tests.

[ekohl]

We should also expose this as a capability. In https://theforeman.org/2019/04/smart-proxy-capabilities-explained.html I've explained this, but this allows the Foreman side to know if the API is supported. You could even look up the presence of 7z and only present the capability if it's present. That's another way of dealing with it.

Of course the Foreman side also needs to be modified to respect this.

[ekohl]

I left some comments about the command task. Perhaps ArchiveExtract shouldn't call super at all in start but rather implement its own logic.

[bastian-src]

We should also expose this as a capability. In https://theforeman.org/2019/04/smart-proxy-capabilities-explained.html I've explained this, but this allows the Foreman side to know if the API is supported. You could even look up the presence of 7z and only present the capability if it's present. That's another way of dealing with it.

Of course the Foreman side also needs to be modified to respect this.

I had a look at your comment and I think it makes totally sense to have such a capability handling for this feature. I just added this commit from what I see from other modules (like the bmc plugin here) and your blog post. Can you maybe give me an example how the capability is checked on the Foreman-side? I would implement it then before triggering the iso image download API.

[bastian-src]

@ekohl coming back to this. I've added tests for the tftp_boot_image_api with respect to the tests of httpboot. The tests run fine when executing them on-by-one. Unfortunately, my tests fail by checking the capabilites here when I want to execute all tests at once. I think the which function is not available in the testing context. Is there an approach to mock this for testing?

Moreover, I'd like to know whether we could also trigger the bootimage_download API endpoint within a Foreman job task. I think this might make it more easy to handle concurrency?

[bastian-src]

@ekohl tests are green.

The /fetch_system_image API endpoint is not a dangling API call anymore. It triggers another thread which downloads the OS image file and extracts the boot files accordingly. Moreover, I tried to make the API endpoint concurrency safe by including a lock. The endpoint returns a status accordingly:

• 200: image and boot files exist already - no need to do anything
• 202: any of the files does not exist - process triggered
• 423: another download/extraction process is still running (resource locked)
• 500: any other error (input error for example)

What do you think about it? Can we continue with the foreman-side of this feature?

[bastian-src]

@ekohl I've also added PRs for foreman-installer and foreman-packaging due to the new settings variable and package dependency.

[bastian-src]

@ekohl do you know why there are no test results? Did I forgot anything, maybe?