 So, hello, everybody. I think it's time to start. Thank you for coming to this session, which is dedicated to the Redfish standard, which is aimed at it to be a replacement for the IPMI standard. My name is Bruno Kornek. I'm working for UET Packard Enterprise as a distinguished technologist in charge of everything related to open source and Linux. I'm based in Europe, as you can hear from my accent, and I'm French, in fact. That's why. And I'm involved in different projects outside of HP, so feel free to come to me if you want to know more about packaging or Docker containers like I did this morning. To start, I would like to have everybody on the same level with regards to a certain number of definitions. So the first definition is around REST, because Redfish is based on all those definitions. So REST is a way to organize software architecture in a new way for web services using verbs as part of the HTTP protocol, get, post, put, delete, and most of the time also patch and head, a patch being pretty interesting for Redfish. You have all the links to Wikipedia if you want to have more details on what it does. We are also talking about API, so an application programming interface, which means a way, a standard way to discuss between software components between a client and a server, typically, such as what you can find around X-Wendow, around POSIX for the unique systems, or OpenStack, which is based on standard API as well, and create standard APIs for cloud environment. So that's the second term we will use. We will also use a notion of JSON that probably most of you already know, which is a way to sell as data and pass data structure from one software component to another software component, which remains pretty easy for humans to understand. If you compare it with XML, for example, which has much more structure around it, and which is pretty similar to YAML and their equivalence between those languages, as we will see a bit later on. And the last one which may be less known by people is OData, which is a controversial standard, which is used by Redfish. It's an open protocol, which gives you a way to provide metadata, information, and dynamic resources inside your JSON structure. And again, it relies on the same REST APIs that we have seen previously. So with all of that, we can now start to talk about what Redfish is and why it has been created. So Redfish is an industry standard, which is led by the DMTF consortium. It's a working group as part of the DMTF consortium. And the goal is to have a management platform, which is driven by RESTful API, using JSON or XML formats based on the OData CSDL source. So people from the Redfish consortium, they use the CSDL as their real source of development for describing the standard, and they generate equivalent JSON and XML schemas that you can use. And further on now, they are also generating YAML as well. So the goal is really to make a standard way to manage systems, and even more than systems, coming from different manufacturers. Something that the previous tools that have been put on the market have never been able to achieve, SMASH being one of the examples, for example. The goal is really to make something which is much more powerful and easy to use and more standard in what we mean by standard these days, so web-based, than what existed before, typically IPMI. And if you look at the IPMI website today, the IPMI promoter are stating that there won't be any further development around IPMI anymore. And they point to Redfish as a way forward for future management of systems. And IPMI was really difficult to deal with and was something which was highly unportable between manufacturers. So really the goal of Redfish is to solve all of those problems, bringing something which is based on existing standard way of communication between client and server. So RESTful API using JSON, using OData, using HTTPS as a way to communicate between client and server, which makes it more secure. It's HTTP based on IP, so you can route it, you can do whatever you want, in fact, because it has a protocol. It goes also further than just the system management. It aims also at being an IT management protocol. So right now, the first four years have been focusing around systems themselves, but now they're extending to storage, to chassis, to data center infrastructure, think power, thermal conditions, et cetera. One of the things of the nice and not nice thing about the standard is that it provides, like SNMP, a NoEM area. So for manufacturer, if there is, there are some aspects of the management which are not yet standardized, meaning not all manufacturers agree on the way to describe that feature or not all manufacturers have that feature part of the hardware, so they're not interested in having it as part of the standard, then you can have a NoEM area in the JSON structure where you store your features, the specific features, or not yet standardized features, and you can develop your own tools to use those extensions. Of course, this is a bit of a deviation with regards to having a standard, but that's a nice way for manufacturer to adopt that standard because it does not prevent them to extend it and do what they want with proprietary tools if they don't want to have an open source tool. And the goal is to help with automation of system management. So the standard has been published the first time in 2015. The working group was created in 2014. You have on the DMTF website, so dmtf.org, standard, Redfish, you have everything that they are publishing, and it has increased a lot these last years around so the schemas themselves describing what you can do, how you can address resources as part of the management browsing, documentation, white paper, fax, and what is really interesting are the mock-ups, and I will show that to you later on. They provide simulation of management boards, BMCs, so that you can have a look past them following the links inside the management stream, and you have a very good idea of what you can do with the Redfish interface. Currently, it's available by a certain number of manufacturers, so Dell, HPE, being the promoter of the standard, they have been pretty active on supporting Redfish since day one, but you also find it on super micro BMCs, inside software, Lenovo, and probably a couple of others as well. I have not ticked everybody, but there are quite a lot of people now interested and even outside of the pure server areas, there are more and more hardware components that start thinking about adding Redfish support. This gives you an idea of the companies behind the Redfish standard and trying to promote it, and you also have a certain number of other efforts which are in relationship with Redfish, typically the guy working around the open compute project, so the OCP platform, the GenZ consortium, which creates a standard interconnect between systems at large, it could be racks, et cetera. The DCEIM, but it's not mentioned here, which is around the data center infrastructure. So what do you want to do with Redfish? You want to do what you were doing with IPMI first, and one of the goals of the standard body right now is to now that they have stabilized the standard at a certain level of features, they really want to tackle what remains not covered, that people are using around the IPMI, and be sure that Redfish provides a similar feature. So of course, you want to be able to gather information about the health of your server, temperature, all the sensors inside the machine, fans information, inventory information, part numbers, UIDs, all those type of stuff, you want to be able to get them and have a good view on the topology of your machine with regard to CPUs, memory, extensions, disks, NICs, et cetera, et cetera. They are even working on the notion of profiles, interoperability profiles, which means that as a customer, you can define a Redfish profile, and you can assess that the machine you are buying complies to the Redfish profile that you are describing, which means that you say, okay, I want the server to always have two CPUs, to have a number of NICs, to have that type of component inside, you can enforce that through profile, and the DMTF publishes tools to help you assess that the physical server you are buying is in agreement with the profile you have decided to create. So you can get information, you can also perform actions. So think about get and post or put operations through the REST API. You can have actions on the power, so you can reboot the system, reboot into whatever mode you want, change the boot order of the system. You can have actions on the thresholds, run power, run fans, stuff like that. There are new notions of events and alerts that have been put in place more recently in the stack. And moreover, on top of that, you can also manage the server infrastructure. So of course, you can manage the BMC itself, information at the BMC levels, its network settings, and the accounts, user accounts are linked to a directory server on which you will manage the authorization, authentication, so that people can log on it. But also we are going up in the stack, so having inventory at chassis level, so if you have a blade infrastructure, if you have for us moonshot type of chassis with a lot of small computers inside the loud box, then you have inventories of those stuff. And as I was saying, there are extensions working on the SNIA around SWATFISH, which is concerning everything related to storage up to very high level, high end level of storage systems. And DCIM, which deals with the facility management, with the data center management, and provides a new notion of sensor, which will be the key resource that you can address inside the Redfish schema to be able to control a full infrastructure in fact. So there is a standard itself, and people are developing a certain number of tools around it, open source tools, mostly some non-open source tools as well, to be able to interact with Redfish based systems. So again, the DMTF has made quite a very good job as publishing a lot of tools on their website and on GitHub through their GitHub entry. Typically you have all the bindings that you need for a value set of languages. You have CLI tools to be able to interact with Redfish based BMCs. You have simulators of BMCs, of Redfish compliant BMCs. You have validation tools as well that allow you to assess that Redfish developed BMC software is compliant with the standard. And again, the markup are also pretty important on the development side. And on the community side, you have a certain number of projects that have been developed to add features in relationship with existing tools. So typically the OpenStack ironic bare metal system as part of the OpenStack. So the possibility to deploy bare metal nodes to be used inside a cloud infrastructure is using the Sushi library that has been developed for OpenStack to interact directly with Redfish based BMCs in that context. You have a Redfish module for Ansible, which again helps you dialogue with the BMC using the Redfish protocol. Similarly, OpenSushi guys are developing the same module for salt. And you have Redfish support inside the OpenBMC project. So if you are more on the NoCP type of platform, you can use the OpenBMC stack inside your architecture to manage your management board. And you can have Redfish support as part of this OpenBMC implementation, even have an Azure's plug-in for it as well. And the two Python, the Python libraries or multiple Python libraries, and I'm responsible of one of those. Well, I'm responsible, culprit. So you have a data model which represents all the resources you can deal with at the Redfish level, but I don't want to pass too much time here. I prefer to do that live on the website. So here you have the Redfish.DMDF.org website and they behave like a BMC. So they have a slash Redfish slash V1 and 3-point, which is the root of the tree of resources that you can manage. And then they are providing multiple types of mock-ups, a single rack, an OCP profile, a Bled system, Bled partitions, which are systems like the HP Superdom system. So you can physically create multiple computers inside a single box. So isolated, electrically, and stuff like that. Don't care. And the Composable system as well. So you have many, many examples. The one I will explore is just a simple rack because that's something that everybody should know. It's a rack server. You put in a rack to CPUs and stuff like that. And so you have the interface here and you have links that have been created for each entry point so that you can start to explore the system. And you have entry points which are mandatory. I argued yesterday, well, two days ago during the Redfish workshop, we had here that the system is mandatory for me from what I read in the spec. But the expert told me it's not mandatory, so now I don't know anymore. But you should find some stable entry points. But the one, in fact, the principle of parsing the Redfish tree is that you should not expect something to be called something. You should parse it, you should explore the stuff, find the entry, find the members of the collections, and do your job after having found all the information on the system. So generally on a system, you will find systems as an entry point chassis and managers. The rest is potentially found or potentially not found depending on the implementation by your hardware vendor. Of course, systems is here, a rack-mounted server, so you just have one system. So the members of that entry system is just one entry which has a name which is 437X something. It depends. You don't, you shouldn't rely on the name which is presented here. It could be one. A lot of manufacturers do that with numbers. So if you have a blade chassis, you have one, two, three, four, which corresponds to blade one, two, three, four. But you may have a serial number, you may have something else. So again, you need to explore, find the number to be able to go deeper in the tree. So you start to find some information about your systems such as serial number, part number, description, UIDs, etc., etc. And quite a lot of information, boot information, boot possibilities, current boot mode, trusting modules if you have a TPM inside your machine. And you see you may have some OEM entry points here, which makes specific entries for that manufacturer. Bios version is generally always there. It's part of the standard. Memory summary, bios. And then you have, again, some further entry points. For example, you may want to have more information about the internet interfaces of your system. And then you go down and you have two nicks inside your machine. You can have a look at one, and you can find, for example, the MAC address of your nicks. So that's one way to populate automatically a deployment server, DHCP servers with the nicks, the IP you want, etc., etc. So that's an idea of how this is organized. And you have the same stuff at the manager level. So for example, the resource of network interface is the same for the BMC. A BMC is as potentially a serial console, a shell access, a firmware version, which is, of course, different from the bios version. But you also have an Ethernet interface. And you may want to go there. There is only one. Generally, there is only one internet interface for BMC. And you have the MAC address of this time, the BMC, which is here. So that was to give you an idea of how you can do just through the web interface. You can browse the REST API, and you can start having a good idea of what you can do and can't do with a Red Fish protocol. And of course, it's very easy, starting from that, to do that programmatically if you want. Recent new features and changes as part of the standard. So there are numberings that tend to publish three times per year. This year, maybe, they will have a fourth release because there are quite a lot of additions. Additions may be important or less important, depending on the versions. There is no real good ground level for that. So last year, they added the support for LDAP, Active Directory configuration for the BMC providers. They added something which is probably very interesting, which will become more interesting as time passes and the resource developed is a telemetry service to be able to collect information through metrics, typically for your power, your fans, in an easy way. So to avoid you to poll on a regular base, the BMC to get the information, which can be pretty costly. The telemetry service is doing the job for you, and you can ask for a report, and you can with one API request get a full set of a time-based report of measurements of values associated to the metric you asked for. And last year, also, they added the open API support, which allows them to have now the YAML support at parity and generate it completely automatically from the specification. Oops, sorry. They added certificate management as well. They worked on the notion of sensor for extension to the data center. They introduced a notion of host interface. So this is a possibility for your BMC to be seen by your operating system if it's configured to be seen by the operating system. And so it allows you, for example, to do rest queries from the operating system to the Redfish interface available through that virtual network interface. That's pretty interesting. And they're working, so 2019.2 should be officially announced next week or the week after. And the main improvement is around software updates, so each time they also review documentation, they fix bugs, they clarify some stuff in the standard. I don't explain that in details here. And they're working for the next version on, so next or later, because we don't know exactly when it will be adopted, but there are discussions in the Redfish forum around the possibility to send events through SMTP protocol to configure managed devices as an SNMP, even if they don't want to pursue the SNMP path and would prefer people to adopt Redfish, but there are certain cases where SNMP is mandatory. Possibility also to configure secure boot, et cetera. Let's talk about the rest. So another simulator which exists is the one we are doing at HP to simulate our platform. So the one by the DMTF are really generic ones. There is no real hardware behind it. It's completely a fact system which is proposed to you, a potential working one, but it's still with fake value. Here you have emulation possible of different HPE servers, and so you can take a two CPU, a four CPU, and a data center optimized one or a generic one, and you can do exactly the same. So you can pass all the level, but for example you see that, so we have an OEM entry which is developed, but you see that we have, for example, the telemetry service which is not part yet of the mockup of the DMTF because we are a bit in advance for the implementation. So I said there is the OEM part where hardware manufacturer can add their own improvement, but also it's sandbox for us to test new features, waiting for them to be adopted and part of the standard. And that's what happened most of the time is that something which is in the OEM to start with and up being as part of the standard. So the telemetry service is already for us ready because we started to have it as part of our OEM branch and now it's really part of the standard. So you have the possibility to, so we are interacting with an ILO, a real ILO system, our BMC board, and you can look at the various potential reports that you can do on CPU, on memory, et cetera, et cetera. So you have another simulator which is more like a real server on which you can make your tries with your software tools to be sure that your software development is working correctly. Some additional examples around the, around Redfish. So for example, for the security, here is what you would do to have the secure boot configuration of your system. So you do get on that URL. So system slash one again is something which will work on an HP server. It may not work on another manufacturer's server. You need to find how it's named. And we have seen the trusted module during the passing. Secure boot, for example, set up is now part of the standard as well as TPM and physical security. And they were removed on our side in our implementation from the OEM part. So originally it was there. And as everybody has that feature, most of the manufacturers have that feature. Now it's really part of the standard. What else? So typically here we have some security features which are still in our area for us. We have, for example, a fifth profile configuration that we can apply. That's not something the industry has agreed upon. So it's spending more adoption. The virtual nick I was mentioning is also something we have developed originally and that we have pushed as a standard. And it's something which can work without any specific driver. So for Linux it's an inbox, a USB EEM network driver. If you load that driver, you will enable your operating system, your Linux distribution to talk to the Redfish, to the BMC, the network, the virtual network of the BMC, which will appear on your system as an additional network interface. And then you will be able to make Redfish queries directly here. Yes, question? Yes. Yes, exactly. Except that you don't need, well, it's a bit different. It's just an interface that you are making, you make appear on the system which was not there before. So it's up to you. Either you deny the driver and the system will never see the BMC, which for some security environments is needed, or you want the facility and then you can activate it. It also depends how you do the management of your machine. Do you have a specific network, an out of map network that you want to use, or do you want to use the in-band network of the system to also do the management? So it's really, it allows you to give you the flexibility to choose where you are gathering the management information. It's available as part of the standard. So every manufacturer who has the feature embedded in their firmware will make an entry point available for you. So you can detect it. Sorry, I didn't get it. So it's part of our, so on HP hardware, I can more talk about that. It's already available as part of the ILO 5 Firmware 140. So it's linked to the firmware evolution because all those all those Redfish calls and the evolution of the standard, we participate to it. And then there are people developing our firmware for our BMC that are adding the features to the firmware and make it available. But as part of Firmware version, so for ILO 5 Firmware version 140 for ILO 4, I don't know. It's available right now. So you can use it. Okay, so Open API is pretty interesting because it allows you to describe the service in a YAML format and you can have an automatic way. So this is the former swagger for those of you who know swagger, maybe more. So you have an easy way. Once you have your Redfish schema described as a YAML Open API compatible format to generate software out of it. There are tools to create a web server compliant with a schema. So you can fully create your own BMC software if you want. Once you have created your YAML format and the YAML format here is generated for us by the DMTF tools. That's something which has been added in 1.6.0 of the standard. And so CSDL files are still the OData CSDL files are still what the DMTF use as the source code I would say for this for the implementation of the standard. And they generate YAML, they generate JSON, they generate XML schemas from those files in a querent way. So we worked on a couple of years ago, so in 2015, there was no real Python library available to help you or the one which was there was really ready mental and so the DMTF at that time had not released it under an open source license. So as we wanted to use it, we started to develop our own to be able to interact with our RedFish systems and add that for some demos we were doing, et cetera, and become a small easy to use tool for us, which provides a certain number of features. It requires quite a lot of Python dependency, so if you want something light, you may use Sushi from OpenStack. If you want something more structured and a bit richer, you may want to use that one and contribute to it. So we have a client tool, we have a library, we have an asset tool which gives you inventory asset numbers for a system, for example, and it has been tested across a large range of physical machines, one I have access to being more HP based, so HPE based, and it's available for different type of environments. So what is important is that the DMTF is looking for feedback, especially for people who are using IPMI and manager infrastructure with IPMI, what would prevent you from using RedFish instead of IPMI to manage your environment? So they are really keen to receive feedback from customers having that type of setup. Use RedFish, use a forum for that or to ask whatever questions you want on top of what has been discussed today. There is a feedback portal, you can submit bug reports if there is something that you feature announcement or an issue you find with the standard. It's available as well online. So really, this year they want to focus more on the end customers and they estimate that the end customer should drive the future effort around RedFish because the base is really strong today, so what we need is what you need. So what tools are missing today? What would make your life easier for integrating that standard protocol inside your environment? And what prevents you from transitioning from legacy tools that you are using right now? Again, a lot of tools are available on the DMTF website to make tests, to grab bindings, et cetera, so feel free to do that. And also, I started a wiki page on the RedFish specification, but as you have heard, I'm not a native English speaker, so I'm not either a native English writer, so you may want to help me and improve the wiki page as well by adding more stuff on it. And last point for me is we are organizing RedFish workshops. The one in San Diego is already done. It was on the 20th. You can find on that URL all the presentations that have been made, which go in much more detail than what I've been able to do in 32 minutes today. We have also workshop, which is planned in Europe for the European people. The 31st of October in Lyon, my own country. And we have made, we are making submissions for LinuxCon for Australia and Suzakan so that we are covering more people potentially. And as you have been very brave to come to that very far away room, there are some t-shirts on the first row, which is medium, large, XL, and two XL. Feel free to grab a t-shirt before leaving the room and wear it. With that, if you have any additional questions, you have two minutes for that, and it should answer very rapidly.