ubuntu-image 0.7ubuntu1

[Steve Langasek]

Hi Gustavo,

On Wed, Oct 12, 2016 at 04:04:22PM -0300, Gustavo Niemeyer wrote:
> We've discussed multiple times in meetings and threads that we want to
> represent the content of the images accurately inside gadget.yaml. The fact
> we're not yet doing that is a bug that we need to fix, and if there's
> disagreement we should talk about it.

The disagreement is about whether this padding is a fundamental property of
an image.

Currently, all of the images that we create are minimally sized to be only
as large as necessary to accommodate their contents, and they are expanded
on first boot to fill the media that they've been written to.  This is an
important optimization in the image creation pipeline (both for developer
use cases and - I believe - in the factory scenario), because it saves us
having to write a lot of zeroes over a slow I/O channel for the empty space
in a filesystem.

Are you proposing to do away with this auto-expansion capability?  If so,
this implies that:

 - each media size will need to be treated as a separate "image", and either
   the gadget or the model (depending on outcome of this discussion) needs
   to be changed to make an image for 2G vs. 4G vs. 8G [...] SD cards
 - writing the image to the media will take longer (~4x longer for a 2G
   image, even more for larger images), slowing down the factory process,
   and impose more wear on the media

This does not sound like a good outcome to me.  And if we don't want this
outcome, then conversely, the overall image size is not a property of the
gadget or the model.

And if it's not a property of gadget or model for the write-to-SD-card or
master-device-in-factory cases, then I don't think we should shoehorn it
into the gadget or model for the VM image case.


Putting it another way.  If we implemented this 'ubuntu-image
--image-size=4G' option, it would be exactly equivalent to someone running
'dd if=/dev/zero of=my-vm.img bs=1G seek=4 count=0' as a post-process step -
i.e. an fseek() and ftruncate() to extend the image, with no other changes. 
If I did that to a VM image locally, would you consider that a different
"image"?  Do you want something to consider this image an invalid instance
of the gadget or model?  (If so, why?)



> The whole point of redesigning these tools is to evolve the status quo
> towards something we are aiming at with underlying goals. If we are going
> to rush it in, we can just pick up the tooling we had (or the hack you
> mention) and put the images out.

What is lacking at the moment is agreement about the underlying goal in this
case, rather than agreement about how to get there.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.snapcraft.io/archives/devices/attachments/20161012/74c7c3f3/attachment.pgp>