Storage Developer Conference - #74: Dip your Toe in the Water: A Swordfish Introduction

Episode Date: August 27, 2018

Hello, everybody. Mark Carlson here, SNEA Technical Council Co-Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the storage 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 podcasts. You are listening to SDC Podcast Episode 74. All right, so what we're basically going to be talking through in here today is, you know, what is Swordfish and kind of what have we been working on. And, of course, there's a standard disclaimer here, right? This stuff is all work in progress. We released the version 1.0 spec as a SNEA technical position last September.

But most of the stuff that we'll be talking about and that we've released as work in progress is all, you know, just that, it's a work in progress. So subject to change without notice. This URL, if you remember nothing else from what I tell you right now, it is on the coasters. It is on the cards. Remember this piece of information today, snea.org slash swordfish. This is where you will find everything current.

If you don't start working on swordfish right now, you wait six months, you go home and you want to start looking up stuff right now, this is where you will go. You'll find the latest information. You'll find pointers to everything we talk about, snea.org slash swordfish. All right, so what are the drivers for swordfish? If you were in listening to John earlier, he talked about what the drivers for, you know, for servers was this proliferation of large-scale data centers, things like that.

So you see a little bit of that same kind of thing in the storage space as well. But, you know, we also have a slightly different history in the storage space, right? So customers have had, you know, kind of SMIS around for a long time. We've had kind of a single management API, but the storage world has been changing a lot. So we've got kind of two or, well, multiple factors, but those kind of two different threads moving, right? The storage world has kind of been shifting in terms of the way people are deploying things. And so we need to be reactive to that. But we also had a lot of people asking for inputs and changes in the existing standards.

And so we basically took a lot of those different kinds of things into account. So what can we do in our APIs, in our standards, to make them simpler to implement and consume, right? So a lot of the existing standards were built from a vendor perspective, right? Here's all of the detailed information. But from a client perspective, from a consumer perspective, I want this set of data. Can you give it to me in a single command? So that's, you know, improving that access efficiency. So fewer transactions, more useful information at once.

You know, I want to get stuff through a standard browser, right? It's not simply a storage admin looking for data anymore. It's, you know, it's my DevOps guy, right? So how do I, you know, how do I provide something that's both for a storage admin as well as for a DevOps guy? And, again, the storage market has really changed, right? It's not DAS and SAN anymore. We've now got cloud. We've got hyper-converged, hyper-scale.

So how do we make a standard, you know, modify a standard or make a standard that can actually meet the needs of all of those types of storage environments? So that's really what we kind of stepped back and said, okay, how can we react to that? And so, you know, a couple years ago we basically said that's what we need to do. And so we said, okay, let's take all the learnings we have from, you know, years and years and years of SMIS development, a bunch of work that had gone into that, but let's also look at what DMTF has been doing with Redfish and take those two starting points and just kind of start from there rather than making a continued evolution of something

that is frankly a hard implementation point. It was something that's difficult for both clients and vendors to implement from. So the other kind of piece, and I'll talk a little bit about it in here, but lots more in the next session, is moving to a – oops, sorry, I have a very sensitive mouse, move to class of service-based provisioning and monitoring. And so this is something that's really, really interesting to drive into a standards-based API, right? We're no longer just saying we're going to expose every single attribute of the system

and leave this from a vendor perspective. We're actually driving class of service into the standard. Okay, and then obviously, you know, traditional stuff like let's cover block, file, and object. And we already talked about extending the domain so that we're covering DAS and SAN, and then moving that to, you know, all of these converged environments. And not just focusing on storage, right? Nobody just does storage anymore.

You've got to cover storage network and servers and make sure it's a really truly integrated thing right so this is where our approach then of saying we're going to extend redfish and make and you know the stuff that if you're in here listening to john earlier where we have redfish that is seamless um you know redfish and swordfish are not different things. And we'll tell, you know, he talked a little bit about that. I'll talk more about that. They're not different things. We build swordfish using redfish. And so, and redfish is adding networking. And as we build storage networking infrastructure, it uses the exact same components.

All of these things need to be a seamless integration. We can't manage data centers, particularly from a standards perspective, with divergent standards, I guess, is a way to say that. They have to be all integrated together. And having them all be based on the same schema and allow vendors to implement them in a completely integrated fashion.

Okay, so how we did that, you know, no surprise here, right? We leveraged the Redfish spec, and Swordfish is built as a pure extension of that. All right, so who is developing Redfish and Swordfish? We really like this picture because this kind of gives an idea, and John talked about this earlier as well, is it's the same companies. There's groups in the middle. A lot of the people that are really active in developing redfish, it's the same companies that are really active in developing swordfish. So it's not, you know, you can see there's a group of people that care about the swordfish side

and a group of people that care about the swordfish side but that overlap is just as many people in the middle as there are on either side right okay

so I want to spend a little bit talking about, you know, what we've been doing and how things have been growing, right? So we mentioned, you know, we kind of, I already mentioned that we basically rolled this stuff out last year, but we're basically, you know, two years into this thing we started a little well not even quite two years ago we basically kicked off the twig the technical workgroup is it's called scalable storage management so if you hear someone you say SSM that's the group that produces the swordfish back we kicked that off in December of 2015 we released the first version of this

back nine months later. And the reason we were able to do that is because all we did was build the storage-specific pieces on top of Redfish. We, and I'll talk in a little bit more detail here in a minute about what that means and how much of that we leveraged. And then once we did that, we basically spent the time since then and this year focusing on validating that rather than throwing a bunch more crap into it and focusing on helping, you know, get some initial implementations out there. Some of that's proof of concepts to validate that. Some of this actually helping folks to say, okay, let's actually start to get some implementations out there.

You know, put it driving documentation, supporting materials. Once we go through some examples and some details of stuff, I'll circle back around and provide some more information on all of this too. Again, you know, things like open source tools, infrastructure development. We're not duplicating anything, and John talked about a bunch of these earlier as well, on the Redfish side. We just use all of those. We're developing some additional stuff to help Swordfish

and also some of the stuff we're developing the Redfish teams can use directly. So everything we develop they can use and everything they develop we can use. And, you know, and then we've been doing a bunch of plug-fests, so we'll talk more about that, too. So what did we put in 1.0? What's out there? Block storage, provisioning with class of service control. You can see I highlight that everywhere because that's a really key mechanism.

Volume, you know, volume mapping and masking, replication, capacity and health metrics, file system. You know, so it adds, you know, how do we do that? We added, you know, basically file system and file share. But other than that, it uses the entire block system model. So it's not a, you know, completely divergent model. So it's not a completely divergent model. It basically just added a couple of schema and then leverages entirely the block storage model. So it's a very, again, extensible. The same way we leverage Redfish to develop Swordfish,

we leverage the block model to develop file system. And additional content, we added the object drive storage, not full object store, but object drive storage. So that's kind of the level of functionality that we rolled out. We've been adding some incremental functionality. I'll talk about that, some of the details about that. So John kind of showed a little preview of this picture, right? He talked a little bit about, you know, what's

actually the hierarchy of redfish. I'm going to talk through this again a little bit so that I can talk about what we added into swordfish and how we structured this. And just real quickly, how many of you, I mean, I know some of you were in here for John's presentation. How many of you have seen this before? So I can see how to go through, how much detail to go through. Okay, I'll spend a little bit of time on it then. So the basic way that the redfish tree is structured is there's kind of a split between the logical structure and the physical structure. And then there's this third area.

You can kind of think of it as, from the redfish perspective, it's called managers, but that's where they put the BMC stuff. From the historical storage management perspective, we will extend that area to put what we think of as the storage management as well because it's where we've had SIMOMs and the like. We can lump that kind of functionality in there. So a lot of our implementations that have things like integrated management cards and stuff, we can just extend that functionality there. They tend to be a little bit bigger than BMCs, but we can, you know, logically,

it's a good logical place in the model to put that capability. So the systems up here on the top is kind of think of that as the logical system. The chassis is, again, where you put the physical components. So you can see over here, you know, power and thermal kinds of things. But the system up there is that logical view of the system where you'll see processors, disks, and NICs modeled. And so we basically took that same system and said, well, you know, there's not a single thing in there that you don't use to comprise a storage system. So we will just take all

of that and reuse it. And so we squish the model down and we layer in purple for SNEO. We layer in basically two key components of the model. And so a couple of things you'll actually see here is when you're – a couple of things that I think – well, I'll call out explicitly because you'll see them again in a little bit, is when you're talking Rust, there's a couple of different ways that Rust can model, but we're using an explicit hierarchy here. So the slash redfish slash v1, everything will be show up under

the trees exactly like this. So you've got these services over here, sessions, accounts, schemas, events, for more updates, some other ones that aren't on here. They will basically show up exactly in that hierarchy when you are navigating a system. These other ones will actually also show up in what we call the Redfish service route. So you'll see the slash managers there, the slash chassis, slash systems. We've added these other two to the service route. So you'll see the slash managers there, the slash chassis, the slash systems. We've added these other two to the service route for storage. So we've added storage systems, which again, it's that logical view of a system. And then the bulk of the functionality actually goes into a storage service. So let me talk about a storage system for a second. A storage system is really, you can kind of think of this as a logical, it's the same way we have a logical system.

A storage system is really an extension of a system. So if your system is actually comprised of an off-the-shelf server, it would be basically identical to that system, basically have exactly the same properties with just an additional parameter that says, I'm running storage. There's literally one property different. It basically inherits from a system. If it's a controller, like an array controller or something like that with some custom ASICs

or something like that in it, it might have some additional properties in there. But that's the kind of thing that this would be modeling. And then the bulk of the rest of the information is actually up in the storage system. So the storage system is where you have your class of service, your volumes, your files, your replicas, your storage pools, all of the things that your clients and your usage is actually going to care about from a day-to-day perspective. Storage systems, the chassis, the managers and everything

is from your diagnostics, maintenance, all that kind of perspective. But someone coming along like cloud usage or VMware infrastructure, anybody managing that level, it could stay entirely only ever talking to your storage services. Okay, so what would a storage implementation or a storage implementation ever look like? Let me take you down into some of the tools we're developing that you can actually go out and look at right now to see what that would look like? Let me take you down into some of the tools we're developing that you can actually go out and look at right now

to see what they would look like. Again, so John talked about this. One of the tools that Redfish has been using and Swordfish is using as well are mock-ups. So we're using these mock-up tools. They look like snapshots of a state in time of different types of systems. So we have several that we published as well that you can actually go look at and say, hmm, what would a small system look like?

What would this type of system look like? What would a file system look like? Do not treat these as normative. Do not treat them as anything other than, this is kind of an example. But we have a site set up called swordfishmockups.com and you can actually go just navigate your way around on that site and look and see at some ideas of what the system might look like, what some different types of systems might look like. So we have three or four different systems out there right now that you can just kind of get an idea of what systems might look like.

And again, these are all static. They're not going to respond to anything. You're not really going to be able to configure them. And I'll talk more about some other things we're developing that will get set up that will give you more flexibility in the future to actually play with things. But I'll walk you through here in a sec what the systems actually look like.

And then you can use this site later to go play around with. Okay. Okay. So the... This... So we want to talk about... How am I going to talk? Okay. So if we want to talk about maybe looking at exploring the Swordfish data model a little bit to see what a system might look like.

What I've done here, and if you're in the back of the room, I'm sorry, you're really not going to be able to read that very well, so kudos to the guys sitting in the front what you can actually do though is this is the same information that's out on that Swordfish mock-up site but what you can actually do is just kind of navigate through the model and see some of those same hierarchies that we just talked about but let me walk you through a couple of just examples of some different things you

might actually want to do. So I mentioned that we're very use case centric as we developed and very client centric as we developed Swordfish, right? We didn't really take the previous approach of saying, well, here's every possible function that every vendor has. Let's throw them all in there. What we did was we basically said, you know, here's a bunch of use cases that the clients actually want to do, so let's focus on instrumenting those instead. So there's not necessarily everything you might possibly think of.

It's what do the clients that are involved in the process actually want to do. But I'll walk you through a couple, you know, a use case or two here. I might only have one in here. They're getting a lot of slides, so I think I might have cut it down to one. But we'll walk through at least one to kind of give you an idea of how to navigate the system. So there are a couple of different mock-ups here. So typical REST hierarchy, what you do is we kind of said, you might be sitting here first thinking, well, geez, I don't know how the system's organized.

Well, that's kind of the nice thing about REST. Unlike SMIS, you don't actually need to know how the system's organized to go navigate your way through. We can just start clicking our way around and understand the details and learn. So what we do is we start at the top. We navigate it into the system. So we selected the Redfish V1 and then clicked on the storage services link to go navigate down. So then we said, okay, well, let's go look down through. There's three different systems here,

so this would be how you would go down and see the details of any one of the three, right? So what do we want to do? Well, let's just get a quick overview of what's in these different systems. So in a block service, you can see a bunch of these different components that we've talked about.

There's class of service. And if you dig down into those, classes of service are comprised of lines of service. So if we go look at a class of service, you'll see how those are built out of different lines of service. And there's five different types of lines of service that you can build from.

And then there's volumes, and there's five different types of lines of service that you can build from. And then there's volumes and there's storage pools and there's storage groups and endpoints and all these different structures in here. So we can go navigate around and just look and see the details for each one of those kinds of systems. So what's a file system look like then? So a file system basically says, well, it's pretty much exactly the same except now there's file system, you know, there's a file system construct in there. You go into that and then you'll see the file shares. Other than that, it's roughly identical.

Okay, so let's discover something. Let's see if I have space to... Well, let's see. What's one of the most common things I want to do? I want to allocate storage. So let's go see if I can navigate down in one of these systems and if there's enough capacity to create a volume. Well, I create volumes out of storage pools, right? So let's go find a pool on one of these systems and see if there's enough space to allocate a volume.

So we'll navigate down and – So we – well, that's weird. I apologize. Okay, so we – there's a slide missing here. Sorry. So we've navigated down in, sorry, there's a slide missing here. But we basically can navigate down into a storage pool off of, if I back up here one, if I go down into block here, so from off of this storage system, I can see over here there's a storage pool. Yes, so I can see these storage pools.

I navigate down into here on the slide that's missing. Go down into there, I can see a couple of storage pools. And then as I navigate forward into here, I can see I go down into this storage pool, and I can see, well, look, yes, there's capacity here, so I can actually go say I can use this pool to create a volume and so I'm checking its remaining capacity by looking at the capacity structure here

to say yep, there's the consumed capacity versus allocated capacity there's space left I can go capacity. There's space left. I can go create a volume out of this one. So just navigating around, going down that structure. I apologize for the one missing slide there. I can go check and see that there is enough capacity.

That's just one way to go look around and see just one particular system that I might want to go, or one thing that I might want to go do with that system. And just real quickly, not knowing anything about how anything was structured in that, I could just navigate around and find some useful information. Okay. So what else is going on? So we mentioned kind of, I mentioned that we're kind of adding a bunch of incremental information and we're looking at adding functionality. We're starting to see some implementations happening this year. About every three-ish months, two to three months, we've been releasing updates. So you can see January, May.

We've been trying to get a release out in this month, next month. That's just to clean up based on some of the implementations. So we started having some implementations and feedback from those implementations in June. We've got some plug fest. I'll talk about those in a slight on that, I think, next. But what we're starting to see is some feedback that basically says, how about a little bit of cleanup here? Maybe we could simplify some stuff here.

So that's kind of some of the kind of stuff we're seeing in this release. So we pushed it out a little bit so it can wait, get a little bit of cleanup there. But what we like to do is have releases every three to four months, not huge releases. We're not trying to drive a lot of functionality in. What we're trying to do is, you know, there's a lot of focus on, you can see, supplemental materials here. You know, we've got, you know, spec. There we go, some spec additions and some of the supplemental documentation as well.

So some of the other stuff that we're starting to do in parallel is look at flushing out some portions of the models that aren't there yet, some schemas that aren't there yet. We've got, and again, John talked about, you know, we've got the PCIE and NVMe over fabric that models that folks are starting to become very interested in. What we're looking at also doing is going back in and ensuring that some of the areas like the converged network adapters models get completed and looking at what are we likely to need in the fiber channel fabric space.

So there's that yang work that's happening over in redfish but um folks are looking to snea to say what are you doing from a fiber channel fabric perspective um so we're looking at things like how much of that work needs to be complete what are people going to actually be looking at from an end-to-end model tying the swordfish models out to that. And so as we do yang conversions of fiber channel, does it really need to be super complete, or should it just be like monitoring high-level information? Again, kind of going back to what I was talking about a little bit earlier. What are the use cases for it?

Because we don't need to have a super complete, you know, really, really detailed implementation with lots and lots of controls on it if nobody's going to use it. So what are those use cases? And then we can flush that out and make sure that we have, you know, the sufficient level of detail for who's going to be using it and who wants to use it. But we also have some holes that we have, you know, plugging everything in end-to-end. And we want to make sure those are covered. So that's kind of when we talk about the fiber channel model, that's what we're talking about is, you know, kind of plugging everything in end-to-end. We have some future things here, object storage, storage-specific security roles.

Right now we haven't had, we've had a lot of interest in object storage, but we haven't had anybody sign up to actually do that work. The security user roles is another one where we think we need to have the implementations further along before anybody's going to step up and say, this is what we really need here. So those are ones that get down on the list.

So, you know, we don't want to forget about them, but we just don't think we haven't needed to do the work yet. Okay, so I talked about some supporting materials. One of the things that we've added and made available starting this year, starting this summer, actually, is what we call the practical guide. In the past, we've looked at doing, for other standards,

we've looked at doing things for implementation guides. One of the issues with implementation guides is they tend to be done very, very late once there's a lot of implementations. And what we decided to do with Swordfish was actually roll out what we call the practical guide, which is, it's not a spec, it's not a user's guide,

it's an amalgamation, you don't get to use that word very often, an amalgamation of a whole bunch of content in a bunch of different sources targeted at kind of every different type of consumer from, you know, implementers to folks looking for general information, whether you're implementing a client or, you know or provider side. It's introductory material, advanced material, just little bits of information all over the place that we can put together. And as someone's got a question, as we figure out a new way of doing things, we put little tiny bits of information all together in one spot.

And we can grow it kind of organically. And so we don't have to kind of wait to be really, really experienced to put the material together. So I would encourage folks to take a look at that. If you have content to submit, if you have questions about it, we put this out. It's, again, available at snea.org slash swordfish. There's a link to the practical guide. It's got links to, should have links to pretty much every piece of content we have about swordfish and also a whole

bunch of links to stuff about redfish because every piece of information about redfish also applies to swordfish. And so those are that's that you know online resources that should be you know if you resources that should be, you know, if you want to have any questions about that, go use those. Go check that out. We've also started similarly to, you know, and there's links to the Swordfish School within the practical guide, but we've also started putting together some short little videos available on the SNEA YouTube channel

that explain some of the more complicated swordfish concepts. Again, relatively short videos, but things that help kind of break down swordfish for you. And so we've started putting some of those out on the YouTube channel. And then some other material that's coming. There's a bunch of marketing materials to help raise awareness of swordfish and things like that that we're working on. Let's see. Ah, yes. We're also working on and we'll be rolling out this fall

a bunch of SNEA-sponsored open source projects. And we're very excited about these. We think these will be something that will really help advance folks' understanding and ability to deploy Swordfish. So a couple of those, the Swordfish emulator extensions. This is not starting a Swordfish emulator from scratch. Again, we leverage the Redfish emulator and just add the Swordfish pieces on top of it. So you take the open source Redfish emulator from DMTF and then come over and take the Swordfish open source emulator pieces, drop them in on top of that to build the Swordfish emulator. And so we use this for a couple of different pieces,

reasons, one of which is, you know, then you can have an emulator. So unlike the mock-ups, it'll actually respond to posts and patches and puts and things like that. And it'll be somewhat interactive, but it also is a tool that we in the Twig can use to kind of try out some concepts and see how things work. But again, that's all open source, so people can take that and contribute to it or, you know, whatever. Next one on the client side is a basic Swordfish web client.

It also works against Redfish implementations. This one is, sure, Swordfish is all web-based, but navigating around through Rust can get a little tedious, or dealing with Python or whatever. So this is actually just a simplification of I can bring up a web plan, I can give it an IP address, username, password, if it's got it, and I can talk to anything that any Redfish service or Swordfish service and navigate my way down through. It will compare it to the schema, and if it's supposed to be able to read and write,

it will give you the option of being able to read and write that property and allow you to configure, you know, the portions of the schema that are supposed to be able to configure. So it's just a really nice basic, and it sorts the information for you in a couple of different ways. But just a, you know, nice simple way to give a presentation, a web-based presentation of the data for you. We also are supporting the development of a couple of different sample integrations

into some data center management environments. One is Power BI and another is Datadog. And so what we've done here, and these should be roughly equivalent functionality, but we have some thresholds and things that are built into the Swordfish API. And so we've built some sample integrations that will basically let anyone pick them up

and use them as a starting point for how to, you know, both here's how you integrate into Power BI, but also here's how, you know, here's how you integrate Swordfish into this environment. And you may or may not be interested in that specific integration, but it's a starting point, right? So you can, you know, use those as a starting point. You can use those as an example. But it should give anybody who's using those platforms, you know,

a leg up on how to interact with Swordfish systems. And then I talked about implementation support. We've been having plug fests. This has been a key driver of ours all year. We want to get those implementations going. We want to validate that what we've done in the spec is correct, that it's not too complicated, that we've got the right set of functionality in there,

all of those kinds of fun things. So we started a plug fest in June. There's actually been a plug fest every month since then, including one this week here. We have been working to keep these initial ones actually open to everyone. And so we've actually have, we have one company that's actually got a public implementation, public integration out there that's open and blogging about it. It's a company called Starwind. They are not even a SNEA member. We basically talked to them last year at Ignite about Swordfish,

and they said, oh, this is neat, wandered off. A few months later, we heard back from them, and they said oh this is neat wandered off a few months later we heard back from them and they're like we built one look um so so and there's a blog about it you can actually go google it and and um they've you know that they've been they've been blogging about it and talking about it um and then we have several, you know, six companies, I think, that have been participating in our plug vests for the last several months. And so we have multiple

implementations that folks are working on to proof of concept, some actual implementations. And since nobody else has announced, that's pretty much all I can say about those. But it's actually, you know actually quite a bit of work. I've been really, really pleased with how little we've had to turn on the SPAC based on the initial implementations. I mean, we've actually had some really good feedback on,

hey, you can simplify this here, you can simplify this here, but there hasn't been a lot of, wow, this is completely wrong. It's actually been, you know, pretty solid so far. So we'll see how things keep going, but we've been very pleased with the progress so far. Okay. So how to participate. We're wrapping up here.

Let's see. So this first URL might start, am I repeating myself enough? Sneha.org slash swordfish. You will find a couple of different places on the SNEA website. The latest, the second one is a standard, snea.org slash public review is where you will find all of the latest technical, everything that's publicly available. We have a link to that on snea.org slash swordfish. If you're interested in joining the TWIG, if you're already a SNEA member,

we would encourage you to join. We would love to have you. If you are not already a SNEA member and are interested, we have several people around the conference. We'd be happy to talk to you about that. And if you have additional information, there's two different places to come to. One is the snea.org slash feedback portal. We also have a community forum

that we'd love to have you provide input on. You can get to it at redfishforums.com or swordfishforums.com. We have an alias that will point you to the exact same place. So that's basically how you provide input. That information, again, is at snea.org slash swordfish.

So you don't even have to remember swordfishforums.com. You can just go to snea.org slash swordfish. So you don't even have to remember swordfishforums.com. You can just go to snea.org slash swordfish. It will tell you where that portal is. I think I have, yes, I can actually stop talking now. So remember, put your business card in to win an Echo Dot tweet. So are there questions? It looks like there's a lot of kind of retrieval built into the source

is there automation as well so that you can do actions based on the data you retrieve? Yeah, it's a full Rust interface so there's full crud so everything you would expect to see in a management interface, right?

So everything I showed here, you know, you kind of see all the gets, but you have full active management, basically. We have a few things that are explicit actions, like resets that don't fit someplace else that you'll actually see called out as an explicit action, but everything else is just kind of implicitly built in. So if you want to create volumes, create pools, all of that kind of stuff is in there.

There's event notification, task management for long-running tasks. So all of those things were in that initial little blurb that I had under services or firmware updates, all of the things you would expect to see in a management API. If you have any specific, you know, questions about if something's specifically in there, you can ask, and I can, you know, kind of show you where those are. Was there other questions? Or, sorry, Dan, I need to repeat the question, by the way. It was...

Okay, next question? Yes. These are not available yet. They will be available over the next couple of months. To find them, you can go to, and we have a couple of the GitHub open repositories already published. These will be on github.com slash SNIA. So the repository already exists for these first two. I will be creating the ones for these.

The Datadog repositories typically get published onto Datadog. Due to SNIA policies, I will have to put a copy here and then also copy it over to Datadog. So it will end up being in both places. But you can find, and then we'll put documentation here that says it's also over there. But the other ones will all be published at github.com slash sneha. Are they going to be a Redfish site for all of their open source stuff is github.com slash dmtf. And the emulator will also have that information

because the instructions for getting the emulator are go to github.com slash dmtf slash redfish emulator and install that. So any other questions? All right. 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 storage developer community. For additional information about the Storage Developer Conference, visit www.storagedeveloper.org.