diff --git a/developer_manual/exapp_development/tech_details/InstallationFlow.rst b/developer_manual/exapp_development/tech_details/InstallationFlow.rst index 17fafa893..e3905a3cf 100644 --- a/developer_manual/exapp_development/tech_details/InstallationFlow.rst +++ b/developer_manual/exapp_development/tech_details/InstallationFlow.rst @@ -3,12 +3,12 @@ App Installation Flow ===================== -Image Pulling(Docker) ---------------------- +Image Pulling (Docker) +---------------------- AppAPI **2.5.0+** will always first try to pull a docker image with a ``suffix`` equal to value of *computeDevice*. -Let us remind you that ``computeDevice`` can take the following values: ``cpu``, ``cuda``, ``rocm`` +The following values are available for ``computeDevice``: ``cpu``, ``cuda``, or ``rocm``. The suffix will be added as follows: @@ -17,22 +17,22 @@ The suffix will be added as follows: return $imageParams['image_src'] . '/' . $imageParams['image_name'] . '-' . $daemonConfig['computeDevice']['id'] . ':' . $imageParams['image_tag']; -For ``cpu`` AppAPI will first try to get the image from ``ghcr.io/cloud-py-api/skeleton-cpu:latest``. +For ``cpu``, AppAPI will first try to get the image from ``ghcr.io/cloud-py-api/skeleton-cpu:latest``. In case the image is not found, ``ghcr.io/cloud-py-api/skeleton:latest`` will be pulled. -If you as an application developer want to have a custom images for any of these values, you can push that extended images to registry in addition to the based one. +If you as an application developer want to have a custom images for any of these values, you can push the extended images to registry in addition to the base one. Heartbeat --------- -The first thing AppAPI does is deploy of the application. +The first thing AppAPI does is deploy the application. -In the case of ``Docker``, this is: +In the case of Docker, this means: -#. 1. performing an image pull -#. 2. creating container from the docker image -#. 3. if the container supports `healthcheck` - AppAPI waits for the `healthy` status -#. 4. waiting until the “/heartbeat” endpoint becomes available with a ``GET`` request +1. performing an image pull +2. creating container from the docker image +3. if the container supports `healthcheck` - AppAPI waits for the `healthy` status +4. waiting until the “/heartbeat” endpoint becomes available with a ``GET`` request The application, in response to the request "/heartbeat", should return json: ``{"status": "ok"}``. @@ -44,15 +44,15 @@ Init .. note:: Starting from this point, all requests made by AppAPI contains :ref:`auth-headers`. After application is ready, which is determined by previous step, -AppAPI sends ``POST`` request to the ``/init`` application endpoint. +AppAPI sends a ``POST`` request to the ``/init`` application endpoint. *If the application does not need to carry out long initialization, it has an option to not implement "/init" endpoint, so -AppAPI will get 404 or 501 error on it's request, and consider that initialization is done and this section can be skipped.* +AppAPI will get 404 or 501 error on it's request, but you can consider that initialization to be done and this section can be skipped.* In case you want to implement "/init" endpoint, your application should: -1. In "/init" handler: Response with empty JSON on AppAPI call. -2. In background job: Send an ``OCS request`` to ``PUT /ocs/v1.php/apps/app_api/ex-app/status`` with the progress value. +1. In "/init" handler: return a Response with empty JSON data on AppAPI call. +2. In background job: send an OCS request to ``PUT /ocs/v1.php/apps/app_api/ex-app/status`` with the progress value. .. warning:: @@ -75,7 +75,7 @@ Example of request payload with error will look like this:: Enabled ------- -After receiving **progress: 100** (*or when ExApp is not implementing "/init" endpoint*), AppAPI enables the application. +After receiving **progress: 100** (*or when ExApp is not implementing the "/init" endpoint*), AppAPI enables the application. To enable or disable the application, a PUT request is sent to the ``/enabled`` endpoint. @@ -96,17 +96,17 @@ Similarly, to disable the application, the request would be:: This approach ensures that the application's state can be easily toggled using a simple query parameter. -.. note:: ``/enabled`` endpoint shares both **enabling** and **disabling**, - so app should determine what is going on using the ``enabled`` input parameter of the request. +.. note:: The ``/enabled`` endpoint shares both **enabling** and **disabling**, + so the app should determine what is going on using the ``enabled`` input parameter of the request. -Inside ``/enabled`` handler application should register all actions related to the Nextcloud, like UI and all other stuff. +Inside the ``/enabled`` handler, the application should register all actions related to the Nextcloud, such as the UI and other stuff. -Response for this request should contain:: +The response for this request should contain:: {"error": ""} -for success and if some error occur during **enabling**, it should be present and not be empty:: +for success, and if some error occurs during **enabling**, it should be present and not be empty:: {"error": "i can't handle enabling"} -This is all three steps involved in the applications installation flow. +This is all three steps involved in the ExApp installation flow.