Storage Developer Conference - #88: Swimming With SNIA Swordfish

Episode Date: March 11, 2019

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 88. So I'm Rochelle Alvers. I am the chair of the Scalable Storage Management Technical Workgroup for SNEA, which produces the SNEA Swordfish specification. So I'm going to be talking about Swordfish. For all of those that were in here for Redfish, you've already got a precursor to a bunch of this.

And this actually, standard disclaimer slide, the key thing on here to note is the smea.org slash swordfish. I will repeat this several times. If you take away nothing else and remember nothing else from the presentations, you can find everything about, including links to these presentations, although they'll be on the SDC site. But all of the information about swordfish that we develop is on smea.org slash swordfish. So what we'll be talking about today is basically, you know, kind of an overview of what swordfish is.

How it extends Redfish. So Jeff talked about what Redfish is, kind of its etymology a bit. We'll also talk about kind of where it came from, what some of the primary drivers are for Swordfish. And then what's the functionality that's included? And then a couple of the use cases

and how you might actually integrate and use Swordfish. In the next session we'll go into a bit more detail on a few things. Diving down into one of our key pieces of functionality and down

into the schema and some of the key pieces of functionality down into the schema and some of the new pieces coming. So we kind of keep this one a little bit more high level and then in the next session go into quite a bit more detail. Okay. So, you know, how did Swordfish come about? Actually, before I start, how many folks have seen or presentations about Swordfish before?

All right. Okay. Okay. So where SNEA kind of came from is we looked at, this is quite a bit different from previous storage management APIs, standard APIs. The previous standards were actually really all developed from a bunch of vendors getting together in a room and saying, here's what we have.

Let's standardize this. And then presenting it to the clients and saying, okay, here you go. And so when we worked on developing Swordfish, and Redfish had taken this tack as well, is what we really wanted to do this time was actually be a lot more client-centered. So we did not really want to just say, here's every possible feature and function available in a storage device and just present that. And so you actually won't find

every possible available attribute of a storage system in Swordfish unless there is a very specific use case by clients or multiple clients that need access to it. And so I highlight that because it actually helps you to keep Swordfish a little bit simpler, quite a bit lighter, but it's also our very client-centric approach to developing the API. And so the next major thing is actually utilizing a client service or a service-based model on service-level-based provisioning, management, and monitoring. And so this is also very different. So this is not a resource-based model,

resource-based provision. This is a class-of-service-based model. We cover block file and object. We have block-of-file-based implemented and have for a while. We haven't had anyone step up to really flush out the object model, but it's there.

It should be very straightforward to do. This doesn't cover every possible permutation of storage device at this point, because we haven't had clients step up and say, I really need tape libraries. So they're not there. So the other, kind of one of the other major drivers here is existing standards have been very focused on a couple of primary domains for storage.

They have been focused on external storage and SANs, and as they applied them to DAS. Well, as I'm sure you're all aware, the storage market has shifted radically over the last few years. We now have cloud, we have hyperconverged, we have converged, we have hyperscale. And so what we wanted to do was actually build a standard that we could take, you know, a lot of the storage infrastructure is largely the same

to deliver into those markets. What we wanted to do was actually build a standard that we could apply to all of those markets as well. These are really a lot of the drivers that we used to develop Swordfish. Then how we did that was we looked around a couple years ago and said, okay, what's out there? Let's try not to do this all from scratch because that would be silly. Redfish was out there. You already heard all the drivers for that, you know, replace IPMI.

But they were already looking at a bunch of stuff. And as you're all also familiar with, storage is not built from largely different components than servers are. So let's just work on the unique stuff. So we implement storage as an extension to the Redfish API. We don't worry about the protocol stuff

because they've got that covered. We just focus on the bits and pieces of it that are unique and value-add for the storage domain. So all that stuff that Jeff said earlier about protocols, no data and stuff, yep, do that. And we focus exclusively on what's the storage functionality and how do we apply functionality and define functionality and extend that for the storage domain. And anything that's defined in Redfish from a protocol perspective, from a schema perspective,

all of that, we just pick up and adopt. So who's working on this stuff? The red bubble is Redfish. The purple bubble is Purple for Sneha. So the most interesting part, though, is the overlapping companies. And this is kind of the current as of today. These bubbles and the companies in them have shifted quite a bit over time. But this is kind of the current overlap but we we find this to be a really interesting thing just

to throw up here because it kind of gives you a sense of both the number of companies that are involved at any given point but also how many companies are working on both. So I think one of the ones to highlight in here, you know, Texas Tech University folks might look at that and go, that seems like a weird one, but as Jeff pointed out earlier, they're doing a bunch of research in large-scale, scale-out stuff, and they're actually working with both storage and servers in in scale out compute and scale out storage stuff so okay so Jeff showed a variant of this earlier but one of the things I wanted to start with is like we keep talking about swordfish as an extension. So what do we mean by that? And so let's start with,

you know, Redfish is a basic compute. Jeff showed a variant of this earlier, but this is how the Redfish service route is organized. So the service route is basically the slash Redfish slash V1, we call that the service route. And so there's a slash V1. We call that the service route. And so there's a bunch of miscellaneous things that show up over there that are just the schemas, the sessions, the accounts, events, registries, tasks. You'll find a collection of stuff that's just dumped there. But for a basic compute system, it's broken into three major categories. There's the systems, which is kind of the logical view of a server, a chassis, and a manager, which the chassis is, think of that as where you put the physical view of a system. And the manager in the server case is kind of the BMC for the most part.

You know, it's the management hierarchy. And so if you think about how you build up storage systems, in some cases those things are leveraged completely. In some cases components of them or logical versions of them are leveraged. But they're very similar. So when we go to add storage to that model, there's actually two different ways that we model this. But where we focus on adding Swordfish is adding what we call storage services, which is really the logical view of your storage. And then we have two different ways to connect that view into all of that,

the redfish portions that we leverage. So the purple part at the top, purple again for color coded in here for Swordfish and for SIA, the storage service is really where you put all of your logical storage entities, the things that you expect to see, your storage pools, your volumes, your file systems, other things that you might expect to see, like storage groups, endpoints. And I talked about this notion of, you know, this service-based system, which we call class of service. So you see all of those inside your storage service. A system can have one or many storage surfaces. So what a collection is over here is really just an array for oversimplification.

It's an array of entities anytime you see a collection. That's a multiple set of objects. So a collection resource and then a single resource, that's just the notation throughout the system. And then we have two different models that we use to say, to describe basically two different kinds of configurations of a swordfish system. So we have what we call the hosted surface configuration.

And so then we have these two other different entities besides the storage services, one of which is where we basically just entirely use that system model. Oops, sorry. And so we have what we call a storage system. And a storage system really is just an instance of a computer system. And so this is a very common deployment model for a Swordfish configuration. So this would be, you know, external storage, an SDS configuration, you know, anything like that, where you basically just instantiate. This is the thing that basically hosts your storage system or your storage service.

So an external storage controller would be modeled as a storage system or an SDS a computer a physical computer that's an SDS configuration that's hosting a storage service. It literally is identical to a server because it is a server. You just model as a storage system.

And so it actually instantiates into the slash systems as well as showing up in the storage systems. So this little quad of boxes here actually shows that a computer system is actually also a system. It shows up in both collections. So this allows you to basically represent your controller or your storage system, you know, using all of those same elements that are in a computer system. Processors, memory, simple storage, you know. like Jeff showed earlier. This would be a direct-attached disk that's hosting some local storage for that controller.

You would have a simple storage. Any of that configuration could be used there. If it happened to have a fiber channel instead of an Ethernet interface, you could substitute that out. So all of that could be used to model your controller. So that's pretty much what that model looks like. We have a second model,

and I'll talk about this one in more detail in the next session as well. But this one we call the integrated service configuration. This one actually takes, and if you've got more of a direct-attached configuration where you have, and you might be leveraging off of a, that storage and storage controller configuration, if you have like a RAID card

that's instantiating a storage service. So you can actually, you don't instantiate off of the computer system itself. It's not the entire system that's instantiating. You actually just link the storage service off of the storage and storage controller itself. So there's really two different models. One is the entire computer system

is the host for the storage system. The other one is you have a storage controller inside a computer system that's a host for the storage service. And so it really just depends on how the system is constructed okay so so talking a little bit more about the storage services that's that's the uh swordfish capabilities um you know what what all functionality is included. We have block storage, pretty much everything you'd expect to be there.

And we've kind of had most of this from day one. We have provisioning with class and service controls. We have... One of the things to note here is this is not... We have resource provisioning from disk volumes, storage pools, hierarchies of pools, pools from pools, volumes from volumes, volumes from pools, and persistent memory, right? The model has actually been included to allow the, you know, storage pools to be created

from persistent memory and memory chunks. And so as the persistent memory implementations start to roll out, we've pre-enabled everything for Swordfish. So volume mapping and masking, obviously, local and remote replication, capacity and health metrics. We have performance metrics for all of those types of objects,

for volumes pools, storage services, all the levels in the system. We have a standard performance metric object that will be consistent across every type of object. So again, from that client perspective that I talked about earlier, you get a single metrics object for performance that is consistent across every object type.

File system. So we have two file systems objects. The file system model is not radically different. It basically builds on top of the block object. Everything is exactly the same except for the two objects, file system and file share. And so it works exactly the same, provisioning with class of service, replication, everything.

The only two unique objects from the rest of the system are file systems and file shares. And then we're working on adding in all of the solution-level connectivity, so Fabric Connect, Host Connect. And so you basically can put an end-to-end model together from servers to storage to fabric and have a complete implementation. So one of the things that helps enable that is we have a Redfish fabric model that includes SAS and SATA, and we're working on adding a complete fabric model.

The initial for Fiber Channel is basically a read-only implementation just to kind of provide a lot of backward compatibility if someone wants to provide a Redfish, Swordfish fiber channel model. We don't expect a lot of implementations to show active controls on that because of their existing implementations, but if they want to have a complete end-to-end model, they can have that. Again, it's kind of client-driven because we don't see folks asking for complete conversions in their tools. Endpoint abstraction is another thing that falls into this category.

Rather than just exposing a port level, we have this notion of an endpoint, which is an abstraction on top of ports that describes the connectivity. And then we also have support for object drives that plug in pervasively through any place you have a drive, you have the ability to have object drives and are supported consistently through the model. Okay. So a little bit through, I should speed up a little bit here. Going through the Swordfish model,

these are some of the primary Swordfish elements. We have, we've talked about class of service, and I think I've kind of already done the definitions of most of these, so I will just kind of skim over them. But again, some of the key new elements are class of service, and we've already talked about the storage service abstraction.

The rest of these are all things that should be familiar from management constructs. They're all leveraged forward. The only other one I think I haven't mentioned is the storage group. This is really just a set of volumes that are managed as a group that you can use to do mapping and masking. Or basically, we have a few other things that we will use, other functions that you can use to deal with a set of volumes as a group.

Okay, so how do you... I have a couple of examples here coming up. And what I really wanted to kind of do was just kind of expose to how you might want to deal with using, kind of using Swordfish. So one of the things to look at is you don't really have to have any view of the schema in order to use the system. Obviously, it's a REST-based interface. So how do I go find volume, capacity, information? What does that look like?

We'll just wander through the system a little bit, read the service route, go find a storage service, find a volume collection, pick a volume, and go look at the capacity information. And then there's a relatively complex capacity structure information, but all we actually need to do is compare the consumed versus allocated. I have not yet mentioned, but I'll have a section at the end where I show a bunch of our resource information. We have a bunch of mock-ups of these different configurations

on swordfishmockups.com, and so I'll show a little bit of that in a minute, but all of this data we show here is available online at our static site on swordfishmockups.com. So, you know, going through and looking at the service route, get command at the top here is not necessarily called out explicitly. Just do a plain get. You can do this through scripting. You can do it through plugins in your browser that will hide all of that complexity for you. But go down through and, again, your storage systems, find the storage services, and then navigate down.

You'll get the list of the storage services. Our mock-up system will have quite a few systems. In a real system, it kind of depends on the scale of the system. You might just have one storage service. That would be very typical for an implementation, to only have one storage service. That would be very typical for an implementation to only have one storage service. And then we navigate down inside that and find the volumes, select the volume member, and then go down. Now your volumes, you're highly likely to have a lot of volumes. So here we're just picking, you know, find a volume and then navigate down.

So we look at going through. There's a fair amount of various properties. The capacity structure can have a lot of data, metadata, and snapshot data, depending on your implementation. The primary data is likely to be instrumented. The metadata and snapshot would likely be only if you're in a more complex configuration that actually supports replication. You'd see those properties filled out. But here what we're really just looking for is, hey, you know, what's the capacity information? So we're looking at, you know, what's the allocated versus consumed? And so, you know, there's the information.

So we just navigated down through here not knowing anything about the schema or the configuration. Is there a question back here? Yeah, if I may. Those numbers are real-time light numbers. Can I rely on those numbers? If I plan to have a kind of a middle there on top of this, and I really, I would depend on those numbers if I plan to have a middle there on top of this I would depend on those numbers so for example

the guaranteed rights would that be right now what's guaranteed right now or is that cash 10 minutes or something okay so just repeating for the recording the question is are these real time data and can I rely on them? And that is

absolutely implementation dependent. So if the implementation supports these properties, you can rely on that data. So if an implementation cannot propagate consumed bytes because that would be a feature that is hidden by the OS, it shouldn't instrument those and just wouldn't populate that field for you. Yes? Yes. Yeah, so the question is, the schema does not necessarily show optional versus mandatory properties at this level.

And what we're doing for some of, and yes, that is correct, the schema will not show at this level. So there's a couple of things that we're doing for some of, and yes, that is correct, the schema will not show at this level. So there's a couple of things that we're developing to help provide guidance there, one of which is what we call a practical guide because we didn't really want to call it an implementer's guide because we expect it to be, we have information in there that's useful for people at all stages of information gathering, whether it's learning about or clients or provider developers or whatever. So it took us a while to come up with a name for it.

But what we'll be doing is developing a range of guidance. So it's not necessarily just a spec or schema thing. It's what makes sense in what circumstance. So there are multiple places to go to get information on whether a property should be implemented. There's a very small number of things that are required at any given point. So you'll be looking at a combination of what's required in the schema, what's required in the spec, and what's required in a profile. And so I'll be talking more about the profile development in the next section. But the

profiles are something we're developing as, you know, a list of here's the supported features, here's what's required in the profile. But even at this level, you know, this, you know, subproperty, you know, the subproperty of a property, that's also going to be fairly implementation-specific. So what we'd expect to do is, at this level, almost either develop implementation guidance and videos and documentation that's not normative to say, this is what you might expect to see in a particular circumstance. Like what I just said on, you know,

if an implementation can't give you consumed information, it won't be propagated. It won't be populated. You know, in a lot of configurations, the driver just won't tell the device that information, or they don't have an API to it. They can't populate that information. So we're looking at different ways for how to make that information clear to both the clients and the providers and the developers on both sides. But we have a bunch of different ways to specify both what implementation should develop and how to make that information clear to the clients.

So some of it will be on us as, you specifications, writing the standards, and some of that will also go back to the implementers developing, anyone developing their implementations. So is there a standard saying that these are the minor things that the implementer has to implement and that there are certain optional stuff? Yeah, so there will be, like I said, there will be multiple ways that we specify that. And so there will also be multiple ways. So the question was basically we will be specifying, was around, again, clarifying how we will be specifying when and where we... Go ahead, George.

Just take a quick shot at that. But, George, we have a microphone recording thing, so I think the only mic is up here if you want to... Sorry. Sorry. Sure. Folks, this is George Erickson. He's a member of our technical work group. So as Rochelle mentioned, if you don't get, say, consumed bites back in your payload,

then it's not implemented. Forget about it. That's one way you can tell. But the principal thing that we're developing is along the line of profiles, which you'll be able to discover in the model what profiles are or are not supported. The profile will then give you a set of properties and actions that you can rely on as an implementer, as a client. Okay.

So let's see. So I talked about these earlier, and the – let's see, how am I doing on time? Okay. let's see how am I doing on time okay we've still got time for a few more questions at the end at this rate I mentioned this earlier I'll also remind us if you don't keep track of this there's a link at smea.org

slash swordfish so remember that URL swordfishmockups.com slash redfish slash V1. If you've got your laptops up, you can actually go point there now. There's also tools out there that will help you with different ways to access the mockups and help with accessing swordfish and redfish systems in general. We have a bunch of different mock-ups out here that actually show, and I apologize that the screenshots are really small here.

One of the guidance we have for this forum is I can't actually toggle over and show you the mock-ups. I have to do everything via slides. So for those of you sitting in the back, you should have sat in the front. These are just screenshots of me navigating around through the mock-up site. But what you actually see here are just, you know, the information that's actually out on the mock-up site. But what we actually have out there are a bunch of these different permutations and configurations that I've actually talked about already. So what we actually have out here, so you can go get an idea of what some of the different,

some example configurations. And I will also point out, I've done a ton of cleanup on these configurations in the last few months, but do not treat them as normative. They are still just informative systems, although we've gotten them a lot better. But you can actually go see examples of a snapshot of what a small external array might look like. We've got one that we call complex. I think in some places we call it complex and other places, I think that I'm not sure that the name sticks all the way

through. Again, informative, not normative. But it's kind of got all of the elements in that HSC model that I talked about. So you can go see classes of service and lines of service and the capabilities that comprise all of that. It's got remote replication. It's got kind of everything, every element of the system in there. It's got file systems. We've got a file system model that sits on top of a block model.

You can kind of see every possible permutation. The other thing that there's out there, there's one of those ISC configurations. And so the ISC configuration extends, sits on top of, and builds volumes off of a RAID controller in a direct attach server. And that one's actually fairly true to life because I modeled it off of one of my systems. So that one's, there's one of those out there that you can kind of do a compare and contrast

of what those different configurations look like. So there's a bunch of different things to go, you can go look at in our mock-ups. It's not really structured the same way the Redfish one is. This is one that's just got everything kind of all plugged together in the same service route. When I get some time, I may go break everything out into different configurations so you can kind of see them all separately. But I was really happy just to get them all completely cleaned up. So,

again, you know, navigating through the mock-ups, just like we just looked at, you can go to the storage services link, and simple shows you the simple mock-up. Storage services one is the complex mock-up. File services, ISC, just takes you through the different configurations. What you'll see going through is all of those different structures we just talked about.

And the only difference you'll see going between the block and the file view is, just to highlight this point, I made it earlier, and I'm going to highlight it again. The only difference you see between those two structures, between the block and the file, is the addition of the file systems collection between the block and the file. Okay, so what else are we working on, on adding to Swordfish? We introduced the V106 in February.

It was approved as a technical position. That's SNEA terminology for standard in May. That's when we introduced the two models. And then cleaned up the mock-ups just recently. We'll have another release coming out soon, sometime this quarter, that adds a bunch of enhanced class of service capabilities for spare management. This is an area that was not very clear, so we've added a bunch of enhancements around that and some new structures around that. We've also got a white paper that's coming out

that talks about how to do spare management consistently and how to use those structures. Yes, ma'am. So far, what I see is it's mostly like can you provision inside the system or like creation or post or put, delete? Is it more than a get and a post? Yes, this is full management.

Full management. Yes. Yeah. The mock-ups you'll only see gets because they're all static. We actually have some tools that will let you do interactive. We have an emulator that will let you do work with an emulated environment. Don has a session that will talk about the tools this afternoon. But you can do interactive puts, post-patches, all of that with an emulated system.

Some of the other stuff we're looking at adding, right now the infrastructure has admin roles that we leverage from Redfish, and we've gotten quite a few requests to enhance those to storage admin roles. So we've been working with the Redfish Forum to enhance the infrastructure to support that. So the infrastructure has been beefed up, and now we need to go back and add the storage admin roles. The profiles, we've talked a little bit about those, and I'll go in more detail in those in the next hour. I keep looking at my watch to figure out where we are in the time.

But we'll talk more about exactly what's happening with profiles. And then another area we've got working is some alignment across DMTF, NBME-MI, and SNEA. So there's another protocol that's being developed for the management of NBME devices in the NBME Express Forum. And so taking some of the work that's going on in that RDE space that Jeff talked about earlier, we're working on trying to develop a next-gen alignment between Swordfish, RDE, and NVM-EMI so that we can reduce the number of standards protocols, particularly around the SSD drives in the next gen, and collapse down, make it so that NVMe MI can use the RDE transport and have Redfish and swordfish schema to manage NBME drives and leverage those transports

rather than having a completely separate protocol and data model. Sashen. There was some conversation through some other channels, like the pinkfish, and they're trying to do more of a de-aggregated sort of classes and classifications. Is that something even kind of absorbed into this piece or? They have their methodology, I guess, just because of all the chains and containers and all, but is there some ability to kind of absorb all that? So the question was about Kingfish.

Kingfish at this point is a single vendor proposal and does not leverage Redfish and Swordfish. We're talking to them about potentials moving forward, but at this point it is independent. As Jeff talked earlier, there's already multiple composability solutions within Redfish so and then

object storage as I mentioned earlier should be an easy extension as soon as we have someone to step up and actually build those models so some of the resources available I've mentioned half of these already So some of the resources available. I've mentioned half of these already, so I'm not going to read the list to you. We work primarily out of GitHub for all of our development. We also have a set of open source tools that Don will talk about later that include Emulator, an open source web client.

So anybody who wants to work with Redfish or Swordfish and is looking for just an easy way to navigate around, it's really easy to build and gives you a nice GUI to just navigate through. It's not incredibly complex, but it just gives you a really nice, really easy way to just bring up and work through the systems. I've already talked about the mock-ups. We have white papers. We have a ton of webcasts from both events like this podcast and things that are available on for reference. We do multiple webcasts a year and all of those are available as well. And we have also a series of YouTube videos that cover different swordfish concepts. So if you have specifics about or specific questions about different concepts,

you might just go check and see if there's a YouTube video that covers that. So those are, I just mentioned all of the open source tools. The other two, we have some sample integrations for clients to kind of show what, you know, what a client might actually use Redfish or use Swordfish for. So we took a couple of enterprise management infrastructures and developed sample clients for them. So the documentation out there also shows screenshots of what it might look like. So if you're just interested in that, just to say how could I integrate Swordfish

from a client perspective, both Datadog and Power BI are available. Or if you use them or have customers that use them, they're both available out there. And I've already mentioned all of these. And then lastly, how to participate. Obviously, CNA.org is less Swordfish. But if you're more interested in actually helping to engage with the standard we have multiple ways

to do that join snea, join the twig provide direct input or just provide if you've been working and have direct questions work with us through the snea feedback portal or through the swordfish Forum that Jeff mentioned earlier.

And swordfishforum.com, redfishforum.com, both get you to the same place. And again, we have the BOF tonight and the workshop tomorrow. So go to one or both, and we'll be digging into more questions on anything from who's actually adopting, who's actually working on this stuff, and who's working on integration, any questions you have on that. And then the workshop, go play with the tools,

see what the vendors are doing. Okay, other questions? Yes, sir. Can I just say one more thing? Please support that regulation. I'm sorry, can you speak up a little bit? Right, the mockups are static. Emulators, yes, emulator supports,

it supports patch and put, and and post and delete. Yeah, it supports everything. The one thing about the emulator is that it doesn't have any rules behind it for enforcing behaviors. So it's just going to do whatever you ask it to do right now. We've got some enhancement issues and enhancement requests out for somebody to go along and actually put in, you know, some functionality at some point

to say when you do this, a real system would, you know, do X, Y, Z, but that doesn't exist right now. Right now, the emulator will support it's fully dynamic and for all of the Swordfish functionality, it will support all of the rest

operations. So, our product leveraged some of the APIs like the platform So, once the storage vendors have a storage API, it would absolutely let you. Yeah, so the minute the vendors announce support, then you would be able to leverage this consistently across them. You just need to push your vendors to implement that for you. Ask them when they're going to have their Swordfish support.

Which vendors have announced support? Excellent question. Which vendors have announced support? At Flash Memory Summit, we actually had our first shipping implementation announced support, which was, unfortunately, not a SNEM member yet, but they are joining, which was a company called X10, E-X-T-E-N. And they were just coming out of stealth at that point.

And so they announced their Swordfish implementation. We do not yet have a compliance and certification program in place. We'll most likely be rolling that out this year as we start to see more implementations from Bosnia and non-Soviet members. But that's basically the first shipping implementation. So we expect to see more rolling out this year. We know of multiples POCs and other things

where folks are doing development, but that's the first thing that's been publicly announced. You mentioned that instead of trying to impose a set of rules, you're taking a back of creating Okay, so the last question. So the approach we're taking with the profiles is actually very client-driven as well. And I'll talk about this more in the next session. So this is a good lead-in, and then I'll let everybody go,

and then you can come back and hear the rest of the more detailed answer. But we're explicitly doing this, working with the features and profiles as a way to both have the products advertise what they're doing, but it's also a layered thing, because it's very difficult to put into a schema or into a spec to say you must do this and have that be something, because there's such a wide variance

in what all implementations must do at any given point because the implementations are going to vary so much and what clients want to do. So we've actually taken eight months just negotiating how we want to do profiles and features. But I'll talk more about that in the next one. But we've actually gotten a very small set, and we're basing this on eight years of experience in how SMIS did profiles. And so we've learned a lot on what not to do.

SMIS had how many profiles? It was a ridiculous number. 150? We are not doing that. Absolutely not doing that. What we've done is we've actually narrowed it down to a way that we're going to advertise features, a very small set of features, and then there'll be a larger number of profiles.

The profiles themselves are an implementation side thing. And so there's actually two different things, right? So what you're actually doing is you're advertising, I support this feature. And then a profile is a very detailed description of how you can get permission to advertise that feature. And so with that, I will stop. And thank you all. And we'll talk a little bit more about that in the next session.

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.