Move installing opm binaries to iib-worker Dockerfile#1300
Move installing opm binaries to iib-worker Dockerfile#1300lipoja merged 1 commit intorelease-engineering:mainfrom
Conversation
Reviewer's GuideIntroduce a central iib_ocp_opm_mapping in the main Config, adjust the development config to rely on base formatting, and change failure cleanup behavior in general tasks to reset Docker configuration instead of running the broader build cleanup, in preparation for moving binaries into the iib image (with additional changes in the workers Dockerfile). Sequence diagram for updated failed_request_callback error handlingsequenceDiagram
participant CeleryWorker
participant failed_request_callback
participant reset_docker_config
participant set_request_state
CeleryWorker ->> failed_request_callback: on_task_failure(request, exc, task_id, args, kwargs, einfo)
alt exc is IIBError
failed_request_callback ->> failed_request_callback: msg = str(exc)
else exc is FinalStateOverwriteError
failed_request_callback ->> failed_request_callback: log.info("Request is in final state")
failed_request_callback ->> reset_docker_config: reset_docker_config()
failed_request_callback -->> CeleryWorker: return
else exc is other Exception
failed_request_callback ->> failed_request_callback: msg = "An unknown error occurred. See logs for details"
failed_request_callback ->> failed_request_callback: log.error(msg, exc_info=exc)
end
failed_request_callback ->> reset_docker_config: reset_docker_config()
failed_request_callback ->> set_request_state: set_request_state(request_id, failed, msg)
set_request_state -->> failed_request_callback: state updated
failed_request_callback -->> CeleryWorker: return
Class diagram for updated Config and DevelopmentConfigclassDiagram
class Config {
+Dict~str, Tuple~int, int~~ iib_binary_ranges
+Dict~str, str~ iib_ocp_opm_mapping
+str iib_opm_pprof_lock_required_min_version
+str iib_image_push_template
}
class DevelopmentConfig {
+str iib_registry
+Optional~str~ iib_request_logs_dir
+Optional~str~ iib_request_related_bundles_dir
+Optional~str~ iib_request_recursive_related_bundles_dir
+str iib_dogpile_backend
+dict iib_ocp_opm_mapping
}
DevelopmentConfig --|> Config
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Review Summary by QodoMove binaries to IIB worker Dockerfile with verification
WalkthroughsDescription• Move OPM binaries to worker Dockerfile with SHA256 verification • Add OCP-OPM version mapping as default configuration • Replace _cleanup() with reset_docker_config() in containerized IIB • Install multiple OPM versions and operator-sdk with checksums Diagramflowchart LR
A["Dockerfile-workers"] -->|"Install OPM variants<br/>with SHA256 checks"| B["Multiple OPM versions<br/>in /usr/local/bin"]
C["config.py"] -->|"Add default mapping"| D["iib_ocp_opm_mapping<br/>configuration"]
E["general.py"] -->|"Replace cleanup call"| F["reset_docker_config<br/>for containerized IIB"]
B --> G["Default OPM symlink"]
File Changes1. docker/Dockerfile-workers
|
Code Review by Qodo
1. Dockerfile command chaining bug
|
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Now that
Configdefines a globaliib_ocp_opm_mapping, consider whether the override inDevelopmentConfigis still needed or if it should be removed/updated to avoid diverging mappings and confusion about the single source of truth. - Replacing
_cleanup()withreset_docker_config()infailed_request_callbacknarrows the cleanup behavior; if_cleanup()previously handled additional teardown beyond Docker config, consider whether that logic still needs to be invoked on failure in some way.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Now that `Config` defines a global `iib_ocp_opm_mapping`, consider whether the override in `DevelopmentConfig` is still needed or if it should be removed/updated to avoid diverging mappings and confusion about the single source of truth.
- Replacing `_cleanup()` with `reset_docker_config()` in `failed_request_callback` narrows the cleanup behavior; if `_cleanup()` previously handled additional teardown beyond Docker config, consider whether that logic still needs to be invoked on failure in some way.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
051ff0a to
3955ecc
Compare
3955ecc to
4aac09e
Compare
2fe48e9 to
3ecfee6
Compare
3ecfee6 to
74ec520
Compare
… default in config.py Assisted-by: Cursor/ChatGPT [CLOUDDST-31191]
74ec520 to
afddd4f
Compare
|
LGTM |
Summary by Sourcery
Update worker configuration and failure handling for OPM version mapping and Docker cleanup behavior.
New Features:
Enhancements: