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

Links in LogEntryCollection are not followed and checked #519

Open
jiaqingz-intel opened this issue Oct 17, 2022 · 7 comments
Open

Links in LogEntryCollection are not followed and checked #519

jiaqingz-intel opened this issue Oct 17, 2022 · 7 comments

Comments

@jiaqingz-intel
Copy link

jiaqingz-intel commented Oct 17, 2022

Version: 2.2.1

Validator only checks the LogEntry in the response payload of LogEntryCollection, the LogEntry resourced linked at @odata.id is not checked. (Response time is 0 and HTTP status is -1)

image

When the LogEntry resources at @odata.id is incorrect, as validator skips them, no error reported.

image

@tomasg2012
Copy link
Contributor

tomasg2012 commented Oct 17, 2022

Am I mistaken? The log is clearly showing a different payload. How is this happening in practice? I am confused.

Edit: Oh, nevermind. It is likely because the validator is not checking the DIRECT call to that odata.id, it is checking it from within the collection without GETting it from the service from it's URI twice (Note the 0ms response time).

I believe there's code in place for some URIs checked but not unique URIs like this. This is an assumption from the tool, and needs to be reported correctly.

@jiaqingz-intel
Copy link
Author

Edit: Oh, nevermind. It is likely because the validator is not checking the DIRECT call to that odata.id, it is checking it from within the collection without GETting it from the service from it's URI twice (Note the 0ms response time).

Oh I see, in other LogEntryCollection, it also does not follow the link.

image

I believe there's code in place for some URIs checked but not unique URIs like this. This is an assumption from the tool, and needs to be reported correctly.

I think only not following the links with # is the correct behavior, like this

image

Anyway I'm going to update the issue.

@jiaqingz-intel jiaqingz-intel changed the title When returing {ResourceCollection} as {Resoure}, validator shows pass Links in LogEntryCollection are not followed Oct 18, 2022
@jiaqingz-intel jiaqingz-intel changed the title Links in LogEntryCollection are not followed Links in LogEntryCollection are not followed and checked Oct 18, 2022
bradbishop pushed a commit to openbmc/bmcweb that referenced this issue Dec 7, 2022
Currently getting single PostCode entry returns a LogEntryCollection
with the specified LogEntry in its Members. Since Redfish Service
Validator does not follow the links in LogServiceCollection[1], such
unexpected behavior passes the validator. This commit makes it return
the LogEntry itself (or 404 Not Found) when requesting it.

Fixes Github issue #236 (#236)

[1] DMTF/Redfish-Service-Validator#519

Tested:
* Confirmed getting a valid PostCode entry now returns a LogEntry, and
  getting invalid entries like B0-1, B1-0, B1-999 or 123 (Not properly-
  formatted ID) responds with 404 Not Found.
* Get PostCode log entries collection still returns LogEntryCollection
  containing first 1000 PostCode entries by default.
* Redfish Service Validator passed.

Change-Id: Ice6b8742caea96ad3d436d57898202fe7362b150
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@intel.com>
@blakehilliard
Copy link

I am also seeing this error. In validateURITree() of validateResource.py, it goes down the path if link.Type is not None and link.Type.AutoExpand because AutoExpand is set to true for LogEntry in the tool. And so it assumes the the collection it already got was auto-expanded, even though it did not request it to be expanded. So then it processes just the odata.id object in Members as if it were the full LogEntry resource and complains that it is missing every field except odata.id.

@mraineri
Copy link
Contributor

mraineri commented Apr 8, 2023

The collection is supposed to be expanded even if not requested; if LogEntryCollection does not show the contents of the LogEntry resources in the Members array, it's nonconformant.

@mraineri
Copy link
Contributor

mraineri commented Apr 8, 2023

@blakehilliard to be clear, are you saying the collection is auto expanded and the case is it's treating it like it's not? Do you have a sample of what you're running exactly from the command line?

@blakehilliard
Copy link

Thanks, I was unaware a collection could have thiis auto-expansion requirement.

@mraineri
Copy link
Contributor

To date, we only have that requirement on the LogEntryCollection (with the OData.AutoExpand term specified on the Members NavigationProperty). In theory it could be applied elsewhere, but there hasn't been a need to force expansion like with logs. The service validator dynamically looks for the OData.AutoExpand term to determine whether or not it should expect the expansion in the response (and validates accordingly).

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

No branches or pull requests

4 participants