ubuntu-image 0.7ubuntu1

[Barry Warsaw]

On Oct 11, 2016, at 12:03 PM, Oliver Grawert wrote:

>what is the justification to waste 50% when we resize anyway before the
>first boot, this doesnt make much sense (it makes the download cost
>higher, dd (a lot) slower, etc)

This is (relatively) old code that tried to compensate for file system
overhead.  Given that we already have two fudge factors, I would prefer not to
add a third.  Instead...

>IMHO we should either make the image the exact size we need or take a
>user supplied size from an option for setups where it makes sense
>(cloud, VM).

I agree.  Calculating the exact size isn't an exact science afaict, though I
would love to hear ideas on how to more accurately determine exactly how much
space we need.  Right now the algorithm walks the source directory adding up
all the sizes of all the files under that directory.  Then it applies the
fudges.  I'm not sure calling out to du would be any more accurate for our
purposes.  I'm also not sure there's a precise way to estimate the file system
overhead, though maybe by knowing intimate details of ext4 and vfat (the only
to fs's we currently support) could get you closer.  I think we're dealing
with fuzzy heuristics here, so what are the right heuristics?

>and yes, i'd prefer a properly crafted cmdline option here indeed, but
>today i need to use this patch to actually provide kvm images that
>users do not need to resize manually before booting, so getting
>something upstream in a not to far future would be good and prevent me
>from having to use my own patched ubuntu-image snap to produce dailies.

Sure, I definitely want to support this important use case.

Let me ask this: would you prefer a cli option/envar over declaring it in the
gadget.yaml, and if so, why?  My problem with the cli/envar is that it hides
the configuration in your shell history, instead of declaring it up front in
the yaml file.  The latter allows you to point to an image and say, "this was
created with that gadget.yaml" and be done with it, without also having to
specify the particular magic you used to run the tool.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.snapcraft.io/archives/devices/attachments/20161011/c03d92e4/attachment.pgp>