Microsoft Technology Licensing, LLC

Vitalii Tsybulnyk

Marwan E Jubran

Aleksandr Mikhailovich Gershaft

Vladimir Petrenko

Vipins Gopinadhan

Weiping Hu

Aritra DattaGupta

Igor Avramovic

Willy Tanimihardja

Clifford Thomas Dibble

Arka Dasgupta

Marwan Elias Jubran

A system and method for blocking path detection is provided. A job comprises tasks with at least some of the tasks dependent on other task(s). Each task is assigned to an ownership team. At a particular point in execution of the job, states of tasks of the job are identified. The states include one of three mutually exclusive states: waiting for another task/finished, in progress, and, blocked. When all the tasks with identified states of in progress or blocked are assigned to a particular ownership team, the particular ownership team is identified as on a blocking path. An action can be performed regarding the blocking path, for example, selected in accordance with policy-defined response actions such as generating an incident, escalating an existing incident, and/or sending a notification (e.g., an accumulated time on the blocking path can be calculated for each team with team(s) notified when certain threshold(s) are exceeded).

System and method for blocking path detection

In various embodiments, methods and systems for modeling or representing hardware inventory based on a topology definition is provided. A topology definition having physical elements and logical elements corresponding to a physical topology layer and a logical topology layer is received. An instance definition for a rack, cluster, or datacenter for a hardware management operation is received. The instance identifies a physical topology and a logical topology for the operation. A hardware management service is executed, based on the topology definition and the instance definition, to manage the hardware inventory of the topology definition. Hardware management of the hardware inventory corresponding to the separately defined physical elements and logical elements is performed with attributes that are defined in the schema. The topology definition can include precision levels that indicate a hierarchical classification of topology components classified at a device level, a rack level, a cluster level, and a datacenter level.

Datacenter topology definition schema

Described herein is a system and method for dependency version conflict auto-resolution for executing job(s). During execution of a particular version of a workflow comprising tasks, information regarding a particular task to be executed is received. The particular task is dependent on another task. Information regarding the dependency is retrieved from a global dependency data structure (e.g., graph) that stores current dependency information regarding the tasks. When it is determined that the conflict exists with respect to the dependency of the particular task on the another task, information regarding the dependency and workflows is retrieved, information regarding a dependency change history regarding at least one of the plurality of tasks, information regarding the particular version of the workflow and a different version of the workflow. A resolution to the conflict can be identified based, at least in part, upon the retrieved information, and, a correct action performed.

Dependency version conflict auto-resolution

Embodiments of the present invention provide systems, methods, and computer storage media for automated standalone bootstrapping of hardware inventory that includes a provisioning workflow of discovering, validating, and configuring hardware inventory. In an exemplary embodiment, an in-rack computing device, such as a chassis manager or selected blade, initializes an intra-rack communication network with a hardware inventory of the rack. The in-rack computing device initiates intra-rack communication with the hardware inventory in the rack, using the intra-rack communication network, to discover at least a set of computing units in a hardware inventory. Intra-rack communications that include traffic received from the set of computing units. The in-rack computing device validates operational configurations of the hardware inventory based on comparing expected operational configuration parameters with actual operational configuration parameters, at least a portion of the operational configuration parameters retrieved from the information carried within the traffic received from the set of computing units.

Automated standalone bootstrapping of hardware inventory

Methods, systems, and computer-readable media for automatically configuring an inventory of hardware to interact seamlessly with a datacenter are provided. Initially, customer-specific specifications are collected from a user, which are automatically supplemented with platform-specific specifications. These specifications are used to select the hardware inventory from a set of predefined hardware clusters, where each of the predefined hardware clusters represents compatible configurations of hardware assets and logical assets that have been demonstrated to function congruently. A cluster-configuration file is derived from data held within a stock-keeping unit (SKU) that describes the selected hardware inventory. The cluster-configuration file is populated with abstract symbolic representations that act as placeholders for expected values that are presently unknown. Network resources are assigned by automated conversion of the abstract symbolic representations into concrete values. The cluster-confirmation file is merged with previous versions of datacenter inventory to create an updated version of the datacenter inventory.

Establishing an initial configuration of a hardware inventory

Building binary packages for software products, particularly large-scale software products, is a highly computation intensive process. Thus, it is desirable to distribute the workload over a large number of computing nodes so as to have the build process complete in an optimal period of time. One environment providing compute resources that can be utilized for a highly available and dynamically scalable distributed build process is an elastic compute cloud. In such an environment, virtual machines can be instantiated and destroyed as the resource requirements of the build process dictate. This has the advantage that dedicated hardware is unneeded, and excess capacity on the hardware employed can be employed for other computation tasks when the build process is idle. Presented herein are systems, methods and computer storage media for distributing a highly available and scalable build service, suitable for use in an elastic compute environment or other distributed environment.

Cloud-based build service

Methods, systems, and computer-readable media for automatically validating and configuring an inventory of hardware to interact seamlessly with a cloud-computing fabric of a data center are provided. Initially, devices internal to the hardware inventory are located by sending and receiving messages via out-of-band communication channels and network communication channels, respectively. Locating the internal devices involves establishing communication from a user device to the hardware inventory and selecting at least one of the internal devices for conducting a discovery process thereon. The discovery process involves receiving a first network identifier via the out-of-band communication channel and receiving a second network identifier via the network communication channel. When the first and second network identifiers match, the interconnection of the selected device is validated. Otherwise, one or more remedial measures are initiated with respect to the selected device. Validation involves conducting a server boot within the MOS and executing validation and configuration tools.

Growing community of inventors

Redmond, WA, United States of America

Vitalii Tsybulnyk