<method name="Upgrade"></method>
     <method name="Rollback"></method>
For these sorts of operations, one often puts in an in options argument,
of type a{sv} ... to future proof. For example:
   rpm-ostree rollback [OPTION...] - Revert to the previously booted tree
   -r, --reboot          Initiate a reboot after rollback is prepared
   rpm-ostree upgrade [OPTION...] - Perform a system upgrade
   --os=OSNAME           Operate on provided OSNAME
   -r, --reboot          Initiate a reboot after an upgrade is prepared
   --allow-downgrade     Permit deployment of chronologically older trees
   --check-diff          Check for upgrades and print package diff only
How are you planning on implementing these via the API? Some of them
seem to fit naturaly in such an options argument, whereas others are
probably separate method calls (eg: --check-diff), or implemented in the
client (eg: --reboot).