Bug 1686146
| Summary: | composer cannot build images after repositories are refreshed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Terry Bowling <tbowling> |
| Component: | lorax-composer | Assignee: | Brian Lane <bcl> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Robert M Williams <rwilliam> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.6 | CC: | elpereir, sbueno, tbowling, wwoods |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
.Image Builder no longer fails to update a blueprint component to the last version
Previously, Image Builder failed to solve dependencies or create images after a local repository mirror was refreshed. As a consequence, it continued to show the old version of the blueprint components. This update fixes the problem.
As a result, dependence solving and image composes succeed.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-22 21:48:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
related bz https://bugzilla.redhat.com/show_bug.cgi?id=1686151 regarding inability to update the blueprint after this scenario occurs Did you edit the blueprint to set the version to 2.7.7? In the blueprint you pasted all the versions are exact, not globs, so the depsolve will fail the first time a .z is bumped. Restarting lorax-composer should pick up the changes, but if that fails cleaning out /var/tmp/composer/* will always make it download new metadata. So that's why I'm asking about changing the blueprint. I can't see any way for depsolve to fail if the cache has been cleared and the version has been changed to either 2.7.7 or 2.* The metadata timeout is currently set to 6 hours, so it is possible for a blueprint depsolve to fail if the repo changes. If you do a compose it will always update the metadata, so if the blueprint is correct it will grab the new metadata and depsolve correctly. I don't know how to solve this without a big red 'refresh the repo metadata' button. If we lower the metadata timeout timer it increases traffic to the repos, and slows down depsolving (eg. worst case is if it checked on every depsolve call). (In reply to Brian Lane from comment #6) > Did you edit the blueprint to set the version to 2.7.7? In the blueprint you > pasted all the versions are exact, not globs, so the depsolve will fail the > first time a .z is bumped. I did not modify the blueprint, so those are defined by composer. When I look at some of the other blueprints, such as example-http-server.toml, it too has some packages defined with exact version rather than globs. > > Restarting lorax-composer should pick up the changes, but if that fails > cleaning out /var/tmp/composer/* will always make it download new metadata. > So that's why I'm asking about changing the blueprint. I can't see any way > for depsolve to fail if the cache has been cleared and the version has been > changed to either 2.7.7 or 2.* Yeah, it never seems to pick up the changes for any of the tests I do. And it seems to automatically populate the exact versions of packages for any blueprint I create from the GUI. I've never seen it use the '*' globs. > > The metadata timeout is currently set to 6 hours, so it is possible for a > blueprint depsolve to fail if the repo changes. > > If you do a compose it will always update the metadata, so if the blueprint > is correct it will grab the new metadata and depsolve correctly. this seems to consistently fail for me, unless I'm missing something. > > I don't know how to solve this without a big red 'refresh the repo metadata' > button. If we lower the metadata timeout timer it increases traffic to the > repos, and slows down depsolving (eg. worst case is if it checked on every > depsolve call). That makes sense. I think maybe we should talk through the various use cases and think about what default behaviors might be best. We can do that later with the team. (In reply to Terry Bowling from comment #7) > (In reply to Brian Lane from comment #6) > > Did you edit the blueprint to set the version to 2.7.7? In the blueprint you > > pasted all the versions are exact, not globs, so the depsolve will fail the > > first time a .z is bumped. > > I did not modify the blueprint, so those are defined by composer. When I > look at some of the other blueprints, such as example-http-server.toml, it > too has some packages defined with exact version rather than globs. > > > > > Restarting lorax-composer should pick up the changes, but if that fails > > cleaning out /var/tmp/composer/* will always make it download new metadata. > > So that's why I'm asking about changing the blueprint. I can't see any way > > for depsolve to fail if the cache has been cleared and the version has been > > changed to either 2.7.7 or 2.* > > Yeah, it never seems to pick up the changes for any of the tests I do. And > it seems to automatically populate the exact versions of packages for any > blueprint I create from the GUI. I've never seen it use the '*' globs. That's probably worth opening a cockpit-composer bug about. You should be able to specify globs, otherwise the blueprints are going to be very hard to maintain when the repos are updated. > > > > > The metadata timeout is currently set to 6 hours, so it is possible for a > > blueprint depsolve to fail if the repo changes. > > > > If you do a compose it will always update the metadata, so if the blueprint > > is correct it will grab the new metadata and depsolve correctly. > > this seems to consistently fail for me, unless I'm missing something. That shouldn't be happening, so it's a bug. Or you are using an older version. I haven't been able to reproduce it here. > > > > > I don't know how to solve this without a big red 'refresh the repo metadata' > > button. If we lower the metadata timeout timer it increases traffic to the > > repos, and slows down depsolving (eg. worst case is if it checked on every > > depsolve call). > > That makes sense. I think maybe we should talk through the various use > cases and think about what default behaviors might be best. We can do that > later with the team. |
Description of problem: Composer fails to depsolve or create images after a local repository mirror is refreshed. Version-Release number of selected component (if applicable): cockpit-composer-0.1.4-1.el7.noarch composer-cli-19.7.27-1.el7.x86_64 lorax-composer-19.7.27-1.el7.x86_64 How reproducible: Current issue is due to ansible 2.7.6 being updated in the repos to 2.7.7. Composes fail, as does depsolving Clearing cache and restarting service does not help. rm -rf /var/tmp/composer/yum/root/var/tmp/composer/cache/* $ composer-cli blueprints depsolve SAP-HANA-Bare-Metal 2019-03-06 14:57:14,679: SAP-HANA-Bare-Metal: The following package(s) had problems: ansible 2.7.6 (No package version matching 2.7.6) blueprint: SAP-HANA-Bare-Metal v0.0.29 I have also reproduced this error in the past by using a custom repo of a package call azurefirstboot which I manually updated the repo. I will attach those to the BZ as an aid in reproducing the issue. Steps to Reproduce: 1. mirror CDN repos using commands: reposync --gpgcheck -ldn --download_path=$PATH --repoid $REPOID --downloadcomps --download-metadata createrepo $PATH/$REPOID -g comps.xml 2. Create a custom repo called azurefirstboot add the version 0.4-1 attached to the BZ 3. Create a test blueprint and add the azurefirstboot package. 4. Create a test image to verify the compose completes (or even starts - does not need to finish) 5. Add version 0.5-4 of the azurefirstboot package to your custom repo and recreate the repo metadata. 6. rm -rf /var/tmp/composer/yum/root/var/tmp/composer/cache/* 7. systemctl restart lorax-composer Actual results: depsolving and image composes fail $ composer-cli blueprints depsolve SAP-HANA-Bare-Metal Expected results: depsolving and image composes succeed Additional info: