<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 12:40 PM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 23/11/15 17:28, Gustavo Niemeyer wrote:<br>
> The agreement in the sprint was to use an overlay, IIRC. You might remember<br>
> us discussing this inside the glassy room, where we talked about the fact<br>
> this is similar in nature to how the live CD works.<br>
><br>
> It sounds like there's a distinction being driven there which I don't quite<br>
> follow, though. The overlay-on-classic-snap-content is still a one-time<br>
> exercise until reset. (?)<br>
<br>
</span>Based on Pitti's feedback on overlays, I think we come out at:<br></blockquote><div><br></div><div>If possible, I'd like to understand what the actual issues are before we take a stance on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* the classic filesystem is read-write in the "classic" framework's writeable space</blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* this filesystem will initially be close to the current core snap (if we unpack that plus delta) </blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> * that filesystem will drift relative to the core snap, based on relative updates and deb installs </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> * that filesystem is persistent until reset</blockquote><div> </div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 * for now, no processes persist in the classic dimension when the user<br>
exits the classic shell<br></blockquote><div><br></div><div>That sounds like a bad idea. I wouldn't like to see my 3h build killed because ssh disconnected.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think it's likely that unpacking the core OS snap plus a delta is the<br>
fastest way to make that filesystem given what's available on the<br>
machine (the delta will be a small download). Initially this might be<br>
implemented as a debootstrap or even just unpacking the LXD images we<br>
publish (from which the Core OS snap is derived).<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div><br></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br></div></div>
</div></div>