Bug 1599106
| Summary: | After uploading images to local registry, they're all deleted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | David Hill <dhill> | ||||
| Component: | documentation | Assignee: | Dan Macpherson <dmacpher> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 13.0 (Queens) | CC: | cchen, dhill, dmacpher, dprince, knoha, m.andre, mburns, sbaker, srevivo | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-11-15 11:00:47 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: | |||||||
| Attachments: |
|
||||||
|
Description
David Hill
2018-07-09 00:16:03 UTC
Created attachment 1457326 [details]
debug.log
I think this behavior can be controlled with the options described in this commit: http://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=15bf0f588c10094585f867927e3508eb155e7cac Perhaps we need to better document the new behavior? Hello Dan, It looks like that a user who wants to use local registry cannot use local registry by this issue. Is it correct? If yes, the documented procedure in our installation guide is not usable for the customer who has a requirement of using a local registry. Best Regards, Keigo Noha Hi Keigo, We still support the use case you are asking about. Sounds like we were missing a patch to expose a flag that would allow you to preserve existing images on the Undercloud registry when new ones are uploaded. Will try to sync with sbaker next week on status here. Hello Dan, Do you have any updates on this? Currently, the supported method for local registry is not usable. Could you proceed this bugzilla forward for including the patch in Z2 errata? Best Regards, Keigo Noha David, can you confirm that this is an issue for you because you are relying on the output of "docker images" to confirm that they are in the local undercloud registry? Can you please see the comment on this bug[1] then elaborate on why this behaviour is a problem for you? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1607925#c1 Discussed this with Steve. We'll make this a docs bug because some explanation content on the difference between the local docker instance and the docker registry would help clarify what's happening. Thanks, it will need to explain the difference between "docker images" output and images actually on the undercloud registry. Suggest to call "skopeo inspect" when they want to confirm an image exists on the undercloud registry Hey, I was using "docker images" as this used to work since we started using containers but if "skopeo inspect" does the same, we no longer need this BZ. Thanks, Dave Hello Dan, We should describe what user can confirm with "docker images" or "skopeo inspect" and difference between them precisely for avoiding the confusion in user side. Could you add the sentence into our document? Best Regards, Keigo Noha So two things: 1. The "skopeo inspect" command is useful for checking is an image is available on the undercloud. However, I'm not sure you can get a full list using skopeo alone. Steve, can you confirm if this is the case? If not, the fallback we can document is: curl http://[undercloud ip]:8787/v2/_catalog | jq . That will return a list of images on the undercloud's docker registry. 2. I don't think we should close this BZ yet. From what I've seen, there's still a lot of confusion about the images existing on docker engine vs the docker registry. People seem to conflate the two, which is why there's a bit of confusion. I still think we should include some conceptual info to distinguish the two. _catalog doesn't return tags, so it will show that an image exists, but it doesn't really verify that the exact tag they are about to deploy is actually in the registry, maybe longer term the prepare command needs a --verify option so they can run a separate command which confirms that every image reference exists in the registry. But I do think we need something for 2 which explains the local registry vs local docker storage. With regards to 1, what about a hybrid approach? We could tell users to view the list of containers with the curl/jq command, then to view tags for a container use skopeo? Just discussed this in person, +1 on a hybrid approach, plus an extra bit explaining about the difference between local docker storage and undercloud registry storage. For 1, I've rewritten the description for the local registry method: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/configuring-a-container-image-source#registry-methods I've also added the following note: "The docker-distribution service acts separately from docker. docker is used to pull and push images to the docker-distribution registry and does not serve the images to the overcloud. The overcloud pulls the images from the docker-distribution registry." I've added commands to list the images and their tags using our hybrid approach to the local registry procedure: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/configuring-a-container-image-source#Configuring-Registry_Details-Local @sbaker, how does this all look? *** Bug 1607925 has been marked as a duplicate of this bug. *** Closing this BZ since the change is live an no additional feedback has been provided. |