The State Engine

[Gustavo Niemeyer]

Another one, with a more interesting specification.

One weak area we have in Snappy at the moment, and that will be addressed
in time for 16.04, is that it's not yet as transactional as it sounds.
This stems from the fact that most operations we need to perform for
setting up an operating system are not atomic, so we cannot in fact solve that
per se. What we can do, though, is to acknowledge the limitation, and
develop around it a good management infrastructure that is able to cope
with it, and move system state back and forth as necessary.

Conveniently enough, acknowledging and attempting to fix that is happening
just as we work on some major fundamental pieces of Snappy, and refactor
the internal organization of the code to be both simpler and more
structured.

With that background, here is a proposal for what may be seen as the Snappy
overlord system (if Michael allows me to borrow the term). This will be the
central piece from which subsystems will hang with more localized goals,
with some interaction between them in specific cases.

Besides solving the transactionality problem, this should also address
cleanly a number of open points we have in the system organization today,
such as:

- How are assertions applied and tracked as the system is changed?
- How are skill assignments tracked and changed as the system is changed?
- How to tell what *would* change if a snap is removed or updated?
- How to tell what *would* change if an assertion is updated?

... and other interesting integration improvements.

Without further delay, for your reviewing pleasure:

https://docs.google.com/a/canonical.com/document/d/10vwSj21eBTTTK-7ZmsBw1cD50fOmEDUADgOog-4OUdM

Pieces of that will start to show up next week as merge proposals.


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160203/ffc1c1e6/attachment.html>