Add Second partition for storage-drive testing

[cevich]

This is mainly/initially to support use of Cirrus-CI
in https://github.com/containers/storage since that setup
re-uses the VM images from this project. However, it also
opens doors here, if libpod ever needs/wants to do things
with a dedicated storage device and/or storage-drivers.

Depends on #3632

[TomSweeneyRedHat]

Tests aren't hip @cevich

[cevich]

Oh no they're not, completely FUBARd. I'm on one of the VMs twidling bits trying to figure out to make this work :D

[rh-atomic-bot]

☔ The latest upstream changes (presumably #3601) made this pull request unmergeable. Please resolve the merge conflicts.

[cevich]

@rhatdan @nalind PTAL, this is ultimately for buildah's benefit. Once this can merge, I'll work on bringing the capability over there.

@mheon @baude I'm assuming libpod CI doesn't currently need to test with a device-mapper storage driver or similar "special" storage setup (swap enabled?). Otherwise let me know.

[rhatdan]

LGTM
But we originally wanted this for containers/storage so that we could run lvm tests for it.

[cevich]

Oh woops. No matter, containers/storage reuses the images from this project also. Glad I didn't start the work on buildah yet 😄

[cevich]

@rhatdan this PR is the other reason I want to try using the libpod produced VM cache-images in c/storage and c/buildah. (First reason being, fixing the stupid dpkg is locked thing).

[mheon]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mheon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

@mheon @edsantiago @vrothberg @TomSweeneyRedHat @baude PTAL and lets get this merged.

[TomSweeneyRedHat]

LGTM

[edsantiago]

I'm pretty baffled by this, but that's because I have no understanding of the /dev/sda setup offered by the CI environment. It might be nice in this or a future PR to document that, explain how it is that parted can be relied upon to have that space available in the sda device. As long as this works, I guess it's ok, it's just confusing.

[cevich]

explain how it is that parted can be relied upon to have that space available in the sda device. As long as this works, I guess it's ok, it's just confusing.

I'll add a comment about this. The "expansion space" is created because of the difference between base-image build time (20gig storage request) and the runtime request (200gig always otherwise gcloud issues warning). We have a unit-test in place to catch the 200gig case, and I tested manually to verify parted does fail safe:

If when the add_second_partition.sh runs, /dev/sda1 uses all the space, parted gives a message like: "Error, you asked for 50%, rounding up due to allocation. Refusing to grow partition from 100% to 100%" then exit's non-zero.

There are other ways this can break though, and no good solutions that are less complicated (I spent about two weeks trying - no joke 😦)

[edsantiago]

200gig always otherwise gcloud issues warning

That's right - I remember now. It's just that there are so many obscure trivial details to remember. Comments are helpful for that. Thanks.

[cevich]

It's just that there are so many obscure trivial details to remember.

Well I guess that makes me the king of obscure trivial details then (depending on my current level of caffeination) 🤣 I do really appreciate the feedback. There's nothing better than another pair of eyes to spot camouflaged assumptions.

[cevich]

(This PR does not need to go in until after release)

[cevich]

Okay, this one is ready @baude @mheon (when things quiet down a little).

[rhatdan]

/lgtm