c8c7f81be5
gdbus-codegen is picky about what it lets through. You have to check that what you write actually gets rendered in the resulting HTML BTW there are remnants documenting an abandoned Agama.Network design: TODO: remove it https://github.com/search?q=repo%3Aagama-project%2Fagama+%2Forg.*Agama.*Network%2F&type=code
97 lines
3.5 KiB
XML
97 lines
3.5 KiB
XML
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
|
|
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
|
|
<node name="/org/opensuse/Agama/Manager1">
|
|
<interface name="org.opensuse.Agama.Manager1">
|
|
<method name="Probe">
|
|
</method>
|
|
<method name="Commit">
|
|
</method>
|
|
<method name="CanInstall">
|
|
<arg name="result" direction="out" type="b"/>
|
|
</method>
|
|
<method name="CollectLogs">
|
|
<arg name="tarball_filesystem_path" direction="out" type="s"/>
|
|
</method>
|
|
<!--
|
|
Finish:
|
|
|
|
Possible values are: "stop", "reboot", "poweroff", "halt"
|
|
|
|
* *stop*:
|
|
Finish the installation without rebooting or shutting down the machine in order
|
|
to inspect it.
|
|
|
|
* *reboot*:
|
|
Finish the installation rebooting into the installed system.
|
|
|
|
* *poweroff*:
|
|
Finish the installation calling shutdown -P
|
|
|
|
* *halt*:
|
|
Finish the installation calling shutdown -H
|
|
|
|
-->
|
|
<method name="Finish">
|
|
<arg name="method" direction="in" type="s"/>
|
|
<arg name="result" direction="out" type="b"/>
|
|
</method>
|
|
|
|
<!--
|
|
InstallationPhases:
|
|
|
|
All possible phases:
|
|
<programlisting>
|
|
[
|
|
{"id" => 0, "label" => "startup"},
|
|
{"id" => 1, "label" => "config"},
|
|
{"id" => 2, "label" => "install"}
|
|
]
|
|
</programlisting>
|
|
|
|
The installation process follows a set of phases. Only the main service (`Agama::Manager`)
|
|
knows the information about the current installation phase. The rest of services will act as utility
|
|
services without any knowledge about the whole installation process.
|
|
|
|
A client (e.g., a web UI) will ask to the main service for the current phase of the installation.
|
|
|
|
In principle, the installation will follow 3 possible phases: *Startup*, *Config* and *Install*.
|
|
|
|
* *Startup* Phase:
|
|
This is the initial phase. The manager service will start in this phase and it will not change to
|
|
another phase until the client asks for performing the next phase.
|
|
|
|
* *Config* Phase:
|
|
The installation is configured during this phase. Configuring the installation means that everything
|
|
needed from the system is read and the required default proposal are calculated. In YaST terms, the
|
|
*config* phase implies to probe some modules like storage, language, etc, and to perform their
|
|
proposals. Note that not all modules have to be probed/proposed. Probing some modules could be
|
|
delayed to the next *install* phase.
|
|
|
|
* *Install* Phase:
|
|
This phase implies to perform everything to install the system according to the selected options and
|
|
proposals. Note that this phase is not only a typical YaST commit. For example, some proposals
|
|
(software?) could be done during this phase. In short, at the beginning of this phase we have all
|
|
the required information to perform the installation, and at the end of the phase the system is
|
|
installed.
|
|
-->
|
|
<property type="aa{sv}" name="InstallationPhases" access="read"/>
|
|
|
|
<!--
|
|
CurrentInstallationPhase:
|
|
Id of the current phase.
|
|
-->
|
|
<property type="u" name="CurrentInstallationPhase" access="read"/>
|
|
|
|
<property access="read" name="IguanaBackend" type="b"></property>
|
|
|
|
<!--
|
|
CurrentInstallationPhase:
|
|
List of names of the currently busy services.
|
|
|
|
Note that the services are blocked meanwhile they are performing a long task. For this
|
|
reason, the *manager* service will store the status of each service and the clients will ask to
|
|
*manager* to know that status.
|
|
-->
|
|
<property type="as" name="BusyServices" access="read"/>
|
|
</interface>
|
|
</node>
|