[RM Ch04] Available storage extensions should remove hard-coded capacity

[kedmison]

The Available Storage Extensions table currently has a capacity field. VNFs should not have a fixed palette of choices for size here when dealing with remote block storage. Instead, the storage extensions table in 4.19 should be sufficient, with the possible (to be discussed) inclusion of a capability indicating the maximum possible allocation in each supported class.

Rationale: When examining OpenStack APIs, one can make a 'volume' request for a particular storage back-end, and can also specify the size of the volume at the same time. There is no OpenStack API that limits the available storage extension to a combination of a particular back-end and a particular size.
In Kubernetes, one finds similar attributes in the PersistentVolumeClaim 'storageClassName' and the storage quantity specified by 'resources.requests.storage'.

[markshostak]

@kedmison Hi Kelvin, We've discussed making storage extensions parametric, so I'm ok with your proposal. However, as discussed in the RM calls, everyone, please be sure when making an assertion such as "We do this, but we should to that...", that we also include the rationale/justification for why we want to use a particular method, so that: A- The merits of the change can be discussed at the time of the proposal B- The reasoning can be cited at any point in the future, when the question of "Why did we do <x, y or z>" arises in the future

Kelvin, Please edit in the rationale Everyone, Does anyone have any objections to this change? (@pgoyal01 Storage is near and dear; do you have any thoughts or concerns?)

Thanks, -Mark

[kedmison]

@markshostak Thanks for the reminder; I will do so.

[markshostak]

@ASawwaf @rabi-abdel Do you guys have any concerns if make the storage extension size, parametric as Kelvin proposed? Specifically, any impact on CNTT strategy/objectives.

@kedmison, I like your idea regarding constraining the maximum size by Instance Type, or at the very least, a maximum for all ITs. It's currently 300GB. Is that sufficient in your estimation?

Thx, -Mark

[ASawwaf]

@kedmison @markshostak , agreed

[kedmison]

@markshostak wrote:

@kedmison, I like your idea regarding constraining the maximum size by Instance Type, or at the very least, a maximum for all ITs. It's currently 300GB. Is that sufficient in your estimation?

When looking a bit forward at IT and ML workloads, I would say it's not, and that we would need something on the order of 1TB as a maximum volume limit. I am familiar with some big data (Hadoop & Spark-based) applications that had a multi-petabyte footprint, and those applications were developing plans to become cloud-native.
Can we specify something like 8 TiB as a maximum volume size, recognizing that some of these big data workloads may migrate to a CNTT-compliant NFVI, and that, by way of comparison, some public cloud providers have 16 TiB to 64 TiB as available maximums?

[markshostak]

@kedmison Hi Kelvin, I don't follow the jump from your first comment about needing 1TB to specifying 8TiB. I'm more comfortable starting w/ 1TB, then revising when we can justify it, but let's get some more perspectives...

@tomkivlin @iangardner22 We're planning to switch to a parametric sizing paradigm for specifying attached and couple it w/ a maximum size, either by Instance Type, or for all Instance Types. Do you have thoughts on what the maximum size should be? Also, do you think the maximum should be set for each Instance Type individually, or do you think a single maximum for all ITs is sufficient?

[tomkivlin]

@markshostak I had similar concerns to Kelvin early doors (but not because of what OpenStack does - I don't think we should be shaping the RM based on what one particular technology allows). My rationale for not doing this is that we would end up with a huge number of options as the performance of the storage presented to an instance will often depend on the size of the volume.

So, I am happy with the parametric approach, am not terribly bothered about a value for the maximum being defined in the RM (will make more sense in RA), but I do think we need to define the ratio between performance and capacity, i.e. IOPS and throughput (both per-GB), as in reality the size of the disk can affect the performance (i.e. you are often unlikely to get highest performance with smaller disks). Standard for hyperscaler providers, I believe OpenStack can do capacity based QoS, etc. Having such a spec in the RM can then flow through to the RAs to define which storage drivers etc. can achieve the spec.

[markshostak]

@tomkivlin Thanks Tom. So you're ok w/ parametric sizing. What do you feel is a reasonable maximum size? Thx, -M

[tomkivlin]

@tomkivlin Thanks Tom. So you're ok w/ parametric sizing. What do you feel is a reasonable maximum size? Thx, -M

No idea, would need to understand what is generally requested by software vendors today (bit like we did early doors to come up with the CPU/RAM numbers) - something huge though. 16TiB, 32TiB, something like that.

[markshostak]

@kedmison, @tomkivlin, All, To get this moving I started a PR (#786). Let's move the conversation over there.

[iangardner22]

All good with me @markshostak - I concur with @tomkivlin