Refactoring skeleton flash control

[Patrick Williams]

On Wed, Nov 16, 2016 at 05:06:27PM -0800, Abhishek Pandit wrote:
> Important use cases (from REST perspective):
> >     - How does a user identify which levels are installed?  Which levels
> >       are activated?  Which levels are kept for optional downgrade?
> >       Which levels are stored on redundant media (ex. dual side flash).
> >     - How does a user upload new levels?
> >     - How does a user request a level to be activated?
> 
> 
> Our traditional approach is host managed. +raltherr might have some more
> thoughts on this for more bmc-centric software management.

Keep in mind that on most systems, the REST API will be present, which
means all DBus interfaces become, by default, available there as well.
This is a big part of why I am proposing the interface model be "data
oriented" rather than "method oriented", for lack of better words.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161116/43213dd6/attachment.sig>