 Okay, so I'd like to share with the community our efforts in developing redfish interoperability profiles. My name is Rick Giosso and I'm working for Dell Technologies. So I guess to begin I may want to answer the question, what exactly is a redfish interoperability profile? So I borrowed this from a presentation offered by the Distributed Management Task Force, the MTF Redfish Forum, which is cited at the bottom. In summary it offers a common ground for redfish service implementers and so in ironic terms that would be typically folks that are implementing software that runs on a baseboard management controller, BMC. Client software developers, which for us is folks that are working on the drivers that are within ironic and users. In our community that would be typically operators, folks like Arne's organization CERN. So it specifies within the profile, you can specify redfish implementation requirements. And those are requirements that the client software has on the redfish service. However, it's important to note that these profiles are not intended to mandate underlying hardware and software features of a product. It's strictly meant to express what the interoperability requirements are between the client and the service. The third point is that it provides a target for implementers to meet customer requirements. So the profiles can be used by those that are working, for example, BMCs, a target to enable them to deliver what it is that a customer, in our case that would be ironic, needs from the service in order to work with ironic. And then the next thing that does is that it provides baseline expectations for client software developers utilizing redfish. So given a profile that's been tested, the developer who's looking to add a bug fix or new feature functions to a piece of software could have an expectation that with the current profiles, as they exist, that certain aspects of the service have been successfully tested for interoperability. So they can at least then rely on those aspects of redfish to work. Of course, with new feature function, additional requirements might be placed on the service and those will have to be expressed and tried. And then another thing to note, which is, I think, very significant for those that consume ironic, the operators, it enables customers, such as operators, to easily specify redfish functionality and conformance in requests for quotes. So it could be used as part of their acquisition process. And there at the bottom I've cited the presentation that I used to come up with this slide. Next I'd like to briefly discuss ironic's efforts to utilize this redfish interoperability profile tool. We are, as a community, developing profiles for the vendor independent redfish hardware type or driver. It is a Walibi release cycle goal to deliver these profiles. And the primary contacts are Arne, Ricardo Pitao, and myself. And these profiles are designed to offer options to three distinct audiences, operators, ironic upstream developers, and vendors. Let's dive in a little bit to discuss or at least an overview of the ironic redfish interoperability profiles that are being developed. From a high level, we are developing two types of profiles, what I've called consolidated and composed. So a consolidated profile offers a very simple to use profile, which can help answer the question whether or not a BMC can interoperate with all of the vendor independent redfish driver's features. So it's sort of a, in a sense, an easy button. You press the button and it'll tell you can any feature that that driver supports work against this service implementation on this BMC. The next one I've called composed is assembled. It's assembled from multiple profiles, one per driver source code module. Now bear in mind that typically in the ironic code base, each driver source code module, which is located in that drivers modules, and for example, in this case, redfish corresponds to a single or multiple interface implementations of the same sort of category. So for example, power management, BIOS RAID, etc. So this composed profile, which is again assembled from multiple individual profiles, can be used as a pattern to create a custom composed profile that aligns with the interfaces. The operator is using her plans to use. So in other words, an operator may decide, well, you know, I'm going to use this redfish driver and point it at this BMC. But I've decided that I'm only interested in power and management interfaces offered by redfish. I don't have a need for BIOS RAID, you know, etc. So all I want to do is test power and management. And so that can be done by basically leveraging the composed one that will be upstream and modifying it to only be composed from the power and management individual profiles. And that way you don't, the operator doesn't need to spend time testing functionality that they don't plan to use and as well as diagnosing and analyzing prospective issues that that testing might report. So the per source code module profiles support a few things. Composition, which we just discussed, keeping pretty much all the profiles but on an individual source code basis, that profile up to date with production code changes, be they bug fixes or the addition of a new feature function. And then finally, it offers support for back porting profile changes to stable branches. So that would be mostly along the lines of bug fixes. So you could easily follow the code changes and align them with the individual per source code module profile. Finally, I wanted to share with everyone a bunch of references that I think are pretty handy. The first category or first group of them is offered by the distributed management task force, the DNTF. The first one is a presentation that's a few years old, but I think it is a good overview of what these redfish interoperability profiles are about. The second one is a specification for the defines the actual profiles and their syntax, the semantics, the details of the JSON which one needs to write in order to develop a profile. And then the third one is a redfish interop validator tool. So this tool basically takes a profile, you pass it, you tell it the name of the profile and you give it other configuration details like the IP address of the implementation, the service implementation of redfish and it will then go ahead and process that profile against that implementation, that service implementation and report any issues that it finds. So basically it does the interoperability testing and reporting. And then the other category of references that I've shared are from ironic. The first one is the Wallaby release priorities specification that lists this and describes this very briefly as one of the priorities for Wallaby. The second one is the storyboard story that's being used to track this work. And finally there's a proposed Garrett change that's still a work in progress but that's quite mature and that we're looking to land this cycle. So I'd like to, I was told it's to be about five to 10 minutes. So I wanted to allow some time for questions. Does anyone have any questions? Thank you very much Richard. Any questions? When do we expect this to actually be available for, at least, when do we expect it to actually emerge? I guess that's a better question. That's a good question. So we've done certainly a thorough pass of the source code and done some testing downstream against Dell EMC hardware. The proposed changes have been reviewed multiple times by myself and by Mike Renneri who is a co-chair of the Redfish Forum and has responsibility that he shares with Jeff Autor from HPE as another co-chair and he's been providing valuable feedback. There's still some review comments that are being reviewed from our initial downstream effort before we posted it to Garrett to make sure that things have been resolved and addressed. And also there's probably a file or two of the individual module profiles that need to be reviewed more thoroughly, specifically I would say the boot interface profile for virtual media boot since that's a relatively more recent addition and also the sensor support in management. So there's some management interface code review work that needs to be done. So that'll be certainly the focus I'd say over the next month, a month and a half. And in addition to that activity we're hoping for some additional hardware sort of experimentation of the profiles against real hardware. As I said, we've exercised it against Dell EMC iDRAC implementations of Redfish and RNAs graciously tested it against some hardware that he has access to at CERN and I believe he has asked others that they're willing to give it a try as well and that would provide us a few data points as to the quality of the interoperability profiles. So I would say I think it's targeted as a third release goal, right, Julia, in Wallaby. I believe so. So I'd say we should make that and I'm hoping a bit earlier than that. Okay. Excellent. I have a few more questions which I may leave for the discussion after. One comment that I have though is that I guess that like once this is merged that means that any code change that comes into comes to these modules will also also require a similar to I know documentation changes, a change or a check of the profiles and how much they are affected by these changes, right? Yes, that's correct. And exactly, the analogy is very apt, it's sort of like documentation. Mostly for reviews when we get changes in this area, we have to remember similar to, okay, did you update the documentation equality and should be some check and have you updated the profiles accordingly if there's changes in the module? Right. For instance, when they rely on additional functionality from the Redfish endpoint, for instance. Right. So any changes to driver's modules, Redfish, should raise that question, are there any Redfish interoperability profile changes that need to be made? And so that's sort of part of the thinking behind the way we've decomposed this problem into individual profiles, one per source code module is that the developer could then take a look at their, you know, do a code diff, right, between the proposed change and the most recent one and determine pretty quickly whether or not the profile, the existing one already covers that. And if not, okay, well, now I know exactly, you know, what the additional requirements on Redfish are and I need to express those in the profile and add them. And so they would first add them to that individual, let's just say for an example, they're changing, I don't know, management.py in Redfish, they would first modify the management profile. And then, based on the diffs there, they would roll them up into the, what did I call it? The consolidated profile, because that basically the consolidated one is taking all the individual ones and boiling it down into one because there can be some redundancy, you know, across interface implementations in terms of the requirements on Redfish. And so we call them out per interface, but then ultimately just want it to be expressed once in the consolidated profile. Right. Are there any more questions for Richard, if that's not the case? Thank you very much again, Richard. Yeah, I guess I had one more thing to add over through regards to, you know, the code structure and code reviews going forward is that the hope would also be that other drivers would add these in time as well and that they would be able to leverage very heavily these vendor independent files. So basically the way the code has been structured or organized, it very much mirrors the way our driver source code is structured. Cool. Thank you very much. You're welcome. Thank you.