Abstract: In one example, a computing node includes a metric dependency graph knowledge base to store a data structure representing a relationship between a plurality of metrics. Further, the computing node may include a processor and a memory having a metric recommendation unit. The metric recommendation unit may determine a first metric of a monitored computing-instance while a user interacts with a GUI of a monitoring application. Further, the metric recommendation unit may retrieve the data structure corresponding to the first metric. The data structure may include the first metric and a plurality of dependent metrics associated with the first metric. Further, the metric recommendation unit may apply a machine learning model on the data structure to determine a second metric from the plurality of dependent metrics. Furthermore, the metric recommendation unit may output the second metric related to the first metric on the GUI.

Abstract: Techniques for determining host computing systems to deploy virtual machines based on disk specifications are disclosed. In one example, a blueprint to deploy a virtual machine in a cloud computing environment may be received. Further, disk specifications required to deploy the virtual machine may be retrieved from the blueprint. Furthermore, candidate storage entities that support the retrieved disk specifications may be determined. A host computing system that has connectivity to the candidate storage entities may be determined. the determined host computing system may be recommended to deploy the virtual machine.

Abstract: Various examples are disclosed for performing dynamic chains of action for Internet-of-Things (IoT) devices. In some aspects, IoT event data is received from an IoT device. An IoT dependency graph is identified based on an initial IoT event specified by the IoT dependency graph. An IoT event subsequent to the initial IoT event is identified according to the IoT dependency graph. A command is transmitted to an IoT device to perform the IoT event.

Abstract: The current document is directed to an integrated cloud-management facility, or subsystem, that incorporates an automated-application-deployment-facility integrator that incorporates one or more automated-application-deployment facilities into the cloud-management facility. The automated-application-deployment-facility integrator allows users of the cloud-management facility to access one or more automated-application-deployment facilities within the context of the cloud-management facility. The automated-application-deployment-facility integrator provides to system managers and administrators, through the cloud-management facility, a wider range of functionalities and capabilities than is provided by a cloud-management facility that includes only a single automated-application-deployment facility, or subsystem.

Abstract: The current document is directed to automated application-release-management facilities that, in a described implementation, coordinate continuous development and release of cloud-computing applications. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The currently described methods and systems allow resources to be shared among multiple, interdependent release pipelines and allow access to shared resources to be controlled.

Abstract: Various examples are disclosed for performing dynamic chains of action for Internet-of-Things (IoT) devices. In some aspects, IoT event data is received from an IoT device. An IoT dependency graph is identified based on an initial IoT event specified by the IoT dependency graph. An IoT event subsequent to the initial IoT event is identified according to the IoT dependency graph. A command is transmitted to an IoT device to perform the IoT event.

Abstract: Examples described herein include systems and methods for onboarding a device into a management system. An example method can include loading a management agent onto the device and receiving inventory information for the device. The example method can further include receiving a request to whitelist the device. In some examples, the request originates from a different device, such as a device used by a technician installing the connected device. The management server can authorize the device and add it to the whitelist. After authorizing the device, the management server can onboard the device by sending management information to the management agent on the device. The management server can then exercise management control of the device through the management agent installed on the device.

Abstract: The current document is directed to automated application-release-management facilities that, in a described implementation, coordinate continuous development and release of cloud-computing applications. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The currently described methods and systems allow resources to be shared among multiple, interdependent release pipelines and allow access to shared resources to be controlled.

Abstract: The current document is directed to an automated-application-installation subsystem that provisions, installs, and configures applications across cloud-computing providers, including applications that invoke functions provisioned and executed through a distributed-function-as-a-service feature of the automated-application-installation subsystem. The automated-application-installation subsystem employs application blueprints to identify components to provision. An application blueprint generally includes component specifications, constraints, and interdependencies. The automated-application-installation subsystem then determines a cost-effective provisioning of the identified components across available cloud-computing providers and installs the application according to the cost-effective provisioning.

Abstract: The current document is directed to an automated-application-installation subsystem that provisions, installs, and configures applications across cloud-computing providers. The automated-application-installation subsystem employs an application blueprint to identify components to provisions, including component specifications and constraints, and to identify interdependencies between components. The automated-application-installation subsystem then determines a cost-effective provisioning of the identified components across available cloud-computing providers and installs the application according to the cost-effective provisioning. When less expensive, storage and computer-instruction-execution components of the application may be allocated from different cloud=computing providers.

Abstract: An example apparatus includes means for generating an application blueprint during a design phase, the application blueprint to bind a service template to a node of an application to be deployed in a cloud environment, the service template to be mapped to a plurality of services that are selectable during a runtime phase; and means for generating a deployment profile during the runtime phase, the deployment profile generating means to: select a first service and a second service from the plurality of services mapped to the service template when the application is to be deployed in the cloud environment, the first service different from the second service; generate a first deployment profile to deploy a first instance of the application based on the first service; and generate a second deployment profile to deploy a second instance of the application based on the second service.

Abstract: A disclosed example to configure an application blueprint includes binding, during a design phase, a service template to a node of the application blueprint, the application blueprint corresponding to an application to be deployed, the service template mapped to a plurality of services to be selectable during a runtime phase to implement the node; and storing, during the design phase, the application blueprint for subsequent access during the runtime phase to generate a first deployment profile and a second deployment profile, the first deployment profile to deploy a first instance of the application based on a first service selected from the service template to implement the node, and the second deployment profile to deploy a second instance of the application based on a second service, different from the first service, selected from the service template to implement the node.

Abstract: The current document is directed to automated application-release-management system that provides for efficient check-in of code changes. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The application-release-management system provides continuous application delivery through automated code-change reception, automated testing, and automated delivery. The application-release-management system uses an efficient code-change code-change-check-in process carried out by a code-change-check-in subsystem that identifies and executes those testing methods that test code paths that include the modified code.

Abstract: Techniques for determining host computing systems to deploy virtual machines based on disk specifications are disclosed. In one example, a blueprint to deploy a virtual machine in a cloud computing environment may be received. Further, disk specifications required to deploy the virtual machine may be retrieved from the blueprint. Furthermore, candidate storage entities that support the retrieved disk specifications may be determined. A host computing system that has connectivity to the candidate storage entities may be determined. the determined host computing system may be recommended to deploy the virtual machine.

Abstract: The current document is directed to an automated-application-installation subsystem that provisions, installs, and configures applications across cloud-computing providers, including applications that invoke functions provisioned and executed through a distributed-function-as-a-service feature of the automated-application-installation subsystem. The automated-application-installation subsystem employs application blueprints to identify components to provision. An application blueprint generally includes component specifications, constraints, and interdependencies. The automated-application-installation subsystem then determines a cost-effective provisioning of the identified components across available cloud-computing providers and installs the application according to the cost-effective provisioning.

Abstract: The current document is directed to automated application-release-management facilities that, in a described implementation, coordinate continuous development and release of cloud-computing applications. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The currently described methods and systems allow resources to be shared among multiple, interdependent release pipelines and allow access to shared resources to be controlled.

Abstract: A disclosed example to configure an application blueprint includes binding, during a design phase, a service template to a node of the application blueprint, the application blueprint corresponding to an application to be deployed, the service template mapped to a plurality of services to be selectable during a runtime phase to implement the node; and storing, during the design phase, the application blueprint for subsequent access during the runtime phase to generate a first deployment profile and a second deployment profile, the first deployment profile to deploy a first instance of the application based on a first service selected from the service template to implement the node, and the second deployment profile to deploy a second instance of the application based on a second service, different from the first service, selected from the service template to implement the node.

Abstract: The current document is directed to an automated-application-installation subsystem that provisions, installs, and configures applications across cloud-computing providers. The automated-application-installation subsystem employs an application blueprint to identify components to provisions, including component specifications and constraints, and to identify interdependencies between components. The automated-application-installation subsystem then determines a cost-effective provisioning of the identified components across available cloud-computing providers and installs the application according to the cost-effective provisioning. When less expensive, storage and computer-instruction-execution components of the application may be allocated from different cloud=computing providers.

Abstract: The current document is directed to an automated-application-release-management system that organizes and manages the application-development and application-release processes to allow for continuous application development and release. The current document is particularly directed to implementations in which the automated application-release-management subsystem provides persona-based dashboard displays to users, tailoring the dashboard displays to the job profiles of users and to individual users. Persona-based dashboard displays are facilitated by standardized stage and task outputs, output contexts implemented by code-change identifiers, and stage/task-output aggregation.

Abstract: The current document is directed to automated application-release-management system that provides for efficient check-in of code changes. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The application-release-management system provides continuous application delivery through automated code-change reception, automated testing, and automated delivery. The application-release-management system uses an efficient code-change code-change-check-in process carried out by a code-change-check-in subsystem that identifies and executes those testing methods that test code paths that include the modified code.