Mike, you are absolutely right. I have added 4 new fields in the disk_offering table. The driver code won't need to change as I would pass the min and max IOPS after translating them. I am not using a fifth parameter since it is an either or situation, if you pass IOPS/GB in your API call and also pass an IOPS value, I will error out saying that you can only use one of those.
Thanks, -Syed On Thu, Jul 27, 2017 at 2:53 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > So then, based on the use case you mentioned, you are saying you don't > really care about minimum limits, right? > > Are the values you specify for the disk offering going to be translated > into the standard min and max values that get stored in the volumes table? > If that is the case, then the storage driver code won't need to change. You > would perform the translation and then pass in the min and max values to > the driver as is done today. > > In that situation, you would only need four new fields in the > cloud.disk_offering table. Perhaps a fifth column saying whether you were > using IOPS/GB or the standard way. > > On Jul 27, 2017, at 12:45 PM, Syed Ahmed <sah...@cloudops.com<mailto:sa > h...@cloudops.com>> wrote: > > Hi Mike, > > In case of min and max values of IOPS for a specific offering, there is > another use case. We want to offer tiered storage. Right now if we have a > disk offering, there is no way for us to limit the IOPS that the customer > can set. We want to have say an offering which scales upto 10k IOPS and if > the want more IOPS, they must switch to a higher tiered offering which has > its values set to a higher limit. > > As for compatibility with existing offering. You are right, the existing > offerings will still work as expected. An IOPS/GB setting will be used > independently of the current method (fixed or custom) > > Thanks, > -Syed > > On Thu, Jul 27, 2017 at 2:34 PM, Tutkowski, Mike < > mike.tutkow...@netapp.com<mailto:mike.tutkow...@netapp.com>> wrote: > Hi Syed, > > I have a couple questions. > > What about the minimum number of IOPS a storage provider can support? > > For example, with SolidFire, in some releases we can go down as low as 100 > IOPS per volume and in newer releases as low as 50 IOPS per volume. > > Perhaps you should just leave it to the storage driver to confine itself > to its minimum and maximum values. This would not require such parameters > to be passed to the disk offering. > > Another question I have is how compatibility will work between this > proposed feature and the existing way this works. I assume it will be an > either or situation. > > Thanks! > Mike > > > On Jul 27, 2017, at 9:34 AM, Syed Ahmed <sah...@cloudops.com<mailto:sa > h...@cloudops.com>> wrote: > > > > Hi All, > > > > I am planning to add 4 new parameters to the disk offering. The use case > for this is as follows: > > > > We want to provide a provisioned IOPS style offering to our customers > with managed storage like SolidFire. The model is similar to GCE where we > have IOPS scale with the size based on a predefined ratio. So for this I > want to add two options. minIOPSPerGB and maxIOPSPerGB. Now, based on what > storage you have, you have limits on the highest values for your min and > max IOPS and after which you don't want to scale your IOPS (SolidFire for > example can do 10k minIOPS and 20k max IOPS). To support this, I have to > add two more parameters, highestMinIOPS, highestMaxIOPS. This should work > with existing disk offerings without problem. I am looking for comments on > this approach. Would really appreciate your reviews. > > > > Thanks, > > -Syed > >
