Update docs

JosepSampe · JosepSampe · commit 2ffe98208db4 · 2024-05-30T16:11:05.000+02:00
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,12 +1,31 @@
 # Changelog
 
-## [v3.3.1.dev0]
+## [v3.4.1.dev0]
+
+### Added
+- 
+
+### Changed
+- 
+
+### Fixed
+- 
+
+## [v3.4.0]
 
 ### Added
 - [CLI] Allow to pass a name in the "lithops runtime list" command
 - [Ceph] Added extra region parameter to Ceph backend
 
 ### Changed
+- [Setup] Moved IBM dependencies to lithops[ibm] extra
+- [Setup] Moved AWS dependencies to lithops[aws] extra
+- [Setup] Moved kubernetes dependencies to lithops[kubernetes] extra
+- [Setup] Moved knative dependencies to lithops[knative] extra
+- [Setup] Moved minio dependencies to lithops[minio] extra
+- [Setup] Moved ceph dependencies to lithops[ceph] extra
+- [Setup] Moved redis dependencies to lithops[redis] extra
+- [Setup] Moved matplotlib, seaborn, numpy and pandas dependencies to lithops[plotting] extra
 - [Setup] Removed unused 'lxml', 'docker' and 'python-dateutil' packages from the setup.py
 - [Core] Detached progress bar from INFO logs
 - [Future] Exposed 'wait_dur_sec' and 'retries' in future.wait() and future.get_result() methods
@@ -21,6 +40,7 @@
 - [Swift] Fixed OpenStack Swift parameters and authentication by adding domain information
 - [AWS Batch] Fixed missing ecsTaskJobRole
 
+
 ## [v3.3.0]
 
 ### Added
diff --git a/docs/source/api_stats.rst b/docs/source/api_stats.rst
@@ -10,6 +10,12 @@ Execution summary plots
 
 The :code:`plot()` method from :code:`FunctionExecutor` creates a scatter plot and a histogram plot showing a summary of the tasks executed by a :code:`FunctionExecutor`. By default, lithops creates a :code:`plots/` directory in the working directory path containing both plots in PNG format. For more details refer to the `FunctionExecutor API reference <https://lithops-cloud.github.io/docs/source/api_futures.html>`_.
 
+To get started, first install Lithops and the plotting dependencies with:
+
+.. code-block:: bash
+
+   python3 -m pip install lithops[plotting]
+
 * **Scatter Plot**: the scatter plot shows a timeline on the horizontal axis where the stages of all invocations are arranged on the vertical axis.
     - :code:`host submit` indicates the time that the orchestrator process has invoked the function.
     - :code:`call start` indicates the timestamp at which the function starts its execution.
diff --git a/docs/source/compute_config/code_engine.md b/docs/source/compute_config/code_engine.md
@@ -2,8 +2,13 @@
 
 [IBM Code Engine](https://cloud.ibm.com/codeengine/overview) allows you to run your application, job or container on a managed serverless platform. Auto-scale workloads and only pay for the resources you consume.
 
-IBM Code Engine exposes both Knative and Kubernetes Job Descriptor API. Lithops supports both of them. Follow IBM Code Engine documentation to get more details on the difference between those APIs.
+## Installation
 
+1. Install IBM Cloud backend dependencies:
+
+```bash
+python3 -m pip install lithops[ibm]
+```
 
 ## Configuration
 
@@ -13,7 +18,7 @@ IBM Code Engine exposes both Knative and Kubernetes Job Descriptor API. Lithops
 
 3. Copy the generated IAM API key (You can only see the key the first time you create it, so make sure to copy it).
 
-4. Naviagete to the [resource groups dashboard](https://cloud.ibm.com/account/resource-groups), and copy the desired resource group ID.
+4. Navigate to the [resource groups dashboard](https://cloud.ibm.com/account/resource-groups), and copy the desired resource group ID.
 
 5. Edit your lithops config and add the following keys:
 
@@ -85,7 +90,7 @@ code_engine:
     ....
     docker_server    : docker.io
     docker_user      : <container registry username>
-    docker_password  : <container registry access TOEKN>
+    docker_password  : <container registry access TOKEN>
 ```
 
 #### Configure IBM Container Registry
diff --git a/docs/source/compute_config/ibm_cf.md b/docs/source/compute_config/ibm_cf.md
@@ -22,7 +22,7 @@ python3 -m pip install lithops[ibm]
 
 4. Copy the generated IAM API key (You can only see the key the first time you create it, so make sure to copy it).
 
-5. Naviagete to the [resource groups dashboard](https://cloud.ibm.com/account/resource-groups), and copy the desired resource group ID.
+5. Navigate to the [resource groups dashboard](https://cloud.ibm.com/account/resource-groups), and copy the desired resource group ID.
 
 5. Edit your lithops config and add the following keys:
 
@@ -50,8 +50,8 @@ python3 -m pip install lithops[ibm]
 
 |Group|Key|Default|Mandatory|Additional info|
 |---|---|---|---|---|
-|ibm_cf| namespace | |no | Value of CURRENT NAMESPACE from [here](https://cloud.ibm.com/functions/namespace-settings). Provide it if you want to use an existsing `namespace`. Lithops will automatically create a new namespace if not provided.|
-|ibm_cf| namespace_id |  |no |  Value of 'GUID' from [here](https://cloud.ibm.com/functions/namespace-settings). Provide it if you want to use an existsing `namespace`. Provide it along with `namespace`.|
+|ibm_cf| namespace | |no | Value of CURRENT NAMESPACE from [here](https://cloud.ibm.com/functions/namespace-settings). Provide it if you want to use an existing `namespace`. Lithops will automatically create a new namespace if not provided.|
+|ibm_cf| namespace_id |  |no |  Value of 'GUID' from [here](https://cloud.ibm.com/functions/namespace-settings). Provide it if you want to use an existing `namespace`. Provide it along with `namespace`.|
 |ibm_cf | region | |no | Service region. One of: `jp-tok`, `au-syd`, `eu-gb`, `eu-de`, `us-south`, `us-east`. Lithops will use the `region` set under the `ibm` section if it is not set here |
 |ibm_cf| endpoint | |no | IBM Cloud Functions endpoint (if region not provided). Make sure to use https:// prefix, for example: https://us-east.functions.cloud.ibm.com |
 |ibm_cf | max_workers | 1200 | no | Max number of workers per `FunctionExecutor()`|
diff --git a/docs/source/compute_config/ibm_vpc.md b/docs/source/compute_config/ibm_vpc.md
@@ -2,13 +2,21 @@
 
 The IBM VPC client of Lithops can provide a truely serverless user experience on top of IBM VPC where Lithops creates new VSIs (Virtual Server Instance) dynamically in runtime, and scale Lithops jobs against them. Alternatively Lithops can start and stop an existing VSI instances.
 
+## Installation
+
+1. Install IBM Cloud backend dependencies:
+
+```bash
+python3 -m pip install lithops[ibm]
+```
+
 ## IBM VPC
 The assumption that you already familiar with IBM Cloud, have your IBM IAM API key created (you can create new keys [here](https://cloud.ibm.com/iam/apikeys)), have valid IBM COS account, region and resource group.
 
-Follow [IBM VPC setup](https://cloud.ibm.com/vpc-ext/overview) if you need to create IBM Virtual Private Cloud. Decide the region for your VPC. The best practice is to use the same region both for VPC and IBM COS, hoewever there is no requirement to keep them in the same region.
+Follow [IBM VPC setup](https://cloud.ibm.com/vpc-ext/overview) if you need to create IBM Virtual Private Cloud. Decide the region for your VPC. The best practice is to use the same region both for VPC and IBM COS, however there is no requirement to keep them in the same region.
 
 ## Choose an operating system image for VSI
-Any Virtual Service Instance (VSI) need to define the instance’s operating system and version. Lithops support both standard Ubuntu operting system choices provided by the VPC and using pre-defined custom images that already contains all dependencies required by Lithops.
+Any Virtual Service Instance (VSI) need to define the instance’s operating system and version. Lithops support both standard Ubuntu operating system choices provided by the VPC and using pre-defined custom images that already contains all dependencies required by Lithops.
 
 - Option 1: Lithops is compatible with any Ubuntu 22.04 image provided in IBM Cloud. In this case, no further action is required and you can continue to the next step. Lithops will install all required dependencies in the VSI by itself. Notice this can consume about 3 min to complete all installations.
 
@@ -81,7 +89,7 @@ ibm_vpc:
 |ibm_vpc | subnet_id | | no | Subnet id of an existing VPC. Get it from [here](https://cloud.ibm.com/vpc-ext/network/subnets)|
 |ibm_vpc | ssh_key_id | | no | SSH public key id. Get it from [here](https://cloud.ibm.com/vpc-ext/compute/sshKeys)|
 |ibm_vpc | gateway_id | | no | Gateway id. Get it from [here](https://cloud.ibm.com/vpc-ext/network/publicGateways)|
-|ibm_vpc | image_id | | no | Virtual machine image id. Default is Ubutnu Server 22.04 |
+|ibm_vpc | image_id | | no | Virtual machine image id. Default is Ubuntu Server 22.04 |
 |ibm_vpc | runtime | python3 | no | Runtime name to run the functions. Can be a container image name. If not set Lithops will use the default python3 interpreter of the VM |
 |ibm_vpc | ssh_username | root |no | Username to access the VM |
 |ibm_vpc | ssh_password |  |no | Password for accessing the worker VMs. If not provided, it is created randomly|
@@ -91,15 +99,15 @@ ibm_vpc:
 |ibm_vpc | worker_profile_name | cx2-2x4 | no | Profile name for the worker VMs |
 |ibm_vpc | master_profile_name | cx2-2x4 | no | Profile name for the master VM |
 |ibm_vpc | verify_resources | True | no | Verify the resources that are stored in the local cache, and expected to be already created (VPC, subnet, floating IP, etc.), exist every time a `FunctionExecutor()` is created |
-|ibm_vpc | delete_on_dismantle | True | no | Delete the worekr VMs when they are stopped |
+|ibm_vpc | delete_on_dismantle | True | no | Delete the worker VMs when they are stopped |
 |ibm_vpc | max_workers | 100 | no | Max number of workers per `FunctionExecutor()`|
 |ibm_vpc | worker_processes | AUTO | no | Number of Lithops processes within a given worker. This is used to parallelize function activations within a worker. By default it detects the amount of CPUs in the worker VM|
 |ibm_vpc | auto_dismantle | True |no | If False then the VM is not stopped automatically.|
 |ibm_vpc | soft_dismantle_timeout | 300 |no| Time in seconds to stop the VM instance after a job **completed** its execution |
 |ibm_vpc | hard_dismantle_timeout | 3600 | no | Time in seconds to stop the VM instance after a job **started** its execution |
 |ibm_vpc | exec_mode | reuse | no | One of: **consume**, **create** or **reuse**. If set to  **create**, Lithops will automatically create new VMs for each map() call based on the number of elements in iterdata. If set to **reuse** will try to reuse running workers if exist |
 |ibm_vpc | singlesocket | False | no | Try to allocate workers with single socket CPU. If eventually running on multiple socket, a warning message printed to user. Is **True** standalone **workers_policy** must be set to **strict** to trace workers states|
-|ibm_vpc | gpu | False | no | If True docker started with gpu support. Requires host to have neccessary hardware and software preconfigured and docker image runtime with gpu support specified |
+|ibm_vpc | gpu | False | no | If `True` docker started with gpu support. Requires host to have necessary hardware and software pre-configured, and docker image runtime with gpu support specified |
 
 ## Lithops and the VSI consume mode
 
@@ -146,11 +154,11 @@ If you need to create new VM, then follow the steps to create and update Lithops
 |---|---|---|---|---|
 |ibm_vpc | region | |yes | VPC Region. For example `us-south`. Choose one region from [here](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc). Lithops will use the region set under the `ibm` section if it is not set here |
 |ibm_vpc | instance_id | | yes | virtual server instance ID |
-|ibm_vpc | floating_ip | | yes | Floatting IP address atached to your VM instance|
+|ibm_vpc | floating_ip | | yes | Floating IP address attached to your VM instance|
 |ibm_vpc | ssh_username | root |no | Username to access the VM |
 |ibm_vpc | ssh_key_filename | ~/.ssh/id_rsa | no | Path to the ssh key file provided to create the VM. It will use the default path if not provided |
 |ibm_vpc | worker_processes | AUTO | no | Number of Lithops processes within a given worker. This is used to parallelize function activations within the worker. By default it detects the amount of CPUs in the VM|
-|ibm_vpc | runtime | python3 | no | Runtime name to run the functions. Can be a container image name. If not set Lithops will use the defeuv python3 interpreter of the VM |
+|ibm_vpc | runtime | python3 | no | Runtime name to run the functions. Can be a container image name. If not set Lithops will use the default `python3` interpreter of the VM |
 |ibm_vpc | auto_dismantle | True |no | If False then the VM is not stopped automatically.|
 |ibm_vpc | soft_dismantle_timeout | 300 |no| Time in seconds to stop the VM instance after a job **completed** its execution |
 |ibm_vpc | hard_dismantle_timeout | 3600 | no | Time in seconds to stop the VM instance after a job **started** its execution |
@@ -174,7 +182,7 @@ lithops logs poll
 
 ## VM Management
 
-Lithops for IBM VPC follows a Mater-Worker architecrue (1:N).
+Lithops for IBM VPC follows a Mater-Worker architecture (1:N).
 
 All the VMs, including the master VM, are automatically stopped after a configurable timeout (see hard/soft dismantle timeouts).
 
diff --git a/docs/source/sklearn_joblib.rst b/docs/source/sklearn_joblib.rst
@@ -3,7 +3,7 @@ Distributed Scikit-learn / Joblib
 
 Lithops supports running distributed scikit-learn programs by implementing a Lithops backend for joblib using Functions instead of local processes. This makes it easy to scale existing applications that use scikit-learn from a single node to a cluster.
 
-To get started, first install Lithops and the joblib dependecies with:
+To get started, first install Lithops and the joblib dependencies with:
 
 .. code-block:: bash
 
diff --git a/docs/source/storage_config/ibm_cos.md b/docs/source/storage_config/ibm_cos.md
@@ -1,9 +1,7 @@
 # IBM Cloud Object Storage
 
-
 Lithops with IBM COS as storage backend.
 
-
 ## Installation
 
 1. Install IBM Cloud backend dependencies:
@@ -93,7 +91,7 @@ python3 -m pip install lithops[ibm]
 ## Lithops COS Endpoint configuration
 
 ### Using region
-The easiest apporach is to let Lithops to choose the right endpoint by itself. To enable this, just configure Lithops with the region name of your `storage_bucket`, as follows:
+The easiest approach is to let Lithops to choose the right endpoint by itself. To enable this, just configure Lithops with the region name of your `storage_bucket`, as follows:
 
 ```yaml
     ibm_cos:
