 Alright guys, looks like we'll have a nice and small crowd, so if you're all coming forward, we don't have to make giant amounts of noise. Yeah, so last talk for today, without further ado. Enjoy. I said a little background, I'm assuming most people here. A fun language and a controller, typically a system on a chip that's in a machine. It allows you to interact with a server without any operating system running on there, or do things like par-off, par-on, get information from the system, outside of the operating system. Being able to do things like get the inventory permission. Yep. Alright, start over. Hopefully the slides so far were pretty self-explanatory. So that's the background. That piece, Redfish is the thing that maybe some people might not be as familiar with. Redfish is a protocol that is by the DMTF that supersedes things like IPMI and SMASH and SNMP to be able to interact with things like a base board management controller, using something a little more modern and a little more intuitive than some of those past protocols. So it's a REST API, JSON formatted data that gets sent back and forth. It also is defined in a way so that it's not necessarily just capable of talking to an individual host. It's an API that can be used by a higher level management tool. So if you have an application that is managing, say, your entire data center, and is already doing things with the devices in your data center, that can actually expose a Redfish interface, and then you're able to interact using that same API that you would directly to a host with that application. So it's flexible enough to handle that where it's either a single device or a whole collection of devices. Sortfish is from the Storage Networking Industry Association, and that was done really closely with the DMTF Redfish team. It really just builds on top. It's layered on top of the Redfish protocol, adding things for managing storage. And that can be typically an external storage device, so a SAN device could expose a Sortfish API. There are some basic storage management for Redfish itself, for managing an individual server with the internal hard drives. But for anything other than just a really basic internal drive configuration, the vision at least is that then Sortfish takes over, and then that gives you all of the advanced functionality for configuring storage. It might help to take a look at the actual object model. Like I said, this is all rest, so it's a little easier to read than something like SMIS protocol specification. So everything is off this Redfish v1 root. So to do anything with either Redfish or Sortfish, you need to get that service root. And then from there, you can navigate to all of these other things, all of the devices. So for example, there's a collection of systems, and then you can get an individual system, and through that, that gets you the processors within that system, or the memory, or in a physical chassis, you can find out the power information, thermal information, things like that. Sortfish, like I said, is built right on top, so there's still that Redfish v1 service root. But then it adds additional information through this storage services collection. So there can be multiple different storage services, and then through that, you can see the drives, the enclosures, storage pools, things like that. It's actually, I should point out it's, on the bottom here, I have file systems. The protocol itself for storage is meant for both, well, for block file and object storage. Focussofar has been on block storage. I think there's barudimentary file system support. Object is planned in there, kind of some placeholders, but it's a protocol that's still evolving. So if anyone is interested in that, that's a place you can help out. So GoFish is a library that it really just makes it easier to consume these protocols from a Go application. It can talk to both Redfish and Swordfish services, and those services can give you a wide variety of server hardware types, a variety of storage devices. You don't need to care as much necessarily if it's a DelSever, Lenovo, or HP. You just talk Redfish, and it's a standard interface for all of them. So the goal with the library is that it hides a lot of the internal details. You shouldn't necessarily need to be an expert in the Redfish specification to be able to use this library and interact with a Redfish-enabled device. It does expose that basic object model, so you kind of need to understand that. But through the linkage and everything being off of that service route, even if you don't even take a look at the specification, you can kind of figure out, based on the names and what they link to, where to go and find some things. And it attempts to hide implementation details. There's not too much of that yet, so there's just kind of a forward goal with it. As the specification evolves, new properties might be added, some things might be taken away. It's one of the goals with the library is that it'll hide that from you, so you don't necessarily need to know in your application the first thing that you do isn't to query what version it is and then have a whole bunch of conditional logic to, okay, this version I got to do this, this version I got to do that. It'll just take care of whatever it can as much as possible, where you can still have that consistent interface and not need to worry as much if something got moved around. So to show an example of what this looks like, this is some really basic go code. You need to import the GoFish library. And it is broken out into different namespaces for redfish and swordfish. There's some common data structures that they share, but to try to keep things separate in there, there's a little overlap between names. There's redfish and swordfish namespace, depending what you need to access. In this example, I'm going to connect to the client. Before I can do that, I need to define this client config structure. And this is where, unless it's a very simple thing like there, they have a simulator that there's no authentication. You just connect to it. You can even use your web browser. In most cases, you'll need to give it username, password, tell it where to connect. Insecure is, I think, unfortunately, is a very common option that you'll have to set that to true unless you actually go through the effort of setting up certificates and all that. Otherwise, it will enforce that there's a known certificate when it does an HTTPS connection and fail if you don't have everything in place. Especially internally, if you're using this within your data center, it's good to have security, but probably okay to set that insecure to true. And that'll just ignore any kind of certificate as long as it can establish the connection that works. So you pass that config into the connect call that gives you an instance of the client. And by that point, you should be authenticated if there's any authentication negotiation that needs to happen between. Like I said, everything is off the service route, so that's one common piece. It's pretty much always you establish, you get the client, and then from the client, you get the service route, and then from there things start to change depending on what you're trying to do. You query the systems, and like I said, most cases if you're just talking to an individual server, that's just going to give you a collection of one. But if you have an application that exposes the Redfish API, that's managing multiple devices, this is going to give you that collection of every system that your application knows about. So that aside, another little setup piece. This is an example. I'm going to reboot a server. If you have some control, you can override some of the boot settings when you do this. So I'm going to tell it the target, change the target to Pixie Boot. So if it was booting off its internal drive, I can set here next time you reboot, do a Pixie Boot. And the override, I can set to once. So this isn't going to make a permanent change in my BIOS, and every time I reboot, it's something different is going to happen. If I just need to boot up my machines, pull down an image, I can do that just one time. Then all I can do here is I loop through that collection of systems. So loop through the one instance if I'm talking to a server. It sets that, set boot call, sets those options, and then just call reset. And here I'm telling it Force Restart. So there's different options. You can tell it to try to gracefully shut down the host OS. In this case, I'm just telling it, basically like cut the power, reboot the machine. So that's a basic overview of the library. There's a lot of detail in there. I didn't want to go too into all the object model of Redfish and Swordfish. Those specs are linked to off of the, this talks page if you want to take a look there. They have a fairly decent online viewer if you're looking for something specific. It's not too hard to look through there if you're trying to find a certain property that you need to pull in for whatever. So I just wanted to show an example of where this is already being used. I know of people using this to write their own little tooling internally to interact with their devices in their data center. Someone's writing a Prometheus integration to be able to use this to pull in your hardware information into Prometheus, which helps with get those metrics. This one is kind of interesting to me. The BMC Lib is an existing library that's been out there before this, and it right now has to have that implementation where there's a separate, whole separate module for, this is how I talk to Adele, a whole separate module to how I talk to HPE. And they're starting in a development branch, so this isn't mainline stuff, but they're starting to see where they can start to replace that with using GoFish and just using this common Redfish protocol to do that interface rather than needing to write all of these device specific codes. So they would like to make it where you just plug in a server, you don't need to know which type it is, it's plug and play, be able to provision things, get things boot up. Ideally, be able to have all the programmatic interface in here so that they don't need to do any manual intervention. So that's part of an overall BMC toolbox. BMC Lib is the one piece in there that does that abstraction currently so that they can do all these fancy things and all of that conditional logic for what they're talking to is in BMC Lib. So they have all of these different tools in BMC toolbox. I'm not an expert on here, so I'm not going to try to explain all of them, but they all in some way interact with the hardware device through BMC Lib. So they're able to get the information out, collect inventory, make configuration changes and everything through BMC Lib. Like I said, right now they have all these specific integrations for different device types, and they're slowly able to migrate that away. Most modern devices from all these manufacturers and others now do have a Redfish interface, and they can stop doing these vendor-specific things for everything. So the ongoing effort with that, they all have their own protocol, but they are getting more support. They are getting up-to-date. There are still, if you do try this out and see anything strange, you may need to apply an update like older versions of Dell iDRAC supported early on protocol version of Redfish. So, like I mentioned, going forward, you should hopefully not have to care what version of the Redfish specification they support. I didn't really want to go all the way back to these old, old versions, so if you run into anything, check how old your firmware is. It may need to be updated. And the idea for BMC Lib to adopt this is it's easier to use one protocol and work is being done there. So try it out. I'd love to hear more feedback. I've been able to test a few different things. The BMC Lib project has been able to test a few different servers, so we found little things here and there, but for the most part, I think the library is pretty usable, but I'd love to hear more. Success and failure. So try it out. If you do see anything, just file an issue on GitHub, and hopefully we can get to that soon. And of course, contributions are always welcome if you see anything and want to enhance something, make it easier to use, have any other ideas, definitely welcome any participation. So maybe this doesn't read on the black. It isn't great in this room, but Git repo is the top link there. This will be linked in the presentation as well. So that's where you can get the code, file any issues, throw up any pull requests. If you would like to find out more about the Redfish protocol, redfish.dmtf.org, and SNEAV has a longer URL there. I'm not going to read off. And if you're interested in that BMC Toolbox, there are some really useful tools in there. Check them out if you want to get involved in that project. I think the same thing. They'd welcome any contribution, but it's also interesting to see what types of things they're doing using some of these basic ideas of how to interact with the BMC and manage hardware below the operating system. Any use of this? If you start using it, I'd love to hear about it. Tweet me. Can contact me directly through Twitter or through GitHub issues and whatever works best for you. But I'd love to hear about anything that works, doesn't work, any kind of feedback. So any questions? I'll straightforward. I'm sorry, what was that? So the question is if there's an environment that you can test changes, if all you have is your laptop, that most likely does not have a BMC in it. Yeah, there is a simulator that the Redfish team from DMTF provides. It's just a Python application. By default, download it, run it. It'll give you a basic setup. If you want to test a specific scenario of type of hardware configuration, it is configurable. So there's not a tool to configure it, but they have instructions in there about how you can configure the simulator to report different types of configurations, different hardware. It's just adding a few files. Yeah, good question. Yes, does it work for... Open BMC. That's actually something I'd like to know. I haven't been able to test yet. I would assume if Open BMC exposes a Redfish interface, it should work. It shouldn't be any reason why not. It's just not something I've tested yet myself. So when you're testing, being able to download basically the responses or the data from the Redfish server, that was actually a nice thing that someone added. They put up a pull request. There's a configuration in that client config where you can tell it to dump all of the responses it gets. So then you can look at the raw JSON data that comes back, and that is useful to see if something's not working quite right, trying to tell what the library expects and then what data you're actually getting back. A lot of them will actually do work well, too, if you just point a browser at this Redfish slash v1. Most browsers will be able to do a challenge authentication, and then once you're authenticated, you can really follow through. You just have to put in the URL for some of the associations that are in there. Oh yeah. Yeah, so you could use this... Yeah, you could use this to write a tool that if your client, whoever you're providing support for, has this issue and you can't access the system, that it could just go out and pull down all kinds of information, dump it into text files, and then there you've got everything, hopefully, that you need. Yeah, all right. Well, yeah, thank you, everyone.