Refactoring skeleton flash control

[Patrick Williams]

Abhishek,

On Mon, Nov 14, 2016 at 11:09:30AM -0800, Abhishek Pandit wrote:
> Hey Adriana,
> 
> I've started with how I think the dbus interface should behave:
> https://gerrit.openbmc-project.xyz/#/c/1166/.

I would like to see some better modeling in place for management of code
levels.  There may be some overlap with what you are proposing, but you
do seem focused on flashing specifically.  Look this over and let me
know what you think, how much overlap there is, and how much you want to
tackle now.  We could do some things like temporarily define the
interface in org.openbmc, to indicate eventual deprecation, but allow
you to continue making progress on the function.

-------------------------

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?

Interface modeling:
    interface xyz.openbmc_project.Software.Level:
        property - string Name
                 - string Version
                 - enum Persistence { "Temporary", "Persisted" }
                 - enum State { "Loading", "Verified", "Failed", "Available" }
    interface xyz.openbmc_project.FilePath:
        < Attached to Software.Level object for images resident on the
          BMC and not in flash modules only. Ex. tmpfs >
        property - string Path

    interface xyz.openbmc_project.Object.Association:
        < Associate Software.Level <-> Inventory.Item >
    interface xyz.openbmc_project.Software.Activation:
        < Attached to Object.Assocation object >
        property - enum Activation { "Ready", "Activating", "Backup",
                                     "Active"
                   enum RequestedActivation { "None", "Backup", 
                                              "Active" }
                   integer Progress

    interface xyz.openbmc_project.Object.Add:
        Used to 'put' new image via HTTPS.  Need to confirm with Brad.
    interface xyz.openbmc_project.Object.Delete:
        Used to 'delete' images (from filesystem).

Object modeling:
    /xyz/openbmc_project/software:
        Owned by "DownloadManager" which supports Object.Add interface.  This
        can be called by REST when a user uploads a new level.  Later,
        we could attach additional interfaces here, possibly owned by
        other processes, such as 'Software.DownloadViaTFTP'.

    /xyz/openbmc_project/software/<id>:
        Owned by "DownloadManager" for images which are resident in
        tmpfs and a local filesystem ("Available" images).  Owned by
        "HostUpdater", "BMCUpdater", etc. for images which are resident
        in flash modules ("Active", "Backup").

    /xyz/openbmc_project/software/<id>/imageFor:
        Owned by "...Updater" processes and supports the
        Object.Association and Software.Activation interfaces.

Use case solutions:
    - How does a user identify which levels are installed?
        Enumerate /xyz/openbmc_project/software/
    - ... are activated?
        List /xyz/openbmc_project/software/ , look at Activation state
        on assocations.
    - ... are kept for optional downgrade?
        List /xyz/openbmc_project/software/ , see images "Persisted",
        "Available" and not ("Active" or "Backup").
    - How does a user upload new levels?
        Do a HTTP PUT to /xyz/openbmc_project/software/<id>.
    - How does a user request a level to be activated?
        Set RequestedActivation to "Active", "...Updater" process will
        begin activation.
> 
> The overall plan for the flash interface in my head:
> 
>    - REST (or some other) interface receives image + signature to update
>    flash
>       - Gets saved to filesystem and flash control is called
>    - Flash control loads the files into memory and verifies the signature
>       - Reference implementation would probably just be pgp

We have used OpenSSL interfaces for other projects.  I'm not stuck on
that though.

>    - Flash control locks the flash device
>       - This needs some more thought and probably new dbus interfaces;
>       important for host flash

Yeah, could certainly be a new interface for this on the same object as
Software.Activation.

>    - Image written to flash
>    - Lock on flash device released
>    - Signal asserted (Done)

Handled by org.freedesktop.Object.PropertyChanged signal on
"Activation" in my modeling above.

-----------------

This is just what I had floating around in the back of my head of what
we would [eventually] do for code update.  I have some past experience with 
CIM and I believe this conceptually lines up with what CIM and Redfish have
both done.  I'm certainly not fixed on any particular interface, property,
or enumeration names.

-- 
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/20161115/0057bdc8/attachment.sig>