A few questions | Redfish Specification Forum

javadude
Minnow

Posts: 1

A few questions Feb 13, 2017 23:19:56 GMT

Quote

Post by javadude on Feb 13, 2017 23:19:56 GMT

I'm primarily a Java backend web developer working for a hardware company, and I've been assigned a task to create a mockup/example of how any arbitrary Redfish implementation could get device information from our SSD drives using one of our CLI tools. Basically I would create a REST service that calls our CLI tool, takes the drive information the CLI tool returns, and then create the applicable JSON response which matches the Redfish schema as closely as possible but not strictly implementing the full standard, since it's just an example. The main goal is to just show others how they could use our CLI tool to get drive info if they were implementing Redfish and wanted to support our drives.

I'm not used to reading huge specifications like this, and while I understand the big picture, I don't quite understand how it all fits together and would like some clarification.

Who creates implementations of Redfish? My guess is server companies, like HP, Dell, etc.?
If server company X uses SSDs from company Y in their systems, or any type of device for that matter, how do they typically get the device info expected in the Redfish schema. Are Redfish implementations calling all sorts of random programs to get info from different devices? Or is it all lower level driver calls?
I imagine the correct schema for this scenario would be the Drive schema, correct?

Thanks for any input. Sorry if these are dumb questions.

mraineri
Administrator

Posts: 1,138

A few questions Feb 16, 2017 19:50:18 GMT

Quote

Post by mraineri on Feb 16, 2017 19:50:18 GMT

Yes, you're correct in that a Redfish implementation would be owned and maintained by the appropriate system vendor.

In terms of how a Redfish implementation gets the drive info, it depends on the system architecture. There are various hardware protocols (both standard and proprietary) that are used within a given system to allow management controllers to collect information from different devices. Depending on the overall design and the type of layering involved, you could have a Redfish implementation working with other Redfish implementations for aggregating that information.

Drive is one of the schemas to work with. Prior to the release of the Drive schema, there was a lightweight SimpleStorage schema that was defined before a more complete storage definition was established.

cprabhudesai
Minnow

Posts: 18

A few questions Dec 8, 2018 16:20:47 GMT

Quote

Post by cprabhudesai on Dec 8, 2018 16:20:47 GMT

Hello,

I want to create a RESTful Redfish compliant service for a device where I work. (Python and Flask)
I write a little about my understanding about the whole service and then towards the end, are a few questions.

DISCLAIMER: I am new to creating a backend service, this is my first time doing it.
Not aware if some things are obvious for everyone, so please forgive and/or
point me to the right direction.

I have briefly used Redfish services from a client perspective for Rack-mounted Servers so I understand some of the
resources mentioned under the specification.

However, I do not understand the use of schemas, for both the client as well as the vendor that's providing the service.
Going through the schemas I do understand that they define what the client should ask for; and for those requests,
what a service might respond with. As a client, I used the service to get information from very few resources,
I didn't necessarily had to deal with these schemas.

But now, as I have to implement one, I think schemas play a big part in designing a service.
How the really common ResourceCollections (Managers, Systems, Chassis etc.) and Services (SessionService, AccountService, etc.)
are mandatory, and there are other ResourceCollections and Resources that a vendor might use as per their discretion.

Q1: There are schemas for various resources under the Redfish Specification, does a vendor have to include them all?
For example, my system is not a Blade Server, do I still have to use that Resource as a part of my Redfish
implementation? Or I can pick and choose, which resources I need and then for those resources, I provide information
for each property?

Q2: Do I have to use the schemas JUST AS A REFERENCE for creating this service?

To better understand the Service, I used Redfish-Mockup-Creator on the Rack-mounter Server I talked about
earlier. This created a recursive directory under redfish/ with index.json for each REST endpoint that the Mockup-Creator hit.

I then used Redfish-Profile-Simulator to host a Python-Flask based server pointing to the directory
I obtained earlier. I was able to get the Resource information from each REST endpoint. This was the index.json content

Q3: How do I create a Redfish Service? Do I maintain a similar recursive folder structure for each Resource I implement?

I read the entire document - Redfish API Specification

Nowhere is it mentioned how a schema is tied to a resource apart from using it as a guideline when creating a Service.

Q4: If It is done that way, and I decide to add some OEM properties or Resources, I would have to maintain my source-code
and the schema separately. I guess my concern was If there's a way to dynamically create a schema from a resource or
the other way around.

Thank you for reading through. Any help is appreciated.

Best,
Chinmay

Last Edit: Dec 8, 2018 17:11:13 GMT by cprabhudesai

jautor
Administrator

Posts: 519

A few questions Dec 14, 2018 20:53:47 GMT cprabhudesai likes this

Quote

Post by jautor on Dec 14, 2018 20:53:47 GMT

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Hello,

I have briefly used Redfish services from a client perspective for Rack-mounted Servers so I understand some of the
resources mentioned under the specification.

However, I do not understand the use of schemas, for both the client as well as the vendor that's providing the service.
Going through the schemas I do understand that they define what the client should ask for; and for those requests,
what a service might respond with. As a client, I used the service to get information from very few resources,
I didn't necessarily had to deal with these schemas.

Correct. The schemas define the properties that may appear in each resource (URI) - so that both the Service knows what to implement, and what a client can expect to be in the JSON response. It's essentially a specification for each data structure. We designed Redfish so that the properties and resource layout are mostly obvious - that for many cases, you can figure out what they all mean without ever looking at the schema.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

But now, as I have to implement one, I think schemas play a big part in designing a service.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

How the really common ResourceCollections (Managers, Systems, Chassis etc.) and Services (SessionService, AccountService, etc.)
are mandatory, and there are other ResourceCollections and Resources that a vendor might use as per their discretion.

Q1: There are schemas for various resources under the Redfish Specification, does a vendor have to include them all?
For example, my system is not a Blade Server, do I still have to use that Resource as a part of my Redfish
implementation? Or I can pick and choose, which resources I need and then for those resources, I provide information
for each property?

No, very few things are actually required to be there. Obviously you need the SessionService so that users can create a session, and you need the ServiceRoot so they can find other resources and/or figure out what the Service is supporting.

Before we go any further, let me point you to the Redfish Resource and Schema Guide, which is a document that converts the "human and machine readable" schema files into something that is really human-readable. That document has example payloads for most resource types, and puts all the important data about each property into tables.

The document gets updated every time we do a schema bundle release (three times a year), and can be downloaded from the Redfish Standards Page under the document "DSP2046".

Here's a direct link for the 2018.2 version, which is the most recently published:

www.dmtf.org/sites/default/files/standards/documents/DSP2046_2018.2_0.pdf

In that guide you'll see some properties marked as "required". That means that if that resource is implemented, then those properties MUST be implemented as well. But you only implement the resources that make sense for your product. You should NOT implement anything your product doesn't support - you just leave those things out.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q2: Do I have to use the schemas JUST AS A REFERENCE for creating this service?

To better understand the Service, I used Redfish-Mockup-Creator on the Rack-mounter Server I talked about
earlier. This created a recursive directory under redfish/ with index.json for each REST endpoint that the Mockup-Creator hit.

I then used Redfish-Profile-Simulator to host a Python-Flask based server pointing to the directory
I obtained earlier. I was able to get the Resource information from each REST endpoint. This was the index.json content

There are tools that can use the schema files (especially the OpenAPI conforming .yaml files) to create code for you based on the schemas that you might find useful. But no, otherwise, the schema files themselves are just for your reference to ensure your implementation meets the specification.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q3: How do I create a Redfish Service? Do I maintain a similar recursive folder structure for each Resource I implement?

I read the entire document - Redfish API Specification

Nowhere is it mentioned how a schema is tied to a resource apart from using it as a guideline when creating a Service.

It's just like any other web server or service - you have a resource (URI) tree that gets populated by various routines that understand that resource.

The schemas are tied to a resource in two ways (starting with Redfish v1.6.0). First, each resource tells you which schema it implements - this is the required "@odata.type" property. Second, the URIs for each resource are now defined for each schema. So the URI \redfish\v1\Chassis will return a ChassisCollection (if the service implements one).

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q4: If It is done that way, and I decide to add some OEM properties or Resources, I would have to maintain my source-code
and the schema separately. I guess my concern was If there's a way to dynamically create a schema from a resource or
the other way around.

Thank you for reading through. Any help is appreciated.

Best,
Chinmay

If you create OEM resources or properties you'll want to create schema files to describe them, so that anyone building applications can use those schema files in the same way they would the standard Redfish-defined ones. And yes, those are separate from your source code. As I said above, there are tools that can convert schema files (OpenAPI tools being the most popular of the three schema languages we support, although there are JSON schema tools available as well) into data structures or code blocks to help you get started. What is left is for your code to populate the values for each of the properties - no one else can do that for you...

Hope that helps,

Jeff

cprabhudesai
Minnow

Posts: 18

A few questions Dec 17, 2018 18:18:56 GMT

Quote

Post by cprabhudesai on Dec 17, 2018 18:18:56 GMT

Dec 14, 2018 20:53:47 GMT jautor said:

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Hello,

I have briefly used Redfish services from a client perspective for Rack-mounted Servers so I understand some of the
resources mentioned under the specification.

However, I do not understand the use of schemas, for both the client as well as the vendor that's providing the service.
Going through the schemas I do understand that they define what the client should ask for; and for those requests,
what a service might respond with. As a client, I used the service to get information from very few resources,
I didn't necessarily had to deal with these schemas.

Correct. The schemas define the properties that may appear in each resource (URI) - so that both the Service knows what to implement, and what a client can expect to be in the JSON response. It's essentially a specification for each data structure. We designed Redfish so that the properties and resource layout are mostly obvious - that for many cases, you can figure out what they all mean without ever looking at the schema.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

But now, as I have to implement one, I think schemas play a big part in designing a service.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

How the really common ResourceCollections (Managers, Systems, Chassis etc.) and Services (SessionService, AccountService, etc.)
are mandatory, and there are other ResourceCollections and Resources that a vendor might use as per their discretion.

Q1: There are schemas for various resources under the Redfish Specification, does a vendor have to include them all?
For example, my system is not a Blade Server, do I still have to use that Resource as a part of my Redfish
implementation? Or I can pick and choose, which resources I need and then for those resources, I provide information
for each property?

No, very few things are actually required to be there. Obviously you need the SessionService so that users can create a session, and you need the ServiceRoot so they can find other resources and/or figure out what the Service is supporting.

Before we go any further, let me point you to the Redfish Resource and Schema Guide, which is a document that converts the "human and machine readable" schema files into something that is really human-readable. That document has example payloads for most resource types, and puts all the important data about each property into tables.

The document gets updated every time we do a schema bundle release (three times a year), and can be downloaded from the Redfish Standards Page under the document "DSP2046".

Here's a direct link for the 2018.2 version, which is the most recently published:

www.dmtf.org/sites/default/files/standards/documents/DSP2046_2018.2_0.pdf

In that guide you'll see some properties marked as "required". That means that if that resource is implemented, then those properties MUST be implemented as well. But you only implement the resources that make sense for your product. You should NOT implement anything your product doesn't support - you just leave those things out.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q2: Do I have to use the schemas JUST AS A REFERENCE for creating this service?

To better understand the Service, I used Redfish-Mockup-Creator on the Rack-mounter Server I talked about
earlier. This created a recursive directory under redfish/ with index.json for each REST endpoint that the Mockup-Creator hit.

I then used Redfish-Profile-Simulator to host a Python-Flask based server pointing to the directory
I obtained earlier. I was able to get the Resource information from each REST endpoint. This was the index.json content

There are tools that can use the schema files (especially the OpenAPI conforming .yaml files) to create code for you based on the schemas that you might find useful. But no, otherwise, the schema files themselves are just for your reference to ensure your implementation meets the specification.

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q3: How do I create a Redfish Service? Do I maintain a similar recursive folder structure for each Resource I implement?

I read the entire document - Redfish API Specification

Nowhere is it mentioned how a schema is tied to a resource apart from using it as a guideline when creating a Service.

It's just like any other web server or service - you have a resource (URI) tree that gets populated by various routines that understand that resource.

The schemas are tied to a resource in two ways (starting with Redfish v1.6.0). First, each resource tells you which schema it implements - this is the required "@odata.type" property. Second, the URIs for each resource are now defined for each schema. So the URI \redfish\v1\Chassis will return a ChassisCollection (if the service implements one).

Dec 8, 2018 16:20:47 GMT cprabhudesai said:

Q4: If It is done that way, and I decide to add some OEM properties or Resources, I would have to maintain my source-code
and the schema separately. I guess my concern was If there's a way to dynamically create a schema from a resource or
the other way around.

Thank you for reading through. Any help is appreciated.

Best,
Chinmay

If you create OEM resources or properties you'll want to create schema files to describe them, so that anyone building applications can use those schema files in the same way they would the standard Redfish-defined ones. And yes, those are separate from your source code. As I said above, there are tools that can convert schema files (OpenAPI tools being the most popular of the three schema languages we support, although there are JSON schema tools available as well) into data structures or code blocks to help you get started. What is left is for your code to populate the values for each of the properties - no one else can do that for you...

Hope that helps,

Jeff

Hello Jeff,

Thank you for giving such a detailed response!
It is clear to me now, and I understand what needs to be done around this brilliant specification!

The documentation is really fantastic and leaves no room for any ambiguity!

As to the last remark, I understand that no one else can return values for me, my question was more in the direction of - if there's a way to generate these code blocks so that I get a jump start and I don't have to re-invent the wheel!

Cheers to you, and the team for all the hard work for this specification!

Best,
Chinmay