Add requests and limits to Persistent Volume Claim

[zakiva]

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1508372

Related PRs: ManageIQ/manageiq-providers-kubernetes#116, ManageIQ/manageiq#16026

@miq-bot add_label enhancement

@simon3z @zeari Please review

[miq-bot]

Checked commit zakiva@fbb610d with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
1 file checked, 0 offenses detected
Everything looks fine. 🍪

[Fryguy]

@zakiva @simon3z I'm ok with this, but why is this modeled as a serialized Hash as opposed to fully modeled out? Will we ever want it more modeled out in the future?

[simon3z]

Will we ever want it more modeled out in the future?

@zakiva can you reference the relevant BZ in the description? I wonder if indeed we want to model that now.

[zakiva]

@zakiva can you reference the relevant BZ in the description? I wonder if indeed we want to model that now.

I didn't find a relevant BZ for that (maybe @Loicavenel knows if we have one).
Anyway, this is part of the storage for chargeback feature @zeari is working on. We currently collect only the actual capacity of the pvc's bounded volume, which also saved as a serialized hash and been accessed in some places, here for example.

[zakiva]

@simon3z Do you want to merge this before the freeze?

[Loicavenel]

@zakiva @zeari can you tell me what is this PR is about? I am not sure I understand it. Is it to have Chargeback for VolumeS?

[zeari]

@zakiva @zeari can you tell me what is this PR is about? I am not sure I understand it. Is it to have Chargeback for VolumeS?

@Loicavenel yes. the values we are collecting now might not be the correct values to use for chargeback with storage.

[Loicavenel]

@zeari can you be more explicite? We do have PV and the Size... this is fixed.. how it can be wrong?

[zakiva]

@zeari can you be more explicite? We do have PV and the Size... this is fixed.. how it can be wrong?

@Loicavenel The claim can have 3 different values related to the storage size:

1. allocated - this is the actual allocated storage of the bounded volume.
2. requested - the requested size by the claim, this is a lower bound for the allocated size.
3. limit - upper bound.

We currently persist only the first one, this PR adds the other two.

[zeari]

@zeari can you be more explicite? We do have PV and the Size... this is fixed.. how it can be wrong?

The capacity we are currently listing is the size of PV that was assigned to a pod\project instead of how much the claim asked for. If you request 1GB volume, you might be assigned a 2GB volume since that is the volume closest to the size to what you ask. So the size we know about would be 2GB instead if what was actually requested.
It makes more sense to charge for what someone asked for instead of what they were upgraded to.
@zakiva @simon3z Correct me if im wrong.

[Loicavenel]

@zeari so, Openshift is rounding up to the closest higher GB?

[zeari]

The process AFAIK

1. a project\pod requests a PV of size x
2. openshift has(for example) PVs of size 1GB, 2GB, 3GB...
3. openshift finds a PV with a size closest to x and binds it to that project

[Loicavenel]

I look in the doc here: https://docs.openshift.com/container-platform/3.5/dev_guide/compute_resources.html.. I don't see anything in Limits regarding PV storage. But I see it in Quota... requests.storage.
Where the PoD request will come from? how do we know what was requested?

[zakiva]

I look in the doc here: https://docs.openshift.com/container-platform/3.5/dev_guide/compute_resources.html.. I don't see anything in Limits regarding PV storage. But I see it in Quota... requests.storage.

These limits/quotas are in project level (summary of resources used in the project). The requested storage in this PR is per specific Persistent Volume Claim which represents a specific user request for storage, e.g. one pod needs 1GB.

[zakiva]

@Fryguy PTAL