Bug 1413045 - podfying cfme image: in customer portal downloaded image Labels is none
Summary: podfying cfme image: in customer portal downloaded image Labels is none
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: cfme-container
Version: 5.7.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: GA
: cfme-future
Assignee: Barak
QA Contact: Einat Pacifici
Red Hat CloudForms Documentation
URL:
Whiteboard: container
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-13 13:13 UTC by Dafna Ron
Modified: 2017-02-07 04:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-26 18:54:43 UTC
Category: ---
Cloudforms Team: Container Management
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dafna Ron 2017-01-13 13:13:52 UTC
Description of problem:

when downloading the image from the portal it shows the label is none. 

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

5.7 GA

How reproducible:

100%

Steps to Reproduce:
1. oc import-image my-cloudforms/cfme4
--from=registry.access.redhat.com/cloudforms/cfme4 --confirm --all
2. 
3.

Actual results:

images appear with label: none

Expected results:

I think we should add a label. 

Additional info:


[root@smicro-628-b11 templates]# oc import-image my-cloudforms/cfme4 --from=registry.access.redhat.com/cloudforms/cfme4 --confirm
The import completed successfully.

Name:			cfme4
Created:		Less than a second ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-01-13T12:04:29Z
Docker Pull Spec:	172.30.176.72:5000/dafna/cfme4

Tag	Spec						Created			PullSpec								Image
latest	registry.access.redhat.com/cloudforms/cfme4	Less than a second ago	registry.access.redhat.com/cloudforms/cfme4@sha256:85c2b23b3389b5...	<same>

[root@smicro-628-b11 templates]# oc import-image my-cloudforms/cfme4 --from=registry.access.redhat.com/cloudforms/cfme4 --confirm --all
The import completed successfully.

Name:			cfme4
Created:		17 seconds ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-01-13T12:04:46Z
Docker Pull Spec:	172.30.176.72:5000/dafna/cfme4

Tag		Spec							Created			PullSpec								Image
latest		registry.access.redhat.com/cloudforms/cfme4		17 seconds ago		registry.access.redhat.com/cloudforms/cfme4@sha256:85c2b23b3389b5...	<same>
5.7		registry.access.redhat.com/cloudforms/cfme4:5.7		Less than a second ago	registry.access.redhat.com/cloudforms/cfme4@sha256:e5df7ce368f67f...	<same>
5.6		registry.access.redhat.com/cloudforms/cfme4:5.6		Less than a second ago	registry.access.redhat.com/cloudforms/cfme4@sha256:0fe89411e7a1a2...	<same>
5.6.0.13-1	registry.access.redhat.com/cloudforms/cfme4:5.6.0.13-1	Less than a second ago	registry.access.redhat.com/cloudforms/cfme4@sha256:7ee6c7ab7bbee4...	<same>
5.6.0.13-2	registry.access.redhat.com/cloudforms/cfme4:5.6.0.13-2	Less than a second ago	registry.access.redhat.com/cloudforms/cfme4@sha256:52f1aed84e9808...	<same>


info: The remote repository contained 5 additional tags which were not imported: 5.6.1.2-2, 5.6.2.1-1, 5.6.2.2-1, 5.6.3.3-2, 5.7.0.17-1
[root@smicro-628-b11 templates]#

Comment 1 Barak 2017-01-17 17:21:14 UTC
Why do you think this is a Cloudforms/CM related bug?

Comment 2 Dafna Ron 2017-01-18 11:25:47 UTC
I don't

Comment 3 Barak 2017-01-22 16:56:43 UTC
Isn't it related to the IS label limitation (IIRC default = 5) ?

If you do it after setting the "maxImagesBulkImportedPerRepository: 100" (or higher) in the /etc/origin/master/master-config.yaml , and restarting the atomic-openshift-master service. 

Does it still show the same label ?

Comment 4 Dafna Ron 2017-01-23 09:58:13 UTC
  maxImagesBulkImportedPerRepository: "-1"

[root@dafna-openshift-master01 ~]#  oc import-image my-cloudforms/cfme4 --from=registry.access.redhat.com/cloudforms/cfme4 --confirm --all
The import completed successfully.

Name:			cfme4
Namespace:		cloud09
Created:		14 seconds ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-01-23T09:56:22Z
Docker Pull Spec:	172.30.192.79:5000/cloud09/cfme4
Unique Images:		10
Tags:			10

Comment 5 Barak 2017-01-23 10:31:31 UTC
Satoe,

Please keep in mind this is the monolithic image.

Do we need to label it differently on build time ?

Comment 6 Franco Bladilo 2017-01-23 13:36:37 UTC
Barak, 

We have been setting OpenShift labels on the monolithic image for a while : 

https://github.com/ManageIQ/manageiq/blob/master/Dockerfile#L182

Which labels missing are we referring to?

Thanks,

Comment 7 Satoe Imaishi 2017-01-23 13:56:52 UTC
I'm not sure which label this is referring either... Dafna, what's the expected value?

Comment 8 Dafna Ron 2017-01-23 14:07:38 UTC
I suggest refereeing this question to the PM :) 
I just think that getting a "none" value is not something we would like for an image downloaded from redhat.

Comment 9 Franco Bladilo 2017-01-23 14:22:32 UTC
Barak, Dafna,

I don't think this is a bug.

The labels that Dafna is referring to, are the labels on the IS object itself, not the images which are actually labeled.

When you create an IS object without a deployment template via oc-import like in this example, labels for the IS are not populated.

When we deploy the IS using a template (such as the one for the podified release), then these labels get injected into all objects created via template, see here : 

https://github.com/ManageIQ/manageiq-pods/blob/master/templates/miq-template.yaml#L3

An alternative would be to add the labels by hand, once the IS object is created, this can be done by using "oc edit is".

Another alternative is to use oc new-app --docker-image= , etc.. to deploy the monolithic build and have OpenShift create all objects and in that case it will apply labels to all objects created.

Thanks,

Comment 10 Dafna Ron 2017-01-23 14:29:16 UTC
please note the documentation comment:
 https://access.redhat.com/containers/#/repo/57ea8ce49c624c035f96f370/image/openshift

"That command results in the latest version of the image being pulled to the local system. By adding the --all flag to that command line, you would import all tags for the image and not just the latest tag." 

perhaps documentation need to be changed.

Comment 11 Satoe Imaishi 2017-01-25 14:54:44 UTC
I don't think the documentation is 'wrong' as that's talking about image tags, not IS labels.

Barak, assigning this to you as this has nothing to do with the actual image, and I'm not sure how we want to handle this ticket..

Comment 12 Barak 2017-01-26 18:54:43 UTC
Per the discussion above and comments #9 #10 & #11,
Moving this to CLOSED NOTABUG


Note You need to log in before you can comment on or make changes to this bug.