<div dir="ltr"><div><span style="font-size:12.8000001907349px">Another one, with a more interesting specification.</span><br clear="all" style="font-size:12.8000001907349px"><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">One weak area we have in Snappy at the moment, and that will be addressed in time for 16.04, <span style="font-size:12.8000001907349px">is that it's not yet as transactional as it sounds.  This stems from the fact that most operations we </span><span style="font-size:12.8000001907349px">need to perform for setting up an operating system are not atomic, so we cannot in fact solve </span><span style="font-size:12.8000001907349px">that per se. What we can do, though, is to acknowledge the limitation, and develop around it </span><span style="font-size:12.8000001907349px">a good management infrastructure that is able to cope with it, and move system state back and forth </span><span style="font-size:12.8000001907349px">as necessary.</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Conveniently enough, acknowledging and attempting to fix that is happening just as we work on <span style="font-size:12.8000001907349px">some major fundamental pieces of Snappy, and refactor the internal organization of the code to be </span><span style="font-size:12.8000001907349px">both simpler and more structured.</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">With that background, here is a proposal for what may be seen as the Snappy overlord system <span style="font-size:12.8000001907349px">(if Michael allows me to borrow the term). This will be the central piece from which subsystems will </span><span style="font-size:12.8000001907349px">hang with more localized goals, with some interaction between them in specific cases.</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><div>Besides solving the transactionality problem, this should also address cleanly a number of open <span style="font-size:12.8000001907349px">points we have in the system organization today, such as:</span></div><div><br></div><div>- How are assertions applied and tracked as the system is changed?</div><div>- How are skill assignments tracked and changed as the system is changed?</div><div>- How to tell what *would* change if a snap is removed or updated?<br></div><div>- How to tell what *would* change if an assertion is updated?</div><div><br></div><div>... and other interesting integration improvements.</div><div><br></div><div>Without further delay, for your reviewing pleasure:</div></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><a href="https://docs.google.com/a/canonical.com/document/d/10vwSj21eBTTTK-7ZmsBw1cD50fOmEDUADgOog-4OUdM" target="_blank">https://docs.google.com/a/canonical.com/document/d/10vwSj21eBTTTK-7ZmsBw1cD50fOmEDUADgOog-4OUdM</a><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Pieces of that will start to show up next week as merge proposals.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">gustavo @ <a href="http://niemeyer.net/" target="_blank">http://niemeyer.net</a></div></div><div style="font-size:12.8000001907349px"><br></div><div>
</div></div>