================== Managing Resources ================== In EDP, users can browse over lists of current resources in their environment, filtering and combining them in groups. -------- Runtimes -------- In **Runtimes**, the entry view on the left lists the available runtime groups. Once a group is selected, all its components (single runtimes or other runtime groups) are listed. At this point, users can edit the groups's description, and define properties. The definition of properties is important to accentuate aspects and values that are central to identify and manage groups (as well as single runtimes). Through properties, runtimes and groups can be filtered, selected and combined. The value of those properties is also the way to dynamically associate - or disassociate - runtimes from fleets. For more information, see :ref:`this section `. Groups can help users with filtering and managing multiple runtimes, for example by simplifying the process of running a feature on a number of runtimes. Filters and properties are the best way to add new components to a group - being those components single runtimes or other runtime groups. .. figure:: ./image/runtime-group-edit-add.png :align: center :alt: add runtime to a group: edit :target: ./_static/runtime-group-edit-add.png :width: 600px Edit properties and add components to a runtime group. When adding new components to a runtime group, two new columns appear at the right side of the display, that act as containers to the added groups and / or single runtimes. A good way to "match" components to a group is filtering properties that share the same values. .. figure:: ./image/runtime-group-filter-add.png :align: center :alt: add runtime to a group: filter :target: ./_static/runtime-group-filter-add.png :width: 600px Filter and select the components that match to the group. After finding the desired match, click on the component and press "Add selected items". Or simply drag and drop the selected component to the columns on the right hand side. Install, Uninstall, Start, Stop =============================== By selecting a single runtime out of the list of available runtimes (Home menu), its status is displayed: type, architecture, operating system and environment. All bundles installed on the chosen runtime are listed, showing basic information such as id, symbolic name and version. In the context of the OSGi specification, a bundle's symbolic name, together with its version, serves as its unique identifier. The state of the bundles, which reflects their life cycle (*STARTING, ACTIVE, RESOLVED, INSTALLED*), is also shown, as are the possible actions related to each bundle: *start, stop, uninstall*. Note that users can only opt to uninstall a bundle once this has been previously stopped. In this area of the portal, users can install bundles on a selected runtime, as well as verify the version of an installed bundle. .. figure:: ./image/devices-details.png :align: center :alt: runtime details :target: ./_static/devices-details.png :width: 600px For each runtime, bundles are listed. Also at this point, users can remove runtimes from EDP. To do that, first they must select the runtime and follow by choosing “Remove runtime”, confirming then the action on the subsequent dialog window. .. admonition:: Please note that :class: my-custom-warning Currently EDP does not provide isolation between users’ runtimes when removing them. That means, users can remove any runtimes available in the environment defined in their permission profile, independently of who created them, or whether they are being used. Status, Type and Search ======================= The runtime status reports if the instance is online or offline. By starting a device which is connected to the cloud, its runtimes' status will show online; the shutdown will switch it to offline. Runtimes are associated to AWS “Thing” types. This allows EDP to store description and configuration information that is common to all runtimes associated with the same type. .. admonition:: On the "Thing" type :class: my-custom-note A “Thing” is defined in AWS IoT as a representation of a specific physical or logical entity. It can be a physical device or sensor; it can also be an instance of an application or a physical entity that does not connect to AWS IoT but is related to other devices that do. The use of a standard type (in EDP's case, "device") simplifies resource management by providing consistent registry data for runtimes that share the same type. On the other hand, types provide “Things” with a common set of attributes that describes identities and capabilities. Currently the type “device” is automatically predefined for all new runtimes. ------------------------ Registering a New Device ------------------------ Aicas can support customers by registering devices and providing certificates for them. However, in case of EDP clients with an own AWS account, their admins will assume these tasks. A complete step by step on connecting devices for EDP is given :doc:`here <./connecting-devices>`. In the AWS IoT services portal, it is possible for integrators and administrators to inspect and eventually edit attributes of devices. .. *Please note that: During registration, a new device certificate will be created and downloaded to the .. device. This certificate is named .p12 and gets embedded into the setup folder of the .. EDP Client bundle. Once incorporated to the OSGi framework, the EDP Client connects the device to .. the cloud.* Registration and Provisioning ============================= The EDP Client and a provisioning script are components that play a central role in provisioning and connecting new runtimes to EDP. When in the **Runtimes** area, users will see in the right side of their screens a button ``Connect Runtime``. .. figure:: ./image/runtime-connect.png :align: center :alt: runtime connections :target: ./_static/runtime-connect.png :width: 600px Access to runtimes's provisioning and connecting. Once clicked, users are offered three possibilities: Users can download a ``Provisioning Script Package``, download only a pre-configured ``Client Bundle`` or the combination ``AMS + Client Bundle`` The provisioning script configures the runtimes, by installing in them the client bundle, which is needed to establish the connection to EDP. By adapting the csv file provided in the downloaded zip package, it is possible to provision multiple runtimes at once. By choosing to just download the EDP client, users will get a pre-configured bundle that comes with all settings, certificates and properties required by EDP. All they need is to enter a runtime name and click on ``Register``. The bundle .jar file is prepared and downloaded, and the client is then ready to be installed in the runtime with the OSGi-based framework of choice. The connection is started immediately, with no necessary manual tasks. Finally the third option offers users to download aicas’ OSGi framework AMS already coupled with the pre-configured client bundle. In this case, users enter a runtime name, the operating system, architecture and version of the framework. Currently this option is only available for AMS. More details on these procedures can be found in :doc:`section Connecting Devices <./connecting-devices>`. .. figure:: ./image/runtime-connect-options.png :align: center :alt: runtime connection options :target: ./_static/runtime-connect-options.png :width: 600px Download the script, the client or also the OSGi framework. .. _fleets: ------ Fleets ------ An extension of the **Runtimes** view is offered under **Fleets**. Fleets are non-hierarchical groupings that define their contained individual runtimes and runtime groups by the use of property filters. When choosing the menu option **Fleets**, users can define these components, through establishing search properties that resolve the logical conditions and dynamically create them. .. figure:: ./image/create-fleets.png :align: center :alt: creating fleets :target: ./_static/create-fleets.png :width: 600px Create fleets and define properties. .. figure:: ./image/fleet-set-property.png :align: center :alt: defining fleet properties :target: ./_static/fleet-set-property.png :width: 600px Fleet criteria consist of multiple key-value pairs. Which runtimes and groups of runtimes meet the criteria to populate fleets is determined when you enter and edit your runtimes and groups in EDP. Users can dynamically set properties to groups and runtimes that will match (or exceed) the properties demanded by a fleet. .. figure:: ./image/runtime-group-properties.png :align: center :alt: setting properties for runtimes :target: ./_static/runtime-group-properties.png :width: 600px Runtimes and runtime groups can simultaneously belong to multiple fleets. ----------- Deployments ----------- EDP offers users the possibility to register various deployments from different sources to various targets. Sources would be feature versions or artifacts, while targets are runtime, runtime groups or fleets. For each deployment, users must enter description, source and target types. This helps to keep the overview of all deployments and improve managing them. In the list of deployments, one can follow up the status, if failed, pending or in progress. .. figure:: ./image/deployments1.png :align: center :alt: runtime detaisl :target: ./_static/deployments1.png :width: 600px Create new **Deployments**; status of existing ones are indicated. .. figure:: ./image/deployments2.png :align: center :alt: runtime detaisl :target: ./_static/deployments2.png :width: 600px After verifying the "Deployment View"; press "upload" to send to the target. The hamburger menu (three bars menu) in the deployment view offers action options that depend on the status. While a deployment is still "pending", users can opt to deploy it. Once started, the deployment's status changes into "in_progress". Users can then cancel it and define a time interval to auto refresh the view. This menu also offers to clear history or close the development view window. .. figure:: ./image/deploy-progress-view-options.png :align: center :alt: runtime detaisl :target: ./_static/deploy-progress-view-options.png :width: 600px "Deployment View" offers a menu of actions, depending on the status. EDP offers graphical views of deployments' progress in a timeline and also a percentage view of their final performance, in terms of successful termination. .. figure:: ./image/deploy-progress-status-timeline.png :align: center :alt: deployment progress over time :target: ./_static/deploy-progress-status-timeline.png :width: 600px View of deployments' progress over time. Let us say, a specific artifact is deployed in three runtimes. At a given moment in time it could have already been successfully run in one runtime, have failed in another and be in progress on the third one. EDP would show in green, red and gray the different states of the deployment in all three units. .. figure:: ./image/deploy-pie-chart.png :align: center :alt: runtime detaisl :target: ./_static/deploy-pie-chart.png :width: 600px View of the percentage of successful deployments. .. ---- .. Jobs .. ---- .. .. To access the list of available jobs, to upload new jobs or to delete selected ones, .. users can choose **Job documents** in EDP’s menu. .. .. A job is a user-defined set of tasks, where each task is a configured command supported .. by the EDP Client. Jobs are executed asynchronously on a runtime or a group of runtimes. .. .. .. admonition:: Job as AWS defines :class: my-custom-note A “Job” is defined in AWS IoT as a set of remote operations that is sent to and executed on one or more devices connected to the AWS cloud. For example, users can define a job that instructs a set of devices to download and install applications or firmware updates, reboot, rotate certificates, or perform remote troubleshooting operations. .. While in the **Runtimes** view, a user should click the ``Create job`` option to .. assign a job to a device, or group of devices. The user should then browse for .. a job file and choose where to run the job on. .. .. A job documents in JSON format an array of tasks to be executed in sequential order. .. The tasks defined in a job are commands that the EDP client can understand and execute. .. For example install a bundle by URL, install a bundle from an OSGi repository, start, stop or .. uninstall a bundle. .. .. .. code-block:: JSON { "tasks": [ { "id": 1, "apiVersion": "1.0.0", "type": "bundle-task", "action": "START", "symbolicName": "com.sample.bundle", "version": "1.0.0" }, { "id": 2, "apiVersion": "1.0.0", "type": "bundle-task", "action": "STOP", "symbolicName": "com.sample.bundle", "version": "1.0.0" } ] } .. .. As an example, above is a job with two tasks: start and stop a bundle. :doc:`← Previous Page ` | :doc:`Next Page → `