Ameet Deulgaonkar

And, in fact, a lot of these things are managed by an infrastructure admin going forward, right?

There's no more dedicated storage admin in some of these SMB segments.

So in order to cater to these myriad requirements, we have given complete flexibility in terms of our APIs.

Now, if you want to be very picky and choosy about where the workload needs to be deployed in the cluster and you are an expert, yes, we allow you to do that.

But we fail and warn you when you are doing something wrong.

For example, if you're trying to place a workload on a node which does not have a budget,

or exhausted of all the budget, we say you can't put that here because your SLA is a problem, right, or your SLO is going to be a problem, right?

But within a pool of resources that can satisfy the request, right, we allow you that flexibility back to you, right?

And we also allow you to take an existing workload and say that, you know, this is IO density for this workload.

You can apply a service level on this one and then import it into the framework, right?

And then you can move it around and you can put it in the right resource for cost optimizations and things like that.

It's pretty much up to you.

In fact, we are trying to integrate SLM APIs into WFA so that people can use WFA automation and orchestration to do some of these things that you talked about.

It works with both the versions.

We make use of whatever the capabilities of the platform are.

For example, we support from

2 onwards, and 8.2 does not support the ONTAP headroom performance capacity they're referring to.

So we make use of static IO budgeting there.

Whatever value we get from the oversizing process, we keep a static IO bookkeeping there with us.

And we work with what we have, right?