ubuntu-image 0.7ubuntu1

Wed Oct 12 19:19:31 UTC 2016

> On 12 Oct 2016, at 20:04, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> 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 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.
> 
There is a pragmatic decision to be made here: what is the ideal situation, which we can probably agree will be the gadget.yaml definition, and what can we do to provide a stable platform that is expandable going forward? Given the time we have left before our final Ubuntu Core 16 milestone we should give weight to solutions that work and are expandable for the future. We all know that after this date much goodness will come; we will change things, adding and improving in addition to what has already landed, but for the release we need something practical. Can we implement a solution that can be backwards compatible but also extensible enought to cover the use cases we know about now but allow changes to be made to other ancillary tools when we are less under pressure to release? 

Regards,
Jamie.

> On Oct 12, 2016 3:41 PM, "Oliver Grawert" <ogra at ubuntu.com <mailto:ogra at ubuntu.com>> wrote:
> hi,
> On Mi, 2016-10-12 at 15:17 -0300, Gustavo Niemeyer wrote:
> > Instead of asking whether I've read the thread, I'd appreciate if you
> > could try to understand the point I'm making so we can make some
> > progress.
> > The gadget.yaml should represent accurately what goes into the image.
> > Not one image in fact, but multiple, one per volume, and all of their
> > partitions.
> 
> i understood during all sprints where we discussed it that this is not
> GA material ...
> 
> today snap prepare-image and ubuntu-image simply create a writable
> partition (it is the default thing carrying our payload whithout which
> we can not boot), today we do not define the writable partition
> anywhere.
> 
> to have it supported in the gadget we will likely need changes in all
> places, starting with the gadgets themselves, snapd for "snap prepare-
> image" and ubuntu-image (and in case you want a fancy different name in
> various other places inside the image).
> 
> for the change you are suggesting we will *not* have a solution this
> week. to have image building *at any point* in cdimage adam will need a
> functional ubuntu-image he does not need to patch like mvo and I have
> to do today to actually create functional images.
> 
> > We need to represent the "writable" partition in the gadget as well
> > if it is supposed to be in those images, otherwise how do we provide
> > parameters for it, and where does it go? Which position? And so on.
> > A lonely "size" parameter is not meaningful in that context without
> > further details. Then, how do we resize the boot partition, or any
> > other one?
> >
> 
> this is not about partitions at all ... a VM sees the img file as a
> disk device, the padding tells the initrd that there is space on the
> device it can resize the writable partition to. 
> 
> we can implement all sorts of fancy and detailed gadget stuff if you
> think we have the time to do so, but we have been waiting for ages to
> even be able to have a gadget usable by ubuntu-image at all, now we are
> waiting for ubuntu-image to be finished and are still not able to
> provide builds on cdimage (they happen on my personal desktop PC today
> and get rsynced to my people.u.c account, likewise mvo builds the betas
> by hand and manually scp's them to cdimage)
> 
> how long do you estimate it will take to change all our setups to have
> "writable" defined in the gadget, to pull out the generic code that
> creates "writable" today and have it properly replaced ? 
> 
> it wont help to discuss theoretical changes here if we can not manage
> to implement them before release while still not being able to create
> official images in the official ubuntu build system. 
> 
> the change that barry and I are discussing will not change anything in
> the images they will stay exactly identical to what we currently
> release but they will be buildable without having to locally hack your
> ubuntu-image so adam can start moving with the cdimage implementation.
> 
> ciao
>         oli
> -- 
> Devices mailing list
> Devices at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.snapcraft.io/mailman/listinfo/devices

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snapcraft.io/archives/devices/attachments/20161012/c58046fe/attachment.html>