Usage of Chassis resource with ChassisType Row and Rack

fish
Guppy

Posts: 65

Usage of Chassis resource with ChassisType Row and Rack May 22, 2019 11:28:33 GMT

Quote

Post by fish on May 22, 2019 11:28:33 GMT

Hi,

Chassis can be of ChassisType Row and Rack. These ChassisTypes should be useful for describing the structure/arrangement of ComputerSystem equipment by using the Chassis ContainedBy and Contains properties with links to other Chassis resources.

Assume that a Manager (of ManagerType Service) is managing multiple ComputerSystems (with associated Chassis) that is arranged in Rows of multiple Racks. The Manager should expose a Redfish REST API including the correspond Chassis hierarchy. It is unlikely that this Manager or any hardware in this setup can automatically detect the existence of Racks and how they are arranged in Rows, at least by using any legacy hardware for servers and racks. So Chassis resources for Racks and Rows cannot be automatically created by the Manager (“system created”). And the Manager will likely also not be able to automatically populate the ContainedBy and Contains properties of Chassis for same reason. This means that Chassis for rack and rows would likely need to be added by end-user /client, e.g. doing POST/create operation towards the ChassisCollection resource. But ChassisCollection schemas has "Insertable" Bool="false" (and "Deletable" Bool="false" on Chassis), which should mean that POST/create on this collection and DELETE of Chassis is not allowed. So how could the Chassis of type Row and Rack be used in this scenario, if client/end-user is never allowed to create such Chassis? And Redfish schema modification rules does not allow to add operations to schemas, only to remove them (chapter 11.4 in 1.7.0). I guess one option is to abandon Redfish schema for Chassis and define own OEM schema for “OemChassis” but I would rather use the standard one in this case. Opinions?

Would Redfish consider to change to "Insertable" = “true” (on the Collection) and "Deletable" ="true" on Chassis?

I see a potential problem that the clients should preferably not be able to delete “system created” Chassis resources (automatically created and exposed by the Manager / Redfish service,) such as Chassis of type Sled or Rackmount. But this issue could probably be resolved by some new property “SystemCreated (boolean)” that is False for end-user created Chassis (such as for Raw, Rack), and not allowing DELETE of the SystemCreated Chassis instances. This would also be easy to add as Oem property in the Chassis for implementations that needed it. Other implementations could choose to have conventions that only Chassis with specific ChassisType can be deleted.

Other problem would be that ContainedBy and Contains in Chassis properties are readOnly. But I think updating of these could possibly be handled via (Oem) actions, if it would not be enough to set this at POST/create of the Chassis. (Even if providing full Link/URI to other resource is a little tricky. ) Any opinions on how to handle possible update (“PATCH”) of ContainedBy and Contains after Chassis was created?

BR /Magnus

j2hilland
Administrator

Posts: 29

Usage of Chassis resource with ChassisType Row and Rack May 22, 2019 19:41:29 GMT

Quote

Post by j2hilland on May 22, 2019 19:41:29 GMT

I think the problem with changing these collections to allow Insert/Delete is a question of use case. We allow insert when you are truly creating. For example, a ComputerSystem is composed from existing resources by POSTing to the ComputerSystemCollection (based on the capabilities object). What we wouldn't want is secondary actions such as adding a chassis and a computer system automatically shows up. Besides, it sounds to me like you're wanting to use the Manger (for the Row/Rack)'s Northbound Interface to add stuff (which is really what would happen via the Southbound interface, like through Redfish or a provider/plug-in/some).

What I read in your description is that you are aggregating other resources and are really looking to force discovery (either automatically go find resources because you know you added them or to manually add them based on something like an Address). So what you are telling your service is to go perform this discovery on this Address and then your Manager (bad name, so I'm going to start calling it an Aggregation Service) is going to go discover what resources can be added based on what is found at that Address. So you want to use the NorthBound interface to tell it to use it's SouthBound interface to find/proxy the Rows/Racks of equipment.

To me, this is more appropriately modeled as a Service with a Discovery action. Perhaps it is time for Redfish to document how Aggregation works and it seems that an Aggregation Service with some kind of action to force discovery through the Southbound interface would be an appropriate addition to Redfish.

fish
Guppy

Posts: 65

Usage of Chassis resource with ChassisType Row and Rack May 23, 2019 14:41:47 GMT

Quote

Post by fish on May 23, 2019 14:41:47 GMT

Thanks for you answer! See my comments inline below.

May 22, 2019 19:41:29 GMT j2hilland said:

I think the problem with changing these collections to allow Insert/Delete is a question of use case. We allow insert when you are truly creating. For example, a ComputerSystem is composed from existing resources by POSTing to the ComputerSystemCollection (based on the capabilities object). What we wouldn't want is secondary actions such as adding a chassis and a computer system automatically shows up. Besides, it sounds to me like you're wanting to use the Manger (for the Row/Rack)'s Northbound Interface to add stuff (which is really what would happen via the Southbound interface, like through Redfish or a provider/plug-in/some).

Comment: Im not proposing that you would do POST/create operation to create Chassis with ChassisType Sled or RackMount. And certainly not also get an associated ComputerSystem instance created as side-affect. This should typically not be supported by any Redifish service. ComputerSystem and associated Chassis will typically be automatically discovered and automatically exposed in the Redfish API by the Redfish service. (These will be the "system created" chassis instances.) Im only proposing that schemas for Chassis and ChassisCollection should be relaxed by allowing Insert/Delete of Chassis via operations POST/create and DELETE, which would typically be used for ChassisType Rack or Row, for reasons mentioned. (These would be the "manually created" chassis instances.)

What I read in your description is that you are aggregating other resources and are really looking to force discovery (either automatically go find resources because you know you added them or to manually add them based on something like an Address). So what you are telling your service is to go perform this discovery on this Address and then your Manager (bad name, so I'm going to start calling it an Aggregation Service) is going to go discover what resources can be added based on what is found at that Address. So you want to use the NorthBound interface to tell it to use it's SouthBound interface to find/proxy the Rows/Racks of equipment.

Comment: Yes you are right in that this use case could be seen as an "aggregation service". But it should not be regarded as some kind of (automatic) "discovery scenario", or even manually triggered discovery. This is what I tried to explain in my initial post when I described that this aggregation service cannot automatically detect (discover) existence of Rows and Racks, because lower layer system (southbound systems) cannot detect these kind Row and Rack entities. I would guess that it is the normal case scenario that such systems does not have hardware or SW or sensors to detect e.g. how legacy servers are arranged in racks, and how these are arranged in rows in e.g. a data center. This is main reason why modelling of Row and Rack Chassis in the Aggregation service ("manager") would have to be accomplished by the northbound client/user of the Aggregation service Redfish API, by adding Chassis instances for Rows and Racks "manually" ( via POST/create operation towards the ChassisCollection).

To me, this is more appropriately modeled as a Service with a Discovery action. Perhaps it is time for Redfish to document how Aggregation works and it seems that an Aggregation Service with some kind of action to force discovery through the Southbound interface would be an appropriate addition to Redfish.

Comment: As stated above I dont think this kind of discovery action to force discovery through southbound interfaces would solve the use case I describe. Reason is the southbound systems are not able to discover/detect rows and racks and their relations in this scenario. And also in a hypothetical scenario where southbound systems would actually be able to do this kind of discovery/detection I would prefer that the discovery is automatic rather than manually triggered by some action. Generally I think that e.g. the Chassis resource is already suitable for describing aggregation of systems in an Aggregation Service , by supporting the containment hierarchy via ContainedBy and Contains properties.

j2hilland
Administrator

Posts: 29

Usage of Chassis resource with ChassisType Row and Rack May 23, 2019 19:03:02 GMT

Quote

Post by j2hilland on May 23, 2019 19:03:02 GMT

But you are proposing a POST of a Chassis - and ChassisType has no required semantics. So this approach is problematic (to allow some to work and others not when there are no real restrictions (no shalls) on the use of ChassisType). And the Contains and ContainedBy objects are currently Read only. When you combine the things you want to do with permissions, it also doesn't follow Redfish (permission is applicable across the whole collection, not on specific members). I believe it is more problematic than you describe and there are many corner cases.

We designed Redfish so that a NorthBound interface would not directly manipulate the Chassis objects. Instead, the implementation could do it on it's behalf via a service (which isn't currently modeled). I could see the need to model that service. I would think the aggregation service would be able to provide the chassis and handle the relationships.

The architectural issue to me is - do you allow a Client to directly manipulate the collection (which is so far largely read only) or do you have the Client tell the Service to manipulate the collection. When you start thinking about accounts/permissions and having them on a resource or collection basis, the later becomes more consistent with Redfish modeling.

Your approach could also result in a lack of interoperability between aggregators. Some would allow this, others would auto discover. But customers could use the interface to provide groupings that other aggregators couldn't support. So it could be abused to provide logical groupings. The right answer is to provide a method of groupings for bulk operations through Redfish, which we have not yet attempted to model in Redfish beyond ResourceBlocks (which is a different use case). An aggregation service could probably be the enableming resource for this functionality as well.

I understand from one perspective it may seem like a simple solution to your problem, but for the industry as a whole it is something that either would not work or would not be enough. And it would lead to a lack of interoperability. I still think the right way is to model an aggregation service (thus permissions would be easier) that would perform operations such as this.

fish Guppy Posts: 65	Usage of Chassis resource with ChassisType Row and Rack May 24, 2019 7:45:11 GMT Quote Select Post Deselect Post Link to Post Back to Top Post by fish on May 24, 2019 7:45:11 GMT OK, thanks for your input! Will consider the different options further.

Usage of Chassis resource with ChassisType Row and Rack

Post by fish on May 22, 2019 11:28:33 GMT

Post by j2hilland on May 22, 2019 19:41:29 GMT

Post by fish on May 23, 2019 14:41:47 GMT

Post by j2hilland on May 23, 2019 19:03:02 GMT

Post by fish on May 24, 2019 7:45:11 GMT