Storage Developer Conference - #126: Introducing the SNIA Swordfish™ PowerShell Tool Kit and Windows Admin Center Integration

Episode Date: June 2, 2020

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 STC Podcast, episode 126. Okay, welcome to Storage Developer Con 2019. Are we all excited to be here? Yay! Okay, welcome to Storage Developer Con 2019. Are we all excited to be here? Yay!

Okay, so I'm going to be co-presenting here today with Barks, who's sitting in the front row here with his hand up. And we're going to be talking to you about Windows PowerShell and specifically how that could be used to expose Swordfish functionality as well as the underpinning for writing a Windows Admin Center module so that you can actually control storage directly from a Windows machine. So you can either do it from PowerShell

or you can do it from WAC. That's the eventual goal here. Let's go ahead and jump right into it. We all know what Swordfish is, basically, right? We've done a whole day worth of sessions on Swordfish so far. And everything you learned about Python, just forget. Okay, so we're going to go over the PowerShell toolkit, and we're also going to go over some

of the integration points with Windows Admin Center. And we're also going to show you how to build the rough steps to build a Windows Admin Center gateway. Let's go ahead and jump in and give you an idea of what I'm going to talk to you about first. Because Barclay is going to come up in a few minutes and talk specifically about the Windows Admin Center integration, whereas I'm going to talk about everything leading up to that. So I'm going to talk about the PowerShell toolkit and how you can use the

PowerShell toolkit to map your Swordfish devices, your, or I'm sorry, your storage devices to the Swordfish model. So if you have a REST API that you currently use for your storage, and most of us have it. I mean, you're with Pure Storage, I'm with Nimble,

we also have 3PAR, we have NetApp in the room, we've got all these different vendors, and we all have PowerShell toolkits to help our customers manage their own storage. All of these PowerShell toolkits depend on the REST API that those vendors supply. So with this, we're actually going to show you how you can take either the PowerShell toolkits depend on the REST API that those vendors supply. So with this, we're actually going to show you how you can take either the PowerShell toolkit or directly from the REST

API and feed it right into Swordfish. And that's how the mapping is going to work. Then we're also going to talk about the provider framework. And what this is, is it's great that I can use a PowerShell toolkit to consume Swordfish resources. It's great that I can map my REST API to Swordfish to see how it looks. But more importantly, I actually want to be able to provide Swordfish to my customers. I actually want this to be on the server side instead of just the client side. And we're also going to show you how the emulators work and how the mock-up website works. So today, we ship a Python-based emulator that anyone can download from GitHub to become a Swordfish target. Anyone also can download, go to the mockup site, and that pretends to

be a Swordfish target. So here's our two targets. This is the third target we're going to introduce today, and this is the bridge between the two. And I'm going to show you what that looks like here. So what we've got is, if you're a storage vendor, your storage device lives here. But more importantly, your storage device needs to have its own custom Swordfish emulator. What I'm gonna show you here is how we can use your storage device, and you can use the Swordfish PowerShell toolkit

to actually query that information. And more importantly, the WAC extension, which is gonna live off of the Swordfish PowerShell toolkit. This is a Swordfish consumer. This is a Swordfish provider. But more importantly, we also provide this provider, which is the mockups.com site, and we also provide the Swordfish simulator that's out there right now. What we're introducing in this session is the PowerShell toolkit and we're introducing a Swordfish provider

that lets you put your storage device here instead. And we're doing a REST API Swordfish mapping example that shows you how you can take your storage, map it to Swordfish, and then expose it via the provider. So you can write your own custom provider, or you can use our shell of a provider to do it. So again, if you're very familiar with Python, you could actually start with the simulator or emulator as it is now that's written in Python. You could actually modify the API code there and actually add your device in and go directly from your storage to the

simulator, or you could write your own custom provider, or you could use our PowerShell provider and actually modify that as well. I'm going to show you exactly what that looks like. It'll all make sense in a moment. So the toolkit, let's start with the client. Swordfish doesn't mean anything unless somebody can actually query the information from a storage array. For instance, if I've got a storage array out there, I want to know how many drives it has.

I want to know what chassis it's living in. I want to know how many volumes it's got, how many initiator groups it has. I want to know all the replica information. To do that, we've actually started up an open source project here that will run in a Windows environment or Linux environment using PowerShell, and it will actually

query and make REST API calls directly against a Swordfish-enabled target. So if you've got a device at Swordfish today, we can query it using PowerShell. And we could run very, very simple commands, such as you import the module, and then you say connect swordfish target down here. You give it a target name in the port. By default, if you leave these alone,

it goes local host and it goes port 5000. But if you, if you want to, you can point this to any swordfish target in the world. Whether it's a simulator, whether it's an emulator, whether it's swordfish mockups, it doesn't matter what, what it is. If you've got a swordfish target, this will talk to it once you do that and you actually connect to the array it will return back the base object of that device so you're turning back the the root structure of redfish slash v1 and in fact you'll notice that we're returning the actual object and these right here are all the json items that you'd expect to find I'm going to show you what that looks like in JSON code. This, by the way, is what it looks like when you're connecting to the Swordfish target.

I also wrote a command to connect to the Swordfish mockup website. Treats it exactly the same because the Swordfish mockup site and an actual Swordfish target look the same. So this different connection type lets you test without even having to run an emulator locally. Normally, if you want to run PowerShell toolkit to connect to Swordfish, you need a Swordfish target. But this lets you connect right to the website and set up absolutely zero infrastructure to start working on this thing.

So you can actually start consuming Swordfish resources immediately. Now, with that said, everything's returned as objects, nested objects. And you very easily cast them to variables. So if I do a get volumes, get swordfish volumes, it's going to give me back a list of all my volumes. And if I throw that into a

variable, I can walk through those and say, okay, just give me volume four, or give me a list of my volumes where the pipeline object dot name equals volume five. So I can look for individual volumes. I can also use more complex code. I can say give me all the volumes where the volumes are

bigger than one gigabyte. Or give me all volumes where volumes, uh, uh, provisioning policy is equal to thin. So you can do all kinds of filters and piping through the native PowerShell directly with this command. You can even cast this variable and say, I want that variable, when it comes back with an object, I want to be able to push that back to JSON to see what the raw JSON code looks like. So that's what this looks like. If I do a get volumes, and I only want volume four, I can convert that volume right back to JSON, and

boom, that's what the JSON looks like for the raw device. So not only can I pull a swordfish target and pull an individual volume and do all kinds of work on it, but after that I can put it right back into JSON to be able to look at it as I would if I was expecting to read JSON raw so again this is the raw JSON and again it converts from the JSON object that's on the swordfish target

brings it into PowerShell, uses it as an object converts it right back again so we're not actually modifying the data, we didn't code any of this information this information. This information is directly passed through. So if you need help on these commands, and by the way, there's a lot of commands that are included, you can do a list of valid commands is get command module swordfish,

sneak swordfish, and if you want help on a very specific command, you can do get help and the name of the command with an examples or full and you can actually see samples of what these commands look like when you're running them. So every command that we've written, I've also made sure that we put inline help in. So there's inline help for all these commands

including how they operate, what they do, what API they're calling and examples of what they look like when they're being run. To see the raw transactions, you can actually do verbose true, at which point all of the raw REST code is actually going to be thrown to the screen in yellow, so you can actually troubleshoot a problem with your provider. If you're writing a Swordfish provider, you can use this PowerShell toolkit so that you

can make calls to the device. And with the verbose mode on, you can see exactly what the responses are. And this, by the way, is what the help looks like. So here's a get command on the Connect Swordfish mockup. It tells you roughly how to use it, and it even gives you an example down below of exactly how to run it. And this is standard PowerShell. All PowerShell people know how to use this and know how to expect it. So this is expected behavior for all. And this is the get swordfish volume. And you can see I've got multiple examples because I can actually put filters on the get command too. I can say get swordfish volume

and I can point to a single swordfish service instead of actually having it, so if one Swordfish provider could actually be providing five different arrays, but I can actually point down and say, okay, only get if it returns back service ID of that, or only get if it returns service ID of that and volume name of that. So I can actually filter it on the command line so I only pull back one thing. That

way instead of pulling back an array of objects, I can actually just pull back a single object or a collection of objects. Yes? Is it pulling the whole object, or is it doing the dollar select? In other words, it's going out there and getting everything? No.

Well, the first pull, it's got to do multiple pulls. The first pull, it goes and looks at the index. Once it's found the index, if you specify these, it can just pull the individual item. So it's not, but, so it makes one call for the index and then one call for the individual item. If, on the other hand, you say, you put a wildcard in there,

it has to look at every item and see if it validates on the wildcard. So these are the working commands right now that I've written. So get sword've written so get swordfish chassis get swordfish chassis power get swordfish chassis thermal get swordfish drive get swordfish endpoint endpoint group storage pool storage services volume class of service swordfish target and mock-up so these commands all exist and they're all get commands i haven't written the post commands yet, which are going to be new and set. So in a REST API world,

you're going to be used to CRUD operations. Create, remove, update, and, or no, create, read, update, and destroy. In PowerShell, those are actually converted to get set, new, and remove. So the terminology is a little bit different, but they work exactly the same. So you can see that I need to do new set and remove

for endpoints and groups, pools, group, you know, consistency groups, volumes. There's a bunch of these I still have to write, but it's all open source work that anybody can help out with. The framework is already there. Adding these new commands is not hard to do. So again, the create equals new, read equals get, update equals set. And again, all commands have inline

help. And all commands work both against the Swordfish targets if you downloaded the emulator that's written in Python, or it works against the Swordfish website, or it works against a real Swordfish target. They're all designed to work equally in all three places. You should mention about get-verb, because that's what's defining all these. True. There is a terminology with PowerShell that only a certain select number of verbs,

the first word, can be used. All PowerShell commands work as verb-vendor identification and then the command itself, noun. So in this case, swordfish is vendor identification and drive is the noun and get is the verb. That's how all PowerShell commands are formatted. But there are only a select number, like for instance, if I wanted to use delete, delete's not a valid verb for PowerShell and it would actually throw errors.

And PowerShell people aren't expected to know that delete is a valid verb. They're always looking for remove. So there's a whole bunch of terminology that PowerShell people have to accept that we have to live with. Yes? And then mention about the singular small. Right?

So like, getSorcusDrive, you just use that to get you all the drives. Right. Right. The other thing is that normally with API, a lot of people when they write their API, they write things plurally. For instance, if you want to get drives, the API

call is drives with pluralized with an S. In PowerShell, it's always a singular because you might be getting one drive. But singular assumes that instead of returning a single item, you could actually return an array of items. So get swordfish drive. It's always going to be a singular drive, not drives. So the things to remember here is we use the approved verbs.

We prefix everything with swordfish, and our nouns are always singular. With that, you can pretty much figure out, and we try to make the nouns exactly match what the API model was as well. Now I should note that we're not using any DLLs, any compiled code. Everything is open source and viewable by the public. But that also helps because we're also not using anything that doesn't compile for Linux and Mac. So if you're running PowerShell for Mac or PowerShell for Linux,

you have to be using.NET or.Core specifics only, which this will run on. So it makes it much more portable that way. But it also ensures it's all open source, nothing is held secret. So let me show you what the mapping looks like. If you want to map your storage device directly to a PowerShell API, or directly to a Swordfish API, that's kind of a hard job. That's where really all of the meat comes in of how you actually implement Swordfish, is how do you map what you have

to what's existing in the spec? Because they're going to be different. Nobody does everything the same. So what you're going to need to do this is you're going to need the REST documentation for your device, a PowerShell toolkit that exposes that REST documentation, because then you can just make PowerShell calls

instead of having to write raw REST. And basic PowerShell knowledge, access to Swordfish mockups and access to the Swordfish spec. And with that, you're going to retrieve the volume from your, the volume object from your device, expand its JSON, hold it side by side. So you're going to say, get volume here on your device,

and then you're going to do a get volume on the Swordfish spec, and look at them side to side, and actually see what matches up. If you have the documentation from your spec, you can actually read the spec. When your volume says size, does it mean the same thing when it says size in the Swordfish spec? And you'd think that's an obvious, but it's very common for a vendor to express things in megabytes or in gigabytes or in gibibytes. You have to normalize your data because the sort of spec expects it a certain way.

So with that, you can actually do that very, very easily. But you have to know what to expect. And then you're going to go through them side by side. Let me show you what that looks like. So here's where you're normalizing the spec. In this case, my volume cache policy is either going to be normal or it's going to be off. But in Swordfish terms, it's either going to be adaptive read-ahead or off. So I can't feed, normally I would just feed the same value in from one spec to the other spec.

But in here, I simply have to change the name from, if the value equals normal, then the value I should feed in is going to be adaptive cache. Otherwise, the value is going to be off. So you can see that there's some things I have to normalize. This is kind of what that looks like. I go into swordfish.com, or swordfish mockups, and I downloaded a volume, a standard volume, just a sample. And then I took my spec, which has all these different fields,

and I figured out what maps to what. Some of these are going to have to be normalized, most are not. But as soon as I've done this little quick mapping, I can kind of start to figure out what this is going to look like. Now, you notice there's going to be a few classes. There's going to be some things in here that simply do not exist in the Sorphish spec, in which case I don't have to worry about it. There's going to be some things over here that do not apply to my device. Again, don't necessarily have to worry about it. I'm going to look at the Swordfish spec after this

to try and figure out what I can flesh out. This is just to get me a started, a place to start. So the idea is that, for instance size here it's 4096 block size here 4000 uh 4096 i'm gonna put the exact same thing it's just going to feed right over so it should make sense how this mapping is going to work after you've done the mapping then you go to the sort for spec and you start walking through all the different fields that could exist for a volume to see if you've got something from your ap that matches it. And if you do fill it in, if you don't, you don't. But there's going to be some things like, for instance, my array, nimble storage, my array only supports triple parity. Now, if I look at the spec, the spec actually for RAID type actually says one of the options is

RAID 6-TP for triple parity. So that's the term I'm going to use. And because my array doesn't support anything else, it doesn't return it as a setting here, but I can fill it in over here as a hard-coded value. Again, I hate hard-coded values, but in some situations, if your array only does it a certain way, you can't hard-code values in. So some things are going to be hard-coded,

some things are going to be directly pulled in, some things are going to be normalized before they're pulled in, and then some things are simply are going to be hard-coded, some things are going to be directly pulled in, some things are going to be normalized before they're pulled in, and then some things are simply not going to be there. And you're just going to simply go through the entire spec doing that. Now, once you do, this is what it's going to look like. You're going to make, and

I created a file structure to match the Swordfish spec. So again, we're now off the PowerShell toolkit, which is where most of us start at, because that's how you query a Swordfish target. Now let's move on to a mock-up. I've actually put a project here,

which I'm working on getting all the vendor-specific stuff out of and making it generalized. And once I do, it'll be submitted to Snea's site for inclusion as a new open-source project. But what this does is it lets you run a PowerShell commandlet that will query, and by the way, I'm calling this Project Catfish, it lets you query the array, an array, and lets you pull all that data in

and save it all to the hard drive locally. And what it does is it saves that structure to the hard drive, and then you can see over here the code where I'm filling in the detected values directly into the fields of what the JSON should look like. Now, in PowerShell and JSON look very similar. I mean, it's surprisingly similar.

The only difference is instead of a semicolon, or instead of a semicolon, they use a colon between the values. They use an equal sign. Instead of sharp brackets, they use curly brackets. I mean, there's very, very few differences, but the point is,

this is all written so that it's very easy on the eyes, very easy to read what my final spec is going to look like. And more importantly, I run a final spec, and I create a file. I create a Swordfish mockup file called create mockup. And that create mockup has different

sub files. It runs one for volumes, one for endpoint groups, one for endpoints, one for storage pools, so that I have one of these that looks like that inside each of my sub files. And the value there is that if I need to troubleshoot something with volumes, I open up the volume file and I look in there and I mess with it. And once I figured out how to do this for a single volume, I simply put it in a loop and have it run against all the volumes. And it builds the entire structure for you and just creates it. Now, you should note, if you're new to PowerShell,

all variables start with a dollar sign, and all constraints, all our constants are shown in brown. So if something has a single quote on either end, that's a constant. I'm not going to change it. It's just fed right in. For instance, up here, OData type,

I know I'm conformant to the 1.0.4 volume, or 1.4.4 volume spec, so I just hard-code that right in. And if I update this module to change to 1.5.0, I'll manually do that as well. So again, we create the object in my PowerShell script as a PowerShell object. And then remember before I ran the PowerShell toolkit

and I was able to pull a volume and then convert it to JSON? Well, I can do the exact opposite. I can take the object I create in PowerShell, convert it to JSON, and then save it to a file. Or send it out to a user. So it's the exact same process. I'm using the built-in convert to JSON functions. And to do this, the best part is you can actually take this,

this mock-up creation process, and you can turn it around and actually make PowerShell listen to port 5000 and actually query the information that's coming in. So if I do a call to port 5000 on this server and I've got my script actually listening to port 5000, all the different directories that it tries to do, that it tries to query,

come back as parameters for my script. At which point they can return the actual index that they looked up previously. So the mockup does two things. If you run the create function, it will lay onto the hard drive an exact replica of what my storage looks like from a Swordfish perspective. I can walk down all the directories.

I can look at how things are laid out. I can open the index.json files and just read them like a text file. However, I can also run the PowerShell command called listener that listens for port 5000 and will actually respond to Swordfish calls. And the best part is I pointed it so that the listener will point right back to that file system and respond with the exact answers that I've recorded previously. So the benefit here is that I can take a swordfish, I can capture a model and then replay that model back all I want, over and over and over.

Now it'd be great if you all had nimble arrays. I'd love that. I'm sure for you it'd be great if everyone had a pure array. But I can't really expect that for somebody who's trying to develop on PowerShell. So I've also included in the GitHub the output of my array after I've pulled this information. So if you want sample data of a nimble array having been run through this process, it's on the GitHub site as well. So you could actually run a listener and pretend you have a nimble array on site that you can run against, run commands

against, without ever buying a nimble array, just so you can get down how the process works and how the code works. And this, by the way, is the code for the listener. It's really simple. PowerShell lets you do a lot of things like this, a lot of system-level things really easily. And then once it's running, it's pretty nondescript.

Now note, in my PowerShell code, I could choose very easily to rewrite that code so that instead of pulling the listener information, instead of going to the hard drive and looking for a static file, instead I could actually go to the array and pull the information directly from the array. And more importantly,

I could also write it very easily, very small changes, so that instead of a put, if it was a put instead of a get, instead of actually reading information from the array, I could actually push information to the array as well using the exact same command set. So it's a very extensible toolkit,

and this can actually give you a storage provider written in PowerShell for your non-Swordfish-enabled array. You've got a Swordfish-enabled... You've got a non-Swordfish device out there. This gives you a proxy agent that you can roll in a couple hours. And in fact, tomorrow,

I'm actually going to be demoing that in the Swordfish mockup, or workshop. We're going to be doing a workshop next door. We're going to help people install the emulators, help people install the tool kit, and I'll help people run this Swordfish walkthrough. So you can actually figure out exactly how to write your own emulator. And if you want, we can actually take a look at your API, if you've got

an API with you. We can take a look at your API and show you exactly how things map over. And show you how, we can actually take a look at your API, if you've got an API with you. We can take a look at your API and show you exactly how things map over and show you how to use the specs to do that as well. So this should kind of give you an idea of where we're going. Right now, I don't have that many commands done. I've got most of the read commands done. I haven't done the write or the update commands yet, but those are coming.

And those should be done before the next event. It's a cookbook. And then we are on to Barker's session, which is Windows Admin Center. Let me give you the microphone. Oh, you're on this one. Where's the little clicky? That's on the keyboard.

It's a little arrow. Oh, I thought you had one. Yeah, so everything that Chris has kind of talked about in terms of the PowerShell work that we're doing, one of the things I kind of always call it, we have the chicken and the egg problem, right, which is we can have swordfish services, but if there's no client consumer, what's kind of the point of actually having that service? So really what Windows Admin Center is going to give us is the ability to build what are called extension types. And that will act as a consumer or a client for consuming not only Redfish stuff but also Swordfish.

So Windows Admin Center is essentially the next generation of server manager in Windows. So if you're running Windows Server 2019 and greater, you're going to notice that there is no more server manager there to be used. So that's the replacement is Windows Admin Center. And one of the major differences is because server manager never had an extensibility model, right? You're pretty much stuck. This is all you can do with this thing. And it's very, very specific against Microsoft features that they wanted to implement. But Windows Admin Center has an extremely good extensibility model behind it. And the way that you do that is we build what are called extension types. So there's two types of extensions. One is called a solution extension, which is a very high-level extension that's built

into the master menu list of Windows Admin Center itself. And then there's also what's called a tool extension. So Windows Admin Center is all about managing servers, compute nodes, hyper-converged infrastructure, failover clustering. So it's built in what's called the connect context model. So you're always going to be connected to something, and once you have that connection, the context of you working in that is what's going to provide a lot of these different extension features. So the interesting thing about WACC is the fact that because when you connect

to a server that has Redfish enablement, you build a tool extension for that server connection, and now you can actually begin interrogating all of the Redfish characteristics that might be surfaced from that particular compute node. So you have to think about how this connection model works in terms of what we're going to be able to do when it comes to specifically around the Swordfish piece. So there's some interesting things that you can do. One of the most important attributes of working with Windows Admin Center as a developer is you have to install it via the command line,

and you're actually going to use this attribute called dev underscore mode equal one. That's going to give you the ability to do live debugging sessions inside of Windows Admin Center from whether your tool is Visual Studio proper or whether you want to use Visual Studio Code. You can certainly get into debug sessions to be able to do these things. You're going to notice it's what's called side-loaded. So that just means that you're side-loaded so that you can do debug sessions and connections into that particular extension type.

So when Microsoft released Windows Admin Center in its early days, it was better known as Project Honolulu, they only had an SDK that was 0.1. So they just recently, with a later build in the 1900s, that they've introduced the SDK 1.0. So all of these are links in here, so that way you kind of have a quick link into looking at the SDKs and everything else. We've adopted this latest insider and the next operations, so that way you can define whether or not you want to use current builds or whether you actually want to use future builds of the SDK with even newer builds,

preview releases is what they consider them, for the different versions of Windows Admin Center themselves. So there's two types of plug-in connections that you can use. One is called a gateway, and the other one is basically being able to do a PowerShell extension. So the basis work that Chris has been doing on the PowerShell toolkit, we are going to essentially use that same toolkit to be the driving force behind any of the connectivity models inside of Windows Admin Center itself.

So the interesting thing there is that as more improvements are made into the PowerShell toolkit, we're just going to natively adopt those inside of Windows Admin Center. So the other thing, all of this is, so the screenshot on the right, this is the new model that's being used. So before, the interface on this used to be iPlugin. That's been deprecated now, so now everything flows across HTTPS, so you don't have to worry about handling a lot of that stuff yourself anymore. The way that one of these plugins works is when you publish a plugin that you want generally available to anybody that might be running Windows Admin Center

is you publish to the master Microsoft NuGet feed. So once it hits there, and any time an update's made, you're going to actually see that extension come up and say, hey, there's an update available. Do you want to go ahead and install that? So this is something that I'm working directly with Microsoft on because we have to go through a publishing process with them in order to get that particular package up there. But as a developer, what you can do when you're running Windows Admin

Center in dev mode is you can create your own feed, and that feed can just simply be a folder on your box. WAC runs both on Windows 10 or Windows Server itself. So you don't really need to kind of have a server infrastructure in order to begin doing development work against Windows Admin Center itself. So this is an example of a solution extension that we built. You'll see here, this is the extensions gallery. And you can kind of see there's tons and tons of different companies

that have actually been doing things in here. Fujitsu, there's DataOn. And then there's a whole bunch of different developer tools that you can actually download. So this is what a solution extension looks like. You can kind of see there's the Pure Storage logo. And then you'll see there's all these connection contexts. So this is how we actually manage the connectivity into a flash array.

So the only thing that we're going to be doing different here is actually we're going the connectivity into a flash array. So the only thing that we're going to be doing different here is actually we're going to be connecting to a swordfish endpoint. So now we'll have that connection, just like Chris showed in the commandlet of connect swordfish target. We'll actually just be connecting to that swordfish target, and it'll be represented as a new connection type that you can begin drilling into. So these are just some of the things that you can accomplish in Windows Admin Center. This is a view of what our dashboard looks like on our main management interface.

So you can pretty much replicate anything that you want. Microsoft provides a very robust set of integrations and controls that they've already built that you can leverage. And the purpose behind this is that it's not recommended that you go off and do some custom thing because as new versions of Windows Admin Center come out,

they want that to be highly compatible moving forward. If you have your own custom controls that you've developed, it's not going to follow their CSS styles. It's not going to follow any of their best practices. Hence the reason why you really need to focus on just using the particular controls that are actually provided by WAC itself. So you get action menu items, and all these types of things are going to be able to do, as right now we only have get cmdlets, but as we do sets and everything else, we're actually just going to build them into a real user interface.

So the first version of the project that I'm working on is, you know, in Don's session, he talked about the basic web client. So all I'm going to be doing is taking the basic web client and really plugging it inside of Windows Admin Center. It's called the iFrame way of doing things. Very simple, very straightforward, and it shows that first kind of example of how you develop a really basic extension. And then as we move forward, I'm essentially going to be taking the basic web client and providing all that same type of functionality

directly in Windows Admin Center. So you'll be able to do clicks and adds and take actions like destroy volumes or destroy different elements that might be part of the schema itself. So here's a couple more examples of what some of the screens look like in terms of our extension.

So the next steps that I have to do right now is I'm actually actively working with the teams called Server Management Team at Microsoft, but everyone refers to them as the WAC team. I'm actually working with them because they are contributing to this open source project. So it's not just simply pure and HPE.

I mean, we want more people to contribute to this. And it's very interesting for me. I think Chris and I really appreciate the fact that the WAC team sees this as something that they want to invest some time in. So I do have calls with them to kind of go over different things that we might want to accomplish because everything has to be built around this connection. A connection requires credential management. So there's some very, very specific things that we need to do from a credential management standpoint. You know, moving over to the new SDK versus the old SDK. And then, you know, like Chris had mentioned, you know, we're going to be, you know, talking about

some of this stuff in the workshop. So, you know, I'll have some demo code and everything else that will be up so you can kind of see how this thing's developed. So there's two also ways of doing Windows Admin Center extensions. One is if you're a C++ or a C Sharp up so you can kind of see how this thing's developed. So there's two also ways of doing Windows Admin Center extensions. One is if you're a C++ or a C Sharp developer, you can certainly do that. WACC is all based on Node.js, Angular, and TypeScript. So you kind of have your different options of how you want to implement this.

Or like I said, you can go ahead and use C Sharp, and best of all, you can actually write a lot of this stuff in PowerShell directly as well. These are all the resources. Chris had a couple on his slides. There's the toolkit, and these are all the different things that you would use to actually get started in writing an extension. They're very, very well documented,

and it's quite easy and straightforward to kind of get running. Like I said, you can do this on Windows 10. You can manage Windows 10 systems, or you can manage Linux. You can manage Windows, basic Windows servers themselves inside of Windows Admin Center directly. And with that, that was my stuff, and we can do Q&A. I want to add one more thing, too, which is that the WAC client while writing is actually the first

open source, or not the first open source, the first industry standards organization WAC module that Microsoft's been cordoned to take on. Yep. There may be more coming after that, like we were talking about a Redfish one at some point, but this is the first one and we're also the first group

that's going to be doing the development in the open because up till now it's always been vendors who are writing their whack module not presenting how they did it to the rest of the world this one's going to be all about exposing to the world yeah i mean the other intention of like the toolkit itself is instead of every vendor going off and doing their own thing and being very customized to that particular vendor that the whole point of this open source project is to have that standard that supports the standard. And this is the way you go and access everything. Everyone's on a level playing field. And if you know how to do something, I mean, what company doesn't have an EMC, a Nimble, a Pure, multiple arrays?

If you know how to talk to one, you'll understand how to talk to the other ones as well. And what I'm looking forward to is the day that somebody comes to me and says, hey, your PowerShell toolkit didn't do this properly, and I followed spec. That's exactly the call I want to get, because that means either the spec and something's going on there, or it means the toolkit needs to be updated.

That's how we make these things better, is by people actually implementing against them. And the toolkit, if it doesn't return your volume, you should look to make sure that you're following the spec properly because it should. And one of the other things that we're going to include, so there's this utility in PowerShell called Pester. So Pester is the way to do automated testing.

It's a declarative language. So we're going to be building Pester tests in here so that if you wanted to do mass scale testing or anything else, or you actually wanted to test based upon certain things that are coming back from the spec itself, you'll be able to identify these things very rapidly by just being able to run and kick off all these pester tests to actually go off. And you can write reports back out of it. You can do error tracking out of it. So we're going to be including some of those as well. Yeah, and the major way of actually distributing PowerShell modules

is through what's called the PowerShell gallery. So it's very, very simple. You just say install-module. What the module name is, in this case, it would be SNEA Swordfish. Pulls down from the gallery automatically, and your installation is done. 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.