The State Engine

[Gustavo Niemeyer]

Hello again,

Besides the tweaks to interface terminology mentioned earlier today, we've
also used the sprint to iterate over the design of the State Engine.

The main problem we wanted to address was to come up with a design that
would allow tracking individual concurrent tasks (downloads, hook
executions, etc). On that basis we've remodeled the state engine entirely
focusing on solving these issues in a simple way.

The outcome so far is this v2 specification which we're starting work on
right away:

https://docs.google.com/document/d/1wvLXMTv7dhrDO28XIsN9h4VSSnVgLczklIAwgOuvR4M

There are still a few minor details to be defined, but the overall
structure seems sound.

Please let us know if you have any comments or questions.


On Wed, Feb 3, 2016 at 7:25 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> 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
>
>


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