Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle nil dockerImageManifest and nil dockerImageMetadata in openshift images #13263

Merged
merged 1 commit into from
Jan 10, 2017

Conversation

zeari
Copy link

@zeari zeari commented Dec 20, 2016

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1405937
dockerImageManifest/dockerImageMetadata could be nil when parsing openshift image data.

@enoodle @simon3z Please review
@miq-bot add_label providers/containers, bug

@zeari
Copy link
Author

zeari commented Dec 20, 2016

@cben @zakiva

@zeari
Copy link
Author

zeari commented Dec 20, 2016

@enoodle I couldnt find the description of these fields under openshift, can you point me towards the types.go file that describes these?

@enoodle
Copy link

enoodle commented Dec 20, 2016

@zeari
Copy link
Author

zeari commented Dec 20, 2016

@zeari https://github.com/openshift/origin/blob/master/pkg/image/api/v1/types.go

So both are omitempty and could be nil. 👍

@enoodle
Copy link

enoodle commented Dec 20, 2016

@zeari Also dockerImageReference could be empty. actually all the fields can be empty except dockerImageLayers that we don't use currently anyway.

@@ -176,25 +176,29 @@ def parse_openshift_image(openshift_image)
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dockerImageReference Could also be empty.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enoodle Done

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeari I am sorry but on second thought maybe this is not enough also. without id and ref there is not much meaning to parser_container_image. Maybe we should also try to get the name from the "regular" metadata, which also might be empty.

id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name] || ""

also anyway the field name should start with a lowercase d IIUC

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if id ends up being "", ref ends up being "docker-pullable://",
does parser_container_image which calls parse_image_name all work?

Can you add some unit test where at least some of these things are missing?

Copy link
Member

@chessbyte chessbyte Dec 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not the following:

id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name]
ref = "ContainerImage::DOCKER_PULLABLE_PREFIX#{id}"

or

id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name]
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id.to_s

In other words, make creation of the ref defensive.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what is the meaning of an image without a name... also parse_container_image might return weird results.
Maybe we should find a way to ignore this "image" if that happens?

@@ -176,25 +176,29 @@ def parse_openshift_image(openshift_image)
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeari I am sorry but on second thought maybe this is not enough also. without id and ref there is not much meaning to parser_container_image. Maybe we should also try to get the name from the "regular" metadata, which also might be empty.

id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name] || ""

also anyway the field name should start with a lowercase d IIUC

@cben
Copy link
Contributor

cben commented Dec 20, 2016

BTW if you need live data examples, here is another one from Einat's OSE 3.3:
https://gist.github.com/cben/dcbbebacc4b7c6588ef19ffbd6fb38bd
has dockerImageReference but no dockerImageManifest (and was failing at refresh_parser.rb:179:in `parse_openshift_image')

@zeari zeari changed the title Handle nil dockerManifest and nil dockerImageMetadata in openshift images Handle nil dockerImageManifest and nil dockerImageMetadata in openshift images Dec 20, 2016
@@ -172,29 +172,33 @@ def parse_env_variables(env_variables)
end

def parse_openshift_image(openshift_image)
id = openshift_image[:dockerImageReference]
id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name] || ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeari @enoodle @cben I don't like the last empty string. It doesn't seem to make sense to have an id that can collapse to an empty string for multiple images.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, Maybe we should abort the processing of that image in this case. There is not much meaning to an image without a name.

@zeari
Copy link
Author

zeari commented Dec 22, 2016

@enoodle @simon3z We shouldnt have empty ids, so this version should be ok.

id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name]
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id.to_s
In other words, make creation of the ref defensive.

@chessbyte I went with this option

@simon3z
Copy link
Contributor

simon3z commented Dec 22, 2016

@smarterclayton @deads2k can you confirm that Name in ObjectMeta although it can be empty (omitempty), that's the case only on the client requests (when generateName is used)?

When reading objects from the api-server we'll always get them with a valid (not-empty) Name?

Since all objects are identified by their name in the API I don't expect to be possible to ever retrieve objects with empty/missing names not even for a short time (e.g. generateName generates the name atomically before the object is ever exposed in the list of objects of that Type).

@deads2k
Copy link

deads2k commented Dec 22, 2016

When reading objects from the api-server we'll always get them with a valid (not-empty) Name?

Correct.

Since all objects are identified by their name in the API I don't expect to be possible to ever retrieve objects with empty/missing names not even for a short time (e.g. generateName generates the name atomically before the object is ever exposed in the list of objects of that Type).

Correct. Names are generated before the object is stored, so an API client can never observe an API object without a name.

@simon3z
Copy link
Contributor

simon3z commented Dec 22, 2016

@zeari overall looks good but I think we need to unit-test parse_openshift_image for these cases we're fixing.

:tag => "abcdefg"
})
end

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeari
Copy link
Author

zeari commented Dec 25, 2016

@zeari overall looks good but I think we need to unit-test parse_openshift_image for these cases we're fixing.

Done.

@zeari
Copy link
Author

zeari commented Dec 27, 2016

ping @simon3z is there something missing here?

@simon3z
Copy link
Contributor

simon3z commented Dec 27, 2016

LGTM 👍 cc @chessbyte

@miq-bot assign chessbyte

@chrispy1
Copy link

chrispy1 commented Jan 4, 2017

@miq-bot add_label euwe/yes
@miq-bot add_label blocker

id = openshift_image[:dockerImageReference]
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id
id = openshift_image[:dockerImageReference] || openshift_image[:metadata][:name]
ref = ContainerImage::DOCKER_PULLABLE_PREFIX + id.to_s
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer interpolation over +

Copy link
Member

@chessbyte chessbyte Jan 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. Prefer:

ref = "ContainerImage::DOCKER_PULLABLE_PREFIX#{id}"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, should be:

ref = "#{ContainerImage::DOCKER_PULLABLE_PREFIX}#{id}"

json = JSON.parse(openshift_image[:dockerImageManifest])
new_result[:tag] ||= json["tag"] if json.keys.include?("tag")
if openshift_image[:dockerImageManifest].present?
json = JSON.parse(openshift_image[:dockerImageManifest])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible this could be a "bad" JSON payload? If so, does it need to be handled?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think the json can be malformed but it can be nil (which i check for).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zeari @Fryguy I agree that the JSON payload can hardly be malformed but this part is so critical (not crashing the inventory refresh) that it may deserve some extra care (so that we won't have to deal with this in the future).
In case we can't parse the JSON string we could log an error and continue.

@miq-bot miq-bot assigned chessbyte and unassigned simon3z Jan 5, 2017
@zeari zeari force-pushed the fix_nil_dockerManifest branch 5 times, most recently from de52589 to 077f707 Compare January 10, 2017 11:04
@miq-bot
Copy link
Member

miq-bot commented Jan 10, 2017

Checked commit zeari@077f707 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
2 files checked, 0 offenses detected
Everything looks good. 🍰

@zeari
Copy link
Author

zeari commented Jan 10, 2017

Is it possible this could be a "bad" JSON payload? If so, does it need to be handled?

ping @Fryguy, I added a rescue on that to log an error and then continue without crashing the refresh.

@zeari
Copy link
Author

zeari commented Jan 10, 2017

@gtanzillo @blomquisg Can you guys take a look? 😅

@Fryguy Fryguy merged commit 5ea1153 into ManageIQ:master Jan 10, 2017
@Fryguy Fryguy added this to the Sprint 52 Ending Jan 16, 2017 milestone Jan 10, 2017
@simon3z
Copy link
Contributor

simon3z commented Jan 11, 2017

@chessbyte we need a backport for euwe.

simaishi pushed a commit that referenced this pull request Jan 11, 2017
Handle nil dockerImageManifest and nil dockerImageMetadata in openshift images
(cherry picked from commit 5ea1153)

https://bugzilla.redhat.com/show_bug.cgi?id=1412312
@simaishi
Copy link
Contributor

Euwe backport details:

$ git log -1
commit 9dbe63c21bedd59a75e8eb7cc65fc75da9702bb8
Author: Jason Frey <fryguy9@gmail.com>
Date:   Tue Jan 10 12:24:18 2017 -0500

    Merge pull request #13263 from zeari/fix_nil_dockerManifest
    
    Handle nil dockerImageManifest and nil dockerImageMetadata in openshift images
    (cherry picked from commit 5ea1153a3d20f6332bf7374a1c1ed26b46b04731)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1412312

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants