ubuntu-image 0.7ubuntu1

[Gustavo Niemeyer]

On Tue, Oct 11, 2016 at 2:54 PM, Steve Langasek <
steve.langasek at canonical.com> wrote:

> On Tue, Oct 11, 2016 at 06:12:06PM +0200, Oliver Grawert wrote:
>
> > Am Dienstag, den 11.10.2016, 11:55 -0400 schrieb Barry Warsaw:
> > > On Oct 11, 2016, at 05:01 PM, Oliver Grawert wrote:
>
> > > > defining it in the gadget would be rather awful since that means if
> we
> > > > use an identical image for cloud, VM  and "normal PC install" we
> would
> > > > need a gadget per image just for that one difference ...  (the pc
> > > > image that you can use for all three consists of: pc (gadget,
> > > > pc-kernel (obviously kernel) and core (rootfs).
> > > That's the data point I was looking for, thanks!
>
> > > Can you explain in more detail why kvm images need some extra space,
> but
> > > other images do not?
>
> > on VMs the img file defines the "physical VM disk" while for an actual
> > install you write the img file to a pyhsical disk device ... the resize
> > code will find that the partition table does not cover all of the disk
> > before first boot and start the resize process so here the img size
> > wont be taken into account at all.
>
> > on a VM, all the resize code will see is the img file that pretends to
> > be a harddisk and it will find there is nothing to resize to.
>
> > > Also, if you specify a fudge factor via cli/envar, should that be
> > > applied in addition to, or instead of, any built-in compensation for
> > > file system overhead?
>
> > i dont mind either, whatever is easier to implement (as long as the
> > help documents the right behaviour) ;)
>
> I don't think a 'fudge factor' option is particularly clean or intuitive.
> I
> think what you actually want is to be able to declare the overall size of
> the image that you're building.  It's a waste of mental energy to think
> about VM image sizes in increments less than 1G, especially given that
> these
> are all still going to be sparse files.
>
> So I would suggest:
>
>  - a --size option to ubuntu-image to specify the full image size (needs
>    some careful thought for the multiple-image case)
>

If we support flags, we need to make it per partition so we can tell what
to grow, or we need to extend the language to be more precise about what to
grow and by how much relative to the total size.


>  - keep the 50% buffer on ext4 filesystem size as a floor (the '50%' can be
>    refined over time with investigation into the actual size requirements
>    for ext4 metadata, but this is not a high priority; highest priority is
>    that it works reliably)
>

What's the 50% buffer?  Per our agreements the size option in the structure
items is a requirement, right?


>  - if --size is smaller than the minimum size needed to accommodate the
>    contents, warn but build the image anyway - because all the expensive
>    work of ubuntu-image happens /before/ we're able to calculate the final
>    size, so throwing that all away at the end would be /very annoying/.
>

Why would we go ahead if we know the contents won't fit?  It sounds fine to
warn if we think it's too small to be useful. But we should error hard if
we know the image is corrupted. It's better to be forced to recreate than
to risk having people using knowingly broken images.


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snapcraft.io/archives/devices/attachments/20161011/b1e509b0/attachment.html>