Storage Developer Conference - #53: Introduction and Overview of Redfish

Episode Date: July 31, 2017

Hello, everybody. Mark Carlson here, SNEA Technical Council Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the developer community. Each episode is hand-selected by the SNEA Technical Council from the presentations at our annual Storage Developer Conference. The link to the slides is available in the show notes at snea.org slash podcast. You are listening to SDC Podcast Episode 53. Today we hear from Patrick Boyd, Principal Systems Management Engineer from Dell, as he presents Introduction and Overview of Redfish from the 2016 Storage Developer Conference. My name is Patrick Boyd. I'm with Dell Technologies, I suppose now.

And I'm here to give you an introduction and overview of Redfish. Last year at this conference, a colleague of mine from the DMTF, Jeff Hillen, from HPE, you know came up and talked about this thing called Redfish that was in development. Probably included how it was going to cure cancer, solve world hunger, but I haven't quite gotten around to those things yet. But I am here to show you what it does do today and kind of how it does it. So no further ado, I'm going to kind of give you a little bit of a view of who is developing this thing, what is it, give you some very simple examples, talk about why we chose the technology we chose to do this. I'm going to give you some slightly more complex examples, go over

how you actually use this thing, discover what resources you have on it and then actually you know even show you a complex creation example which I haven't actually seen written down before so all right so who is behind redfish as you can see the promoter companies supporting companies pretty much if you buy server server hardware chances are you're interacting with some or multiple of these people at some stage either their stuff is inside the servers you're buying or they're actually making the servers you're buying so chances are you're going to see Redfish at some point here in the near future additionally we're working with the Open Compute Project to do their remote management profile of servers is going to be supported by Redfish.

Working with the UAFI Consortium to supplement their firmware update mechanism and to also allow discovery of does this system have Redfish from a local perspective so you can talk to a local host interface on Redfish. We're working with SNEA collaborating on storage. There's gonna be a lot of sessions on that later on in the week presented by Rochelle. And then we're also starting to work with the green group to deal with power and cooling. We already deal with power and cooling of individual servers. This is more dealing with power and cooling of entire data centers. So how do we actually scale this thing up to provide the level of data that the green group uses to do that sort of thing?

So that's what we're trying to do here. All right. What is Redfish? It's an industry standard API for IT infrastructure. We chose HTTPS and we transport JSON over that using an OASIS standard called OData version 4. It's basically designed to be usable by apps, GUIs or scripts. It's not required, you don't need to write a whole bunch of C code or, you know, code to do this. You can just script it from the command line and it will work. It's also

Shima backed, but human readable. In other words, you don't have to go, okay, what does bit four in this mask mean again? We're actually gonna spell that out in a nice string, say this is exactly what these things are. No bit masks, none of that kind of stuff. First off, Redfish is mostly focused on servers. Its first release was a secure multi-node capable replacement for IPMI over LAN. We basically took the IPMI feature set we felt was still relevant, ported it to HTTPS with REST. Now we started to add devices to cover customer use cases and technology. For example, this last year, we've added direct attached storage, we've added PCIe and SAS switching, we've added non-volatile DIMMs, we're adding multi-function adapters, aka complex NICs that are not necessarily just NICs, FCOE, iSCSI offload, et cetera.

We're also starting to focus on composability. How do I carve up systems to make larger systems? And then, again, as I alluded to earlier, we're trying to meet OCP, the Open Compute Project's, remote machine management requirements so that people can use this to manage their machines remotely from the Open compute project. We also intend to expand the scope of this over time to the rest of the IT infrastructure.

As I alluded to, we're working with SNEA to cover more advanced storage. Rochelle has a couple of presentations later on in the conference for an overview of Swordfish and then a deep dive of Swordfish. We're working with partners like the Green Grid to cover power and computing. for an overview of Swordfish and then a deep dive of Swordfish. We're working on with partners like the Green Grid to cover power and computing. And then we're also going to work to expand and accommodate existing network switch

models and standards into Redfish. So you're actually going to theoretically all your IT infrastructure managed the same way. All right, Real simple example. Basically, I have some Python code here where you basically put it in the URI, open it, you get back JSON, you parse the JSON, you read out the serial number out of the array, print that out, and there's the serial number. Three lines of code, I've got a serial number on a server.

Okay, that's kind of useful, right? I'm more of a command line guy, so I also have a command line example where all I have to do is call curl, here's the URI, I'm passing it to a JSON parser that's available for the Linux command line called jq just so I get just the serial number instead of the entire payload. So pretty simple, not a whole lot to this. So why do we choose HTTPS, REST, JSON, etc.? So HTTPS obviously you guys are all familiar with. It's well understood by admins, known security model, known network configurations. You guys know how to secure this thing. Your DevOps people know how to secure this thing. Pretty much anyone knows how to deal with HTTPS through the

firewall, etc. REST, it's pretty much replaced SOAP, which is what we were mostly using for systems management for this. It's a little bit easier, a little lighter weight. You can use standard tools like curl that I just showed you. You don't have to have a whole lot of extra infrastructure to call SOAP calls. Now REST is pretty simple. JSON we chose because, again, human readable, but it's simpler than XML, but still has large cross-language support. So basically, we look at it as the combination of large cross-platform support plus ubiquity of tools to deal with REST, HTTP, JSON,

allow us to make this use the same tools that are already being used in IT management elsewhere. For example, they can call it Google API, a Twitter API, an AWS API. They can also call Redfish. Very similar concepts. So, slightly more complex example that actually does something. But this is about as simple as you can be on an API. I'm going to blink a light on a server. So basically I need to go find this server somewhere in the data center. I'm going to blink its little Cyclops LED. So what we do is in Redfish we called that the indicator LED and I just set that to blinking. So what I'm doing is first I create a little file called LED.JSON that has a very simple JSON in it that says indicator LED to blinking. That's all I said. Then I call curl, tell it to patch, pass it the file, pass it login information.

One thing Redfish does support is it supports both basic authentication and session authentication. So if you don't want to go through the complex ordeal of setting up a session for just simple something like this, you can just pass your credentials on the command line and do basic auth. Set it to the URI that I need to blink and lo and behold the LED will start blinking. We also try to keep the same paradigm alive as much as possible. So if you need to blink a disk drive, whether it be a hard drive, SSD, whatever, same exact thing except you notice it's a different URI. It's essentially a different resource that we're telling to blink now. Other than that, the file to do it looks exactly the same.

So would you recommend an HTTPS to your sending password? Yes. Redfish basically says that anyone that's implementing shall implement HTTPS. So they're required to by the standard. If they want to also implement HTTP, they are allowed. But for security reasons, obviously, I'd want to use HTTPS pretty much all the time. It's me. But again, if you're confident your network's secure, et cetera, you could do HTTP.

You could do session-based auth over HTTP to abstract out your credentials a little bit. So yeah, that is totally allowable. But again, we typically stick with HTTPS mostly because it's more secure. Good question. We typically stick with HTTPS mostly because it's more secure. Question. Is this sort of like the BMC or by some software on the server? So either way. The question was is this the BMC or some software on the server. In essence, Redfish could be in any of those things.

It can be a management controller inside the server itself, firmware, it can be software running on a host, doesn't really matter what this is. There are ways to discover that which I'm going to go into a little bit here in a minute. Basically you discover that something is Redfish capable, doesn't matter if it's software or firmware or whatever, it's a Redfish endpoint that you can talk to. And I'm going to go over that here so that we can actually talk about how you can actually, once you've discovered a Redfish endpoint, figure out what this is and what it's doing. So let me take a real quick step back. There are a couple of actual ways to figure out this thing has redfish. One is being told it has redfish. Second is

we have a SSDP mechanism, simple discovery protocol, basically similar to UPnP. You plug this thing in and it announces to the world, hey, I've got redfish. The new one is our new host interface where if you boot up, there should be UEFI variables and SMBIOS tables you're going to be able to read that basically say, hey, here's how you can go to the local copy of Redfish that the BMC is exposing or whatever that actually says, hey, here's my copy of Redfish. Once you know something has Redfish, there's only one URI that is absolute set in stone and that's slash Redfish. When you get slash Redfish, you'll get contents back that looks something like this.

Very simple JSON. Right now we only have a version one. So it'll say version one is at this URI. It's not necessarily at slash Redfish slash V1. Most people have done it that way for simplicity's sake, but you really can't make that assumption. The standard doesn't allow you to make that assumption. So it could be at slash foo. So you make that one call.

You figure out where the service route is. So in this case, it indicates that the service route is at slash redfish slash v1. Once you have that, you can obtain that URI. You get back what we call the service root document. Service root document looks something like this. For the most part, if something says at OData in front of it, you can mostly ignore it. That means it's OData metadata. I'm going to go into why we did OData in a little bit.

Suffice to say, there's some standardized tools that can just handle OData things when you point them at it. Like there's even a plug-in for Excel now. You can actually say, here Excel, read this OData endpoint and it will do that. So for the most part, don't worry too much about the at OData stuff. Everything in Redfish has an ID and a name. The ID is basically a unique descriptor in this collection. The name is more human readable. In this case, not very interesting because this is the root service. The Redfish version is the version of the Redfish spec this service is compliant to. So 104 is our latest. And the UUID uniquely identifies this Redfish service. So for example, if I have multiple IP addresses that have been appointed to the same Redfish service, they're both going to spit out the same UUID, so I know I'm looking at the same Redfish endpoint.

These other things are collections, which I'm going to go into on the next slide. So basically the service group can also get a whole bunch of what we call root level entities for Redfish service. Currently these are systems which are basically all your application servers this thing manages. It's a simple BMC, it's probably only going to be you know exposing one of those things. If it's a chassis controller for a blade chassis, it might be exposing one for every single chassis in the blade. Or it could be even doing multi chassis management exposing one for every single system that you've connected to. If it's some kind of Redfish aggregator or some other service running on a host, who knows how

many nodes it could be reporting, right? So it's really, again, we try to make sure this thing scales all the way down to BMC, all the way up to something like a data center management software. Chassis are all the actual raw sheet metal chassis that are in the system. Again, that could be as many as one, could be as many as thousands. Managers, these are more the things that are actually doing Redfish usually. There are also provisions for modeling things like just a simple fan controller. So these are things that are actually doing management of your hardware. Task management service, basically the Scout long running tasks.

Session service, again if you're trying to do session management, logging in using sessions, you use that. There's an account service to provision new accounts. Event service to subscribe to events. If you're used to SIM, this is what in SIM is called alert indications. Registries are basically a set of message registries. What we've done here is we've actually allowed for a Redfish service to point at localized files.

These might be hosted locally, they might be hosted elsewhere. We're basically saying here's where you can go get localization type information or more extended information about error messages, etc. So these are just registries of that sort. There's a set of JSON schemas. OData has its own set of schemas called CSDL. We also produce JSON schema. Both are normative, both are allowed, both are supposed to be equivalent.

So basically, if you're more comfortable one way or the other, you can do that. If you never want to look at a schema, you can probably muddle through. That's part of the point of this. Lately we also have now added fabrics, which are some very simple fabrics like PCIE and SAS that allow for some very basic setup of how those fabrics work. Then finally an update service to do firmware update. Patrick? Yes. those fabrics work. Then finally an update service to do firmware update. Yes?

There's one missing from this which we'll cover in more detail in the surface deep dive, but you will actually see it when you look at the DFTF redfish surface and that is the extension placeholder for storage systems. Yes, I did not want to steal your thunder. But it actually does show up when you go see the redfish surface. Yes, again, we have allowed for extensions to this and one thing that's going to happen to swordfish is adding a few elements to this, which is seen as extensions on top of redfish.

Like I said, I wasn't trying to steal Rochelle's thunder, so I left them out. So As Rochelle pointed out, yes, they are there, and yes, they are part of the DMTF standard. DMTF and Redfish have worked very closely together to make this seamless from a user point of view. Where Swordfish begins and where Redfish begins, a typical user of this API really is not going to be able to tell.

It's going to be pretty nice. Question. What do you mean by fabrics? Okay. Like I said, this is a very simple fabric solution. What we currently support is PCIe and SAS. There are talks in SNEA to add a few elements to this, to add fiber channel. It's going to be a very, very basic fabric model to deal with a SAS fabric, a PCIE fabric,

maybe a fiber channel fabric. We're probably not going to get off into Ethernet fabrics. They're a little bit more complex. So there's probably going to be a different model for those somewhere. But yeah. What kind of information is it? I mean, it's like box pieces. I was thinking similar to Australia.

Is that any fabric information? somewhere but yeah so mostly what it's meant to do is it's got three kind of elements inside it it's got endpoints zones and switches switches I think you know go without saying are the actual things doing the switching. There could be one of those in a fabric or there could be many. Endpoints are the things that you can actually route and make visible. And the zone is the collection of things that are visible to each other. So in other words, you basically say, I have these 10 endpoints that I want to be able to have M.1 see M.2, you create a zone with M.1 and M.2 in it. That's it. It's a very, very simplistic model of fabric, not necessarily anything that is

strictly inside the box or outside the box right now. Again, it was originally designed for PCIE and SAS switching, both of which can be inside the box or outside the box. Those were kind of our initial guidance. We worked with SNEA and basically said, hey, does this model in basic ways support fiber channel? And they said, yeah, there are a few things we need to add. We said, great, we can go out with this then. And so that's kind of the Redfish model at work is let's start, get something stood up. Does it break anything in the future? Cool. It doesn't? All right,

we can ship and then we can add things in the future that we know other technologies are coming. So. And what we can say is that network, Ethernet switching and networking is also going to come in here at this level. Yes. There's a whole wrap and stuff coming on that. What we can say is that network, Ethernet switching and networking is also going to come here at this level. Yes. There's a whole route and stuff coming on that.

Yes, exactly. We're adding Ethernet networking to this as well, Ethernet ID network. Yes, it's just not currently in fabric. It's not in fabric. It probably will not be in fabric, but yeah. It'll be different because of the modern Ethernet patterns. Yes. And as you ask questions, you get red fish.

All right. So now each of these entities that I just talked about can contain more entity types underneath it. So for example, a computer system, which is under the systems element from the service route, can contain processors, Ethernet interfaces, simple storage, log services and storage. Theoretically other things as well. Simple storage was the initial kind of release of, hey, here's HBA level storage. Every single thing you see is a physical device.

We kind of looked at that and said, well, we need to support more complex storage topologies as well. So we added storage, which is a bit more allowing for volumes and drives and not have a one-to-one relationship anymore. Processes are obviously your CPUs. Ethernet interfaces are your network controllers. Log services are what logs your system has. For example, your system may have an OS log, may have a cell log, may have some other type of chassis-tied lifecycle log. These are all examples of log services that might be exposed

on a system. All right. So let's take an example again. So we want to discover every single drive that a Redfish service is modeling. So first, we would go get the service route, which I already showed you. Next thing we would need to do is we need to get everything under systems. So we just do a get on systems and you're going to get back

something that looks like this. This is what we call a collection or entity in Redfish. The important things to look at are the members count and the members. Most of the rest of this is just metadata. So metadata, the members count tells you how many members you have. Because this could be paged. One of the things Redfish allows for is if I have 5,000 of these things, I might not want to get all 5,000 at once. Or the service may not be able to return all 5,000 at once. So it may say, here's 100 and there's more.

And there's ways to go page through that. And so the members array is the actual entities that we're looking at. So in this case, this is probably a simple BMC. It's modeling one system. So now we need to get that one system. So the previous page showed us the systems URI was redfishv1 system slash one. So we get that and we want the storage node. We want to know what storage URI for this guy is. So that comes back with redfishv1 systems one storage. So in these examples, and quite often the URIs are simply the name of

the node added at the end of the URI. Again that's not required so you can't make that assumption. You can't just assume it's slash storage. It could be slash foo. So that's why we have to go through these steps. So now we need to know how many different storage entities are available on this computer system. So we do a get on storage. And now, in this case, we get back two. For this example, I have a simple onboard SATA and a RAID card. Those are modeled separately because they are basically separate storage domains. If I have a RAID card and an onboard SATA chip,

they're accessing different drives, producing different volumes. They're not really interacting with each other. So they are both produced separately. Now, I could go through each storage entity and then determine the URI for drives, enter each drive, and then go get a git on each drive. But that's pretty tedious. So I'm going to show you one of the tricks that Redfish allows.

It's this little thing right here where it says $expand equals drives. What that does is that says expand out this one field. In other words, hey, service service go do all these tedious gets for me and so basically what that has done is it's actually instead of me having you know normally right here there being at odata id colon and a uri and there'd be a list of those and i have to go get each one of those individually what this has done instead is actually put the data here in the payload for me. So now I see the ID, the name, the indicator LED, the model, the revision, the capacity in bytes, and a whole bunch of other fields.

I just put a dot, dot, dot so I wasn't overwhelming you with the 8 million fields we have for drive. And then the next one, and the next one, and the next one, et cetera, et cetera, et cetera, until I'm out of drives. So, yes? How stable is the enumeration of things that there are multiple copies of? If you ask for a list of drives and then somebody pulls a drive out or adds a new drive, does that scoop the later drives down the list so that you're not really quite sure what you're accessing?

So the question is, how stable is the enumeration of drives, or any entity for that matter? In the case of drives, it's actually very stable because the way we modeled an empty slot is an absent drive. There's actually a state field in these things, and basically all we do is say, hey, that's an absent drive. So that's actually how a model drive slots. In other cases, yeah, if I'm modeling multiple systems, let's say it's a blade chassis, for example, and I didn't choose to model the empty slots as absent chassis or systems, obviously I don't know how many systems are gone because that one slot is empty, right? Then, yeah, it could change after I did a get and someone yanks this thing.

However, we would send, you know, if you were subscribed to the event service, we would send you an event saying, hey, these things changed. And actually give you the URIs of the relevant thing that's changed. It's actually in the events. And so that way you're able to actually tell what changed. So that is, you know, the hope for things that aren't stable. You'll be able to go, oh, okay, this thing just changed. I need to go get more data if I'm, for example, writing a data center management console that needs to know how many systems I have that are currently up. A system goes down and can't be talked to, well, then that one might disappear. But, hey, I'm going to get an event about it.

All right. So I've shown you how to blink a light, how to get a field. Those are kind of nice. But, you know, let's do something a little bit more complicated. I'm going to create a volume, a.k.a. virtual disk, logical disk. So what I'm doing here is, again, setting up a file. In this case, we need to provide at least three things. Actually, we only really need to provide two things

to the Redfish servers to have it create a volume. I'm also providing the name. You don't necessarily have to provide that. I need to tell you how big the volume is, and is and I tell you what type of volume I want created. So in this case I'm doing a one tibibyte volume and I'm saying it's a mirrored volume. I'm putting that in the file. I don't necessarily have to do this file step by the way on curl. It just makes the command line a little cleaner because if I put all this stuff inside the

quotes here it would be really confusing. I could actually do this in one single line of command line if I wanted to. Basically what you do is you post. That's our create operation. Pass in the volume we want posted. Again the login information. What I'm doing here is you'll see that storage RAID volumes. Volume is a collection of volumes.

So when you create something in a collection is you post to the root of the collection. So there might be a volume slash one, volume slash two, volume slash three for the three volumes I may already have. But in order to create a new one, I have to post to the root of the collection. Once I do that, I just created a volume, name test drive, the size of one tibibyte, utilizing mirror for redundancy. It is probably relevant to point out at this point that depending on how long the operation takes, you may get a success back immediately or you may get a task. We talked about the task service

earlier. I don't actually have an example of that in here, but basically you may get a success back immediately or you may get a task. We talked about the task service earlier. I don't actually have an example of that in here. But basically you may get a handle back that basically says, hey, we're working on it. And there are ways in the API to tell that. So that's most of what I have. I have a few backup slides for a few more complicated examples if anyone wants or if we have any more questions sure So the question is, what is the data center? What equipment is there? What is there in each of those systems in the data center? What do they use currently today? And how that changes with Redfish?

So what do they have? What's their stack, software stack, and their way of managing the data center today? And what does that look like with Redfish before and after? Okay, so the question is, if the use case here is data center management, what does that look like currently, and how does Redfish change that?

First off, that is a use case of this API. It is not the use case of this API. Today, they use a combination of IPMI, SMIS or SIM and essentially homegrown tools slash vendor proprietary means. Most data center management tools I know of usually know how to crawl inside the OS's inside Windows through WMI, inside VMware through some VMware specific APIs, some of which are now actually RESTful, etc. The way Redfish changes all that is essentially takes what we thought was good out of IPMI and SMIS, makes it in one pane of glass.

It's a little simpler to access. You don't have to understand what profiles are there, etc. The idea within SMIS, you don't have to go, okay, this is a Dell server, we need to call this IPMI command. This is an HP server. We have to call this IPMI command because IPMI wasn't quite implemented exactly the same across the board in some cases. There's actually a whole bunch of things in IPMI tool that go and handle that. If I was going and trying writing code from scratch, I'd have to basically replicate all that. There are a few places where it's just not the same. And in these cases, we have a very clean model for adding OEM extensions on top of Redfish that

IPMI really didn't have as well. It just reserved commands, but unfortunately, it didn't have a good way of reserving parameters to commands. And that was part of the problem with IPMI. With SMIS, again there were a few the same kind of compatibility issues and then honestly it's not quite as client focused. Neither is IPMI. For example, if I wanted to get a picture of all my thermal data in my data center, for IPMI, I'd have to go look at sensors and figure out which are my thermal sensors and then also go look at this fan table over here that's different from the sensor table and kind of put this picture together. Similar thing for SMIS.

I'd have to go enumerate many different objects. On Redfish, I'd basically say chassis slash thermal. Here's all my thermal data. And that's all assuming you're talking to the standard APIs as opposed to everyone's proprietary APIs. Yes. A lot of people have hunted working with standard APIs because trying to take care of DevOps guy,

he wouldn't work directly with SMS because the learning curve on that is really high. Yes. So you'll probably end up going and working with each vendor's proprietary REST API or proprietary command line API or something like that and doing exactly the same kind of things that Patrick's just describing. So that's where a lot of this stuff comes in for both Redfish and Swordfish is, you know, can we give them tools that they're used to, that they can plug in,

because they're already working with a lot of us on Python and standard API or standards tools. Can we come in and can we give them things that work well with the tools that they already have? I'm definitely going to make that office. Yeah. It was just curious that the mapping is already existing and that will just make it. Yes. No, again, absolutely exists, but we think this is a lot cleaner and a lot easier for people to deal with, especially just the DevOps guy that may not really be a great computer programmer. He can use command line tools, he can Google on...

I'm blanking on the name. He can just Google the question, and there will probably be an answer there on how to call a REST API, how to deal with SOAP, how to deal with IPMI. That's a lot more specific, and honestly, it's a lot more subjective on this system, this system, this system. You're going to get different answers. Redfish, you'll get basically the same answer. Yes. Yes. How do you know which model to choose, and do you have the option to define the label?

So, you know, who gets to design it before you call that on it and you see what I'm saying? Yes. Okay. So the question is, you know, in this case, I said volume type mirrored. How do I know what the mirroring strategy is, et cetera? The focus for Redfish is more what than how. In this case, the guy wanted his data mirrored. He doesn't necessarily care how.

If I wanted to control that on a more granular level, what I would do is I would probably add OEM extensions or if we found there was an industry wide case for this mirror strategy, this mirror strategy, this mirror strategy, then we would add that as a separate field or we'd add it as an OEM field.

Essentially the desire here is here's the basic and if I want to add more bells and whistles and more knobs, we can do that later as well. So as far as what the mirroring strategy is, et cetera, most part the thought is, eh, user wanted to mirror volume. Also, a lot of this is focused exclusively on the local storage. These are servers and local attached storage.

So when we're talking about more complex storage configurations, that's when we're going to go to the source-push parts. So we can talk about the more complex storage configurations and how we do that when we go into the source-push parts. So from the source-push parts. Exactly. So, yeah, again, this is DMTF standards. This is very focused on local systems, the server itself.

It's not quite as focused on SANS or NASAs, et cetera. If you're interested more in that, then absolutely go to Rochelle's talk on how SNE is built on top of redfish. Yes? So if you have a fairly complex system, you try to enumerate for everything. Are you looking at a tree structure so that as you go down it, you keep going down it, and once you've walked all the tree, you've enumerated your whole system? Or are you looking at a network where you have to be aware that, well, this server might have hooked to this switch,

and this server's also hooked, so you've got a graph, and you have to kind of keep track of everything you visit as you go through to enumerate the system? So the question is, on a complex system, are we dealing with more a tree structure or a graph? It is probably more of a graph, because as I called out earlier on all the things at the root, there are definitely links across those.

For example, the system is more, it's actually kind of a combination of tree and graph actually now that I think about it. So for example, system is kind of the logical view, right? I can have physical systems, I can have virtual systems. Chassis are kind of the physical view. Here's the actual sheet metal. Here's the power domain inside that, the fan, the thermal domain inside that. Here's managers, which might be the BMC, might be a fan controller, might be some piece of software running an OS.

And so there are links between all these things. The chassis tells me what systems are in it. The systems tell me what chassis they're in. The managers tell me what chassis they're in. The managers tell me what chassis they're in and what chassis they're managing. The chassis tell me what managers are managing them. Everything's linked everywhere else.

One of the things we did very specifically is everything's contained at one place. What I mean is if I do some crazy stuff with the expand operation, I basically can't end up with multiple copies of the same object. I'll end up with references instead.

That way, if I'm just writing a client that's doing some kind of crazy get that's going to try and get everything in one go, I'm getting references so I can reconstruct all those pointers, but I'm not ending up with 50 copies of the same object, or entity, sorry, so that I'm getting confused up with 50 copies of the same object, or entity, sorry.

So I'm getting confused. Would you say that discovery is more tree-oriented, but when you get into the details, you're actually going to mesh? Correct. Yeah, absolutely. When you're initially discovering these things, it is definitely more of a tree operation. You start at the top and basically do either breadth- or depth first search depending on what you're looking for

if you're just trying to obtain everything. You know, once you actually start getting into it, you're going to start seeing all these interlinks and how everything's connected so you do know all this data on how is this thing connected so you can do things like isolate failure domains, see

how things are connected in a fabric, etc. Yeah, and remember that when you go discover multiple distinct translate failure domains, see how things are connected in a fabric, etc. So. Yeah, remember that when you go discover multiple distinct management touchpoints, those may be connected up to each other on the back end network or fabric or whatever. And those you have to do your graph and cross reference. So there are IDs in here that can hard cross-reference, right? So to build the network graph,

you have to use that method to enumerate under a given management touchpoint all the systems and so on there. It's a cross-reference tree or a cross-index tree. So you descend the tree, but there are links to other things in there. And there are some models

where things are effectively enumerated twice. And when you do the networking stuff, start introducing those things. If you look at the way gang models are done, oftentimes you'll go down and go, oh, here are all my ports. And then you'll go, oh, but I have a virtual network device that has those ports again. So the box has a bunch of ports or interfaces, and then this virtual site has a bunch of interfaces, or this VLAN has a bunch of interfaces.

And so, if you think about it, you're traversing, you've got to do two different things if you want to manage an entire data center. The beauty of this is if you get all the devices of many of the same API for the common facilities, thermal power cooling chassis, and even some of the OS stuff, that's a huge advantage because you don't have to got from SNEA, they called it durable name in their SMIS profiles. We now call it identifiers. And essentially it's a worldwide or a, you know, depends on the exact circumstances, universally or, you know, system unique ID at least, that you can use to correlate these volumes and etc. across different systems.

So if I am discovering, let's say I had a BMC implementing redfish over here, and I had a big storage array implementing stored fish over here, they're both going to produce a volume entity. They're both going to have a durable name or an identifier that's the same. So I actually go, okay, I'm crawling this and crawling this. This volume and this volume are the same volume. That's how this guy is talking. He's reading data off this array over here.

So that's one thing that we have. So that's an example of the collaboration that Sneha has brought to this that has helped us be a better standard. Is there compliance testing also done? Is there Redfish compliance testing done for the people who are building the systems supporting Redfish? So the thing we're actually doing differently for Redfish is we're open sourcing the compliance

tools. So all the tools that basically say, hey, is this Redfish service compliant with the standard, all open source. They're going to be in a GitHub repository called Redfish Tools. And basically it's going to allow customers to run their own tests and wrap their own tests around this. So that's kind of our thought on this, is to empower the customers to figure out their own interop testing.

There's not going to be some kind of DMTF standard test that basically says, yep, DMTF approval, you're a redfish. We don't have that on purpose. Maybe I missed that question. Did you get a question on how you fit in these are the Yang and NetConf and their configuration and orchestration models and where do you fit in the ecosystem?

No, so the question that I was answering was basically what does the compliance testing model look like for Redfish. As far as how do we fit into Yang, etc., I would suggest you talk to Joe. He's actually working on that exact problem right now. How do we take the Yang models and basically create an equivalent Redfish model out of them? The idea for Ethernet networking switches is to take the Yang model, translate it into the underlying schema language of OData, which then gives you a JSON Redfish compliant API

to talk to your network switch using ITF, OpenConfig, IEEE models. Plus proprietary is easy, vendor extension is easy, because that's just the beginning again. And so we have a spec that's just got its work in progress number, it's justrusions, because that's just the gang again. And so we have a spec that's just got its work in progress number. It's just out now on how to translate gang to something called CSDL, which is Common Schema Definition

Language, which otherwise is Redfish. But then there's a tool to take that schema output and translate it to JSON schema, like JSON schema or JSON schema, not just any old JSON schema. And then you take that and that's your JSON, that'll tell you your JSON messages. So effectively, you just send JSON messages but there's all this back-end structure to help you organize everything. And if you want to take advantage and you provide the metadata service, you can get all these XML files that tell you how all the data is organized and all the annotations and just a ton of information on the structure of the data.

It's type, it's enumeration, it's limits, it's this, it's that. YANG has that, as you well know. And so we back everything in YANG, every single thing in the end, into something in ZSDL such that it could be with Redfish. If you go back to your overall list of all the models, there. So we're going to put something called network devices at exactly the same level, and you can enumerate as many network devices as you want. So if you have a chassis, you can do the chassis itself.

You can do the sliding parts, all with separate network devices. If you had an ethernet fabric, you could do that as a touchpoint for the fabric level control, plus one for each of the network devices. If you had a stack switch, it'll work. If you have just a single switch, it's pretty easy. And then whatever Yang models that the networking vendor wants to use, and then we'll be working on some canonical models for some various departmental scenarios and things like that.

That's about to start. And that all came out of work from something called the consortium, which was a few companies that put together that initial thing. Is that me? Yes, please introduce yourself so that you can Oh, yeah, yeah. I'm Joseph White. I'm a distinguished engineer at Dell.

Joseph White. W-H-I-T. W-H-I-T. Yeah, Joseph White. Yeah, so he's part of the, what are we calling it, the Ethernet subcommittee? Yeah, the Ethernet Task Force. I think it's Ethernet Task Force is our official name, but we've developed a gentleman named John Lund, who's a long-term DMTF, SPMF guy, our co-chairs for this. And John works for Intel. And John's from Intel.

Yeah, so all that work is happening, again, on the auspices of the SPMF, which is the group that does Redfish. So this is going to be in the redfish standard as well rallied working groups, overall structural model that they're working on just split into three at the last ITF meeting, or anything like that. I think you could just join. I think you can come. Any of the member supporting companies, ideas. We've gone down here for a lot of already, and that provided us a lot of context and information. So there's a lot of stuff there. So if you want to. I'm an entrepreneur.

I'm an entrepreneur. OK. Founded a couple of companies. Oh, sweet. Nice. Thank you. OK. Yeah.

OK. Thank you. What is smart fish versus red fish correlation again? OK. Okay, so again, Rochelle's going to go more into this in her talks. Redfish is focused on local servers. Basically, it's focused on servers. And then Swordfish is focused on storage. So it's more what does a you know R-BOD or large array of storage look like you're gonna go to the Swordfish model for that. What does a server in BMC look like you're gonna go

to the Redfish model for that. However, there's a lot of overlap. For example, they're both contained in sheet metal. They both have power supplies. Both have fans. Both have temperature sensors. So we're trying to leverage things as much as possible. I'm confused. I thought Redfish was expecting its scope to do the switches,

fabric, and storage. It covers local storage. We'll cover it. So come to a talk on Wednesday morning and Wednesday afternoon, both of them. We'll go into detail on all of it. And the simplest

answer you're going to get is swordfish is an extension of redfish. Swordfish leverages all the infrastructure. Everything on here, plus. And it will be compatible with is an extension of redfish. Yes. Swordfish leverages all the infrastructure that this brings into focus. Everything on here plus. And it will be compatible with.

It brings in DMTF and STEA are actually working in conjunction, which is good and interesting. I said, so swordfish will be not compatible with. It's part of redfish. It's just being run out of steam. But Castilla has the storage management initiatives and came up with SMIS many years ago, which had success in a few areas for the SID model. And this is sort of, swordfish is up there.

I'm stealing all your stuff. So it's all going to play nice together. It's all going to be part of one unified superstructure. Shared storage, remote storage, logical partitioning of remote storage, all that complicated good stuff is all in Swordfish. Core server management and system management is solidly in Redfield. And Redfish defines all the protocols? The hybrid converge would be dead center. So, you know, again, from a user's perspective, there is no difference. They really should not see it. Really, the biggest difference here is where it's developed.

DMTF develops Redfish. SNEA develops Swordfish. From a user perspective, it looks the same. They hit the system endpoint. They don't really know that it's running Redfish or running Swordfish. It's going to say slash Redfish because we're going to say slash Redfish. Whether it's implementing a whole bunch of these entities that are defined by SNEA or a whole bunch of these entities that are defined by redfish,

it's probably going to end up being a mix of the two probably regardless. It really helps us accelerate the development because the SNEA can go off and focus on defining the storage pieces in parallel. Yeah. I was wondering, I think the first kind of thing to look forward to here is that Redfish plus Swordfish plus what he's doing leads to a unified management approach for most of the stuff you'll find in a data center. So finally, you can have software

that can depend on a standard being in place where it can reach into different domains and actually do something meaningful for automation. That's the real game. And they keep saying the word composability. They mean if you just have a wall of processors, some networks, and a bunch of storage, you could actually construct logical systems out of this.

You might need a five-processor, something that has that storage over there. You can construct that with a single management station. So that's the end game, but right now we're talking about, you know, pulling Patrick's telling us about pulling the infrastructure stuff together. That's it started with server management and what Rochelle and the Twitter and the SNEA people are doing is adding the complex storage to it. And what he's venturing off into now under SPMF will actually pull the ethernet parts into the game. So you actually have a unified approach

for the management of servers, storage, and all headers. And we don't throw out anything that exists now under ITF, IEEE, and open config groups. Because the models that all those groups have put forward already for how you organize network switches, you can't just throw that out. There's vast amounts of good information and so on. You just need to find out how to plug it into all of this so that you get unification which is what we've done the first step up there are a few steps we've done the first step we've proposed the first step the first step has to get ratified but it's a pretty good attempt on the first step we're most of the way there on the first step which is translation and incorporation

all right we're about out of time. Any other questions? Ken, Rochelle, point us to some documentation on storage? Absolutely, though. It's nia.org slash swordfish. Just, you know, also look at your handy little... It's right. Thank you. And

we've got the keynote at 10 o'clock on Wednesday. There will be an overview of Swordfish at 3 p.m. with Deep Dada on Swordfish Wednesday as well. You need more incentive. There will be a giveaway to give away a drone. You know, like Phantom 3.

I can tell you from personal experience, it's really fun. Thank you. So, I can't do three. I can tell you from personal experience, it's really fun. Thank you. Thanks, everybody. Thanks for listening. If you have questions about the material presented in this podcast, be sure and join our developers mailing list by sending an email to developers-subscribe at sneha.org. Here you can ask questions and discuss this topic further with your peers in the developer community. For additional information about the Storage Developer Conference, visit storagedeveloper.org.