Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1599106

Summary: After uploading images to local registry, they're all deleted
Product: Red Hat OpenStack Reporter: David Hill <dhill>
Component: documentationAssignee: 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 Flags
debug.log none

Description David Hill 2018-07-09 00:16:03 UTC
Description of problem:
After uploading images to local registry, they're all deleted

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Hill 2018-07-09 00:17:37 UTC
Created attachment 1457326 [details]
debug.log

Comment 5 Dan Prince 2018-07-09 15:33:06 UTC
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?

Comment 7 Keigo Noha 2018-07-19 06:48:57 UTC
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

Comment 8 Dan Prince 2018-07-20 18:16:29 UTC
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.

Comment 9 Keigo Noha 2018-07-31 01:21:06 UTC
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

Comment 11 Steve Baker 2018-07-31 21:03:06 UTC
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

Comment 12 Dan Macpherson 2018-08-06 23:06:23 UTC
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.

Comment 13 Steve Baker 2018-08-06 23:07:33 UTC
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

Comment 14 David Hill 2018-08-13 12:29:17 UTC
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

Comment 15 Keigo Noha 2018-08-14 01:21:30 UTC
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

Comment 16 Dan Macpherson 2018-08-14 03:36:52 UTC
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.

Comment 17 Steve Baker 2018-08-14 22:10:17 UTC
_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.

Comment 18 Dan Macpherson 2018-08-20 05:20:36 UTC
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?

Comment 19 Steve Baker 2018-08-20 23:16:14 UTC
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.

Comment 20 Dan Macpherson 2018-08-21 05:48:33 UTC
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?

Comment 22 Steve Baker 2018-09-05 22:24:35 UTC
*** Bug 1607925 has been marked as a duplicate of this bug. ***

Comment 23 Dan Macpherson 2018-11-15 11:00:47 UTC
Closing this BZ since the change is live an no additional feedback has been provided.