bmcweb image upload

[Ed Tanous]

On 4/25/19 2:01 AM, Wim Vervoorn wrote:
> Hello,
> 
> I have an AST2400 OpenBmc with 128 MB of RAM. I found that the firmware upload using WebUI (and Redfish) doesn't work. Bmcweb is killed due to an out of memory condition.
> 
> If found out this is due to the large request size of 30 MB. Will there be an update to the upload mechanism to resolve this large memory requirement?
> 

Running bmcweb on a 128MB ram system has been on my list to try for a
long time.  It's good to know at least some things function.

I don't know of anyone planning on improving the memory usage at this
point.  The systems I support have 512MB of ram, so our systems have
plenty of headroom.  The existing mechanism was definitely a cop-out
from a memory perspective when the implementation was first done;  The
whole payload was buffered in memory before writing to the filesystem,
mostly because of history: Crow didn't have support for incremental
upload or streaming of "normal" HTTP requests or chunk transfer
encoding.  These days the boost::beast internals can support streaming
the payload directly to somewhere, we would just need to expose the
appropriate buffers to bmcweb.

This could definitely be improved.

If I were to go about fixing this, my plan would be:
1. Come up with an amended DBus/filesystem interface that allows
chunking a response directly into flash.  This would probably be a unix
socket, or chunk based dbus interface like venture uses.  As you've
already found, internally the update packages use tarball, so we would
have to stream the decompression of files in the tarball, or use a
different format.
2. Expose a new url registration type in bmcweb that can accept a socket
or buffer object as a parameter.  This is similar to how websocket
upgrade works, just in different conditions when it would get invoked.
3. ??????
4. Profit.