classic mode (v1)

Gustavo Niemeyer gustavo.niemeyer at
Tue Nov 24 15:23:53 UTC 2015

On Tue, Nov 24, 2015 at 12:40 PM, Mark Shuttleworth <mark at> wrote:

> On 23/11/15 17:28, Gustavo Niemeyer wrote:
> > The agreement in the sprint was to use an overlay, IIRC. You might
> remember
> > us discussing this inside the glassy room, where we talked about the fact
> > this is similar in nature to how the live CD works.
> >
> > It sounds like there's a distinction being driven there which I don't
> quite
> > follow, though. The overlay-on-classic-snap-content is still a one-time
> > exercise until reset. (?)
> Based on Pitti's feedback on overlays, I think we come out at:

If possible, I'd like to understand what the actual issues are before we
take a stance on this.

> * the classic filesystem is read-write in the "classic"
> framework's writeable space

* this filesystem will initially be close to the current core snap (if we
> unpack that plus delta)

* that filesystem will drift relative to the core snap, based on relative
> updates and deb installs

* that filesystem is persistent until reset

All of these points are similar in both approaches. The difference is only
whether we write it all in the writable space, or just the overlay deltas.

>  * for now, no processes persist in the classic dimension when the user
> exits the classic shell

That sounds like a bad idea. I wouldn't like to see my 3h build killed
because ssh disconnected.

> I think it's likely that unpacking the core OS snap plus a delta is the
> fastest way to make that filesystem given what's available on the
> machine (the delta will be a small download). Initially this might be
> implemented as a debootstrap or even just unpacking the LXD images we
> publish (from which the Core OS snap is derived).

That final plan and the initial plan to get something going quickly are
also very similar in both approaches. The distinction is only whether to
unpack or not.

gustavo @
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list