Bug 1519536
| Summary: | [Documentation] Running against sat6 "openstack overcloud container image tag discover" results in "docker pull failed: unknown: Not Found". | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Alexander Chuzhoy <sasha> |
| Component: | documentation | Assignee: | Dougal Matthews <dmatthew> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Omri Hochman <ohochman> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 12.0 (Pike) | CC: | dcadzow, dmacpher, emacchi, jschluet, m.andre, mariel, mburns, rhallise, sbaker, slinaber, srevivo, yprokule |
| Target Milestone: | --- | Keywords: | Triaged, ZStream |
| Target Release: | 12.0 (Pike) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
You must manually discover the latest Docker image tags for current container images that are stored in Red Hat Satellite. For more information, see the Red Hat Satellite documentation: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_container_images#managing_container_images_with_docker_tags
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-21 23:38:28 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: | |||
|
Description
Alexander Chuzhoy
2017-11-30 21:05:36 UTC
So it looks like the tag discover has an issue parsing the tag when there is a port :5000 specified. Since 5000 is the standard port I though I could just do this as a workaround: openstack overcloud container image tag discover --image rhos-compute-node-08.lab.eng.rdu2.redhat.com/default_organization-osp12_containers-gnocchi-api:latest --tag-from-label version-release But no! Docker tries to pull this as an x/y image from docker.io We have 2 options here: - fix the tag discover parsing (this will be done anyway, but getting it backported quickly requires Process) - Dan Macpherson investigates if sat6 can have an extra / in the path, so docker's namespace parsing works as expected, eg: default_organization/osp12_containers-gnocchi-api:latest I just had a chat with dbecker, IMO this should not be a blocker and we should document in the sat6 case[1] to skip the discover tag step and to use a specific (versioned) tag. I'm not sure exactly how this temporary workaround docs would be presented, so setting needinfo on Dan Macpherson. [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12-beta/html/director_installation_and_usage/configuring-registry_details#Configuring-Registry_Details-Satellite (In reply to Steve Baker from comment #1) > - Dan Macpherson investigates if sat6 can have an extra / in the path, so > docker's namespace parsing works as expected, eg: > default_organization/osp12_containers-gnocchi-api:latest I think this option is out. AFAIK the container namespace parsing is a Pulp convention and I don't think it can be modified within the Sat6 workflow. (In reply to Steve Baker from comment #2) > I just had a chat with dbecker, IMO this should not be a blocker and we > should document in the sat6 case[1] to skip the discover tag step and to use > a specific (versioned) tag. I'm not sure exactly how this temporary > workaround docs would be presented, so setting needinfo on Dan Macpherson. > > [1] > https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12- > beta/html/director_installation_and_usage/configuring- > registry_details#Configuring-Registry_Details-Satellite Sure, and I don't see this as a major issue either since you can see all the tags usig Sat6. I think we can just recommend users look up the tag in Say 6. Just a note, I've added the hammer command to look up the tag: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12/html/director_installation_and_usage/configuring-registry_details#Configuring-Registry_Details-Satellite See step 9 Doc workaround was applied in the doc text for OSP 12. OSP 12 is now EOL and the change does not apply to OSP 13. Closing the bug. |