Jenkinsfile.cloud: +8G the qemu qcow2 #228
Conversation
openshift-ci-robot
added
the
size/XS
|
/me wonders why we are resizing rather than just making the disk bigger when we create it? |
is it because we only want the qemu image to be the one that is bigger? |
Jenkinsfile.cloud
Outdated
| @@ -166,6 +166,8 @@ node(NODE) { | |||
| parallel par_stages; par_stages = [:] | |||
|
|
|||
| stage("Finalizing, generate metadata") { | |||
| // See https://github.com/openshift/installer/blob/master/Documentation/dev/libvirt-howto.md#13a-rhcos | |||
| sh "qemu-img resize ${img_prefix}-qemu.qcow2 +8G" | |||
There was a problem hiding this comment.
The gzip command below is still taking in ${qcow} which is ${img_prefix}.qcow2
That's the only one that I'm aware of that needs to be larger. We may want to bump up the vagrant ones as well. |
|
The default size of the default disk is going to be influenced by the base size of all of the containers in the default install right? It feels like we'll end up needing to track that somewhere; probably the installer, but I also don't see a problem with just making all of our images unconditionally larger. Doing the latter would be just a matter of tweaking the magic comment at the top of |
|
/hold |
openshift-ci-robot
added
the
do-not-merge/hold
In that case should I close this in favor of changing |
right. To me the best place for this long term is to have the installer request an appropriate size of the image (just like it would do for public cloud) and have that "size" live inside the installer. This PR is a temporary solution IMHO and we have noted that in our previous conversation we had about it. |
The installer requires the image to start off with an extra +8G developer usage. @eparis noted it would be helpful to have this happen in the pipeline rather than each developer doing it on their own. In the (near) future it would be preferable for the installer to handle this. Signed-off-by: Steve Milner <smilner@redhat.com>
Agreed. |
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
I opened openshift/installer#126 so it doesn't get forgotten. |
It feels like we should stay consistent across both local and public cloud as much as possible.
I believe every image format we ship isn't "raw" - qcow2 for example doesn't rely on being "sparse" or filled with zeros. The only one I'm a bit uncertain about is vmdk...and OK, some quick testing by doing: Does show the vmdk growing to 13G before I killed it; a bit surprising as it does look like the vmdk format talks about "virtual size" just like qcow2. |
|
It looks like AWS supports OVA upload, and hopefully at least that supports being sparse; something to look into later. /lgtm |
openshift/os#228 has been added as a workaround until the installer has the ability to resize images. Signed-off-by: Steve Milner <smilner@redhat.com>
|
IIRC, the reason we upload VMDK today is because that's what |
openshift/os#228 has been added as a workaround until the installer has the ability to resize images. Signed-off-by: Steve Milner <smilner@redhat.com>
This is the size of the current RHCOS images, but resizing here will allow the OS folks to stop guessing which size we need [1,2]. Explicitly closing the file before resizing ensures we've flushed the cache after the earlier copy. We probably should have been doing that before the Rename anyway. With this explict close, the deferred close call may fail, but that's fine. Dropping to qemu-img makes me a bit jumpy, but at lest most folks with a libvirtd running will have qemu-img available. [1]: openshift#126 [2]: openshift/os#228
This is the size of the current RHCOS images, but resizing here will allow the OS folks to stop guessing which size we need [1,2]. Explicitly closing the file before resizing ensures we've flushed the cache after the earlier copy. We probably should have been doing that before the Rename anyway. With this explict close, the deferred close call may fail, but that's fine. Dropping to qemu-img makes me a bit jumpy, but at lest most folks with a libvirtd running will have qemu-img available. [1]: openshift#126 [2]: openshift/os#228
This is the size of the current RHCOS images, but resizing here will allow the OS folks to stop guessing which size we need [1,2]. Explicitly closing the file before resizing ensures we've flushed the cache after the earlier copy. We probably should have been doing that before the Rename anyway. With this explict close, the deferred close call may fail, but that's fine. Dropping to qemu-img makes me a bit jumpy, but at least most folks with a libvirtd running will have qemu-img available. [1]: openshift#126 [2]: openshift/os#228
This is the size of the current RHCOS images:
$ qemu-img info ~/.cache/openshift-install/libvirt/image/2454fcdc0a61a9005fbf916b54fbe332
image: /home/trking/.cache/openshift-install/libvirt/image/2454fcdc0a61a9005fbf916b54fbe332
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 1.6G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
Resizing here will allow the OS folks to stop guessing which size we
need [1,2]. And when we need future resizes, we can update here
instead of bugging the OS team.
Also inline the volume in the libvirt Terraform module. The
libvirt/volume module indirection was unnecessary indirection.
[1]: openshift#126
[2]: openshift/os#228
The installer requires the image to start off with an extra
+8G developer usage. @eparis noted it would be helpful to have
this happen in the pipeline rather than each developer doing it
on their own.
In the (near) future it would be preferable for the installer
to handle this.