System and method for deploying a software program

A method for deploying a software program on a target computing device includes receiving late-binding configuration actions; combining the late-binding configuration actions with a target computing device-specific model to produce a final configuration model; and providing the final configuration model to the target computing device. The final configuration model is executed by the target computing device to configure the target computing device with the software program.

BACKGROUND

Computing devices, such as servers, routers, computers, and other devices having processor logic and memory may have an operating system and one or more applications installed thereon. However, the operating systems, and the applications first have to be loaded or deployed onto the computing device. A computing device with no functional operating system may be referred to as a bare metal computing device. A bare metal computing device can have firmware, such as a Basic Input/Output System (BIOS) that functions to identify, test, and initialize system devices such as displays, drives, peripherals, and other hardware. The BIOS sets the hardware into a known state, so that the computing device can be configured with the operating systems and applications.

Different approaches exist for configuring a computing device. Desired-state software management models may be used to configure various computing devices such as computers and servers with operating systems and applications. The desired-state management model usually is built well before deployment of an operating system to a computer system, and may be based on a set of software developer-selected use cases. A task-based configuration approach uses a series of discrete steps to at least partly configure a computing device. Because the desired-state model typically is developed well before deployment of operating systems and applications, it may conflict with a task-based approach where late-binding, ad hoc configuration decisions are common.

DETAILED DESCRIPTION

One approach for configuring a computer is to use a generic desired-state model for a computer's software (i.e., operating systems and applications) configuration. The generic desired-state model is developed from a set of software developer-selected uses-cases by specifying configuration actions (e.g., deploy operating system ABC with options1,2, and5; deploy operating system XYZ with options2and3). The generic desired-state model typically is developed well before deployment of the operating systems and applications on the computer. The deployment of the operating systems and applications then proceeds according to the software developer-specified use-cases. However, the generic desired-state model, being generic, may not account for variations between a target computer and the device upon which the generic desired-state model is based. That is, the generic desire-state model may not reflect the actual state of the target computer at the time of software deployment.

In a task-based configuration processes, a computer user or system administrator specifies the steps to use for configuring the computer hardware and the software programs to be deployed thereon. This approach can account for a current state of the target computer.

Both task-based and desired-state models may be used to configure various target computing devices such as computers and servers. However, because the generic desired-state model is built “up front,” it may not harmonize with a task-based approach where late-binding, ad hoc configuration decisions are common. Furthermore, the generic desired-state model works by object classification based on pre-determined use-cases; any object not classified by the generic desired-state model can be assigned by the model to a default handler that is part of the target computing device's BIOS or functional operating system. Thus, for physical objects such as software programs or files, failure of the generic desired-state model to classify the software programs or files does not present a problem because of the default handler assignment. However, how the objects should be deployed (i.e., the configuration actions related to the software programs), if not accounted for (correctly or at all) in the generic desired-state model, can present a problem at the time of software deployment. Furthermore, lack of, or improper, classification for the configuration actions as opposed to physical objects such as software programs is more likely to occur in the generic desired-state model because configuration actions are more dynamic in nature software programs and thus more difficult to model in advance of the software deployment. Moreover, some configuration action decisions are made at the time of software program deployment, and thus cannot be included in the generic desired-state model.

To overcome problems inherent in current methods for deploying a software program (i.e., the configuration of operating systems and applications on a computer), the herein disclosed software program deployment system, and corresponding method, overlay task-specific actions on top of a generic desired-state model. Specifically, an operating system to be deployed and installed on a target computing device has a set of pre-defined configuration actions in the generic desired-state model. To provide a computer system administrator with some flexibility in the operating system deployment, the generic desired-state model is modified by the use of a task-based add-on that allows the addition or substitution of administrator-defined configuration actions to the generic desired-state model. Thus, the system administrator can add a new configuration action to the desired-state model, can substitute a new configuration action for a pre-defined configuration action in the generic desired-state model, and can deleted a pre-defined configuration action from the generic desired-state model. As an example, a generic desired-state model may not provide for hard drive partitioning. Upon deployment of an operating system, however, the system administrator may desire to partition the hard drive, and can, using the herein disclosed system and method, add this configuration action to the generic desired-state model that was previously developed for deployment and installation of the operating system.

FIG. 1illustrates an example of a software program deployment system. The software deployment system ofFIG. 1supports combining task-based configuration actions with a generic desired-state model. The system may be used to deploy an operating system to a bare metal computing device, deploy applications to a computing device already configured with a fully functional operating system, and deploy a new operating system to replace an existing operating system, or to act as a second or subsequent operating system on the computing device. For simplification of description, the system and corresponding method will be disclosed with respect to deploying and installing an operating system on a bare metal computing device.

InFIG. 1, system100includes bare metal target computing device110, which is to have an operating system installed thereon. The target computing device110may be any software-configurable computing system, such as a server, for example. A computer system administrator employs a Web-based user interface (U/I)120to initiate, control, and manage configuration of the target computing device110and deployment and installation of the operating system. Also shown inFIG. 1is model server140, central device repository130, and target proxy server150. The servers140and150may be separate hardware devices or may be virtual machines. Alternately, the servers140and150may be combined on one hardware device. The central device repository130maintains configuration data for the target computing device110. The configuration data may specify, for example, that the target computing device110includes a single hard drive, that specific permission is required from a system administrator to deploy the operating system to the target computing device110, etc. The central device repository130also maintains configuration data for other devices that may be configured using the system100. Finally, the central device repository130may maintain the to-be-installed operating system programming, files, and data. The model server140maintains a generic desired-state model for configuring the target computing device110. In an embodiment, the generic desired-state model may require the addition of target device-specific configuration data135, which, as noted above, is maintained in the repository130. The model server140receives from the Web U/I120, any late-binding configuration actions125specified by the system administrator. To construct a final configuration model specific to the target computing device110, the model server140retrieves the target computing device-specific configuration data135from the repository130and passes the device-specific configuration data135and generic desired-state model (i.e., target computing device-specific configuration model145) to the target proxy server150along with the late-binding configuration actions125. The target proxy server150overlays the administrator-selected late-binding configuration actions125on the model145to form a final configuration model, which the target computing device110will receive to drive configuration and installation of the operating system on the target computing device110. That is, the target proxy server150combines (deletes, adds, or substitutes) configuration actions defined or selected by the computer system administrator with the model145to achieve a final configuration action set, or model, to use in deploying the operating system on the target computing device110. To achieve the final configuration model, the target proxy server150translates the combined late-binding configuration actions125and model145into a format appropriate for the target computing device110. For example, the combined late-binding configuration actions125and model145is translated into an XML-formatted document or file. Final configuration model155contains the model description for the intended deployment (e.g., what operating system to deploy and install, files required for the operating system deployment and installation, how to configure the target computing device hard disk) as well as all the configuration data needed so that the BIOS on the target computing device140can perform the operating system installation.

The Web U/I120may be generated by the model server140, and the programming that provides for the Web U/I may be stored in memory in the model server140and executed by a processor in the model server140. The Web U/I120exposes the operating system deployment to the computer system administrator as a task that the administrator can control. The computer system administrator uses the Web U/I120to initiate the deployment process of the target computing device110by sending deployment trigger115to the target computing device110. The deployment trigger115may be a simple command. The target computing device110receives the deployment trigger115, and in response, sends an initiate deployment request117to the model server140. The Web U/I120displays to the administrator prompts, menus, and directions regarding selection of configuration actions, and provides the administrator with a running status of the operating system deployment on the target computing device110.

Finally, the system100may include computer readable medium160. Computer readable medium160may be an optical disk, for example, and may have loaded thereon, the applications, programs, files, and data used by the servers140and150to execute a process for configuring the target computing device110. The applications, programs, files and data may be transferred from the computer readable medium160to another computer readable medium such as the central device repository130, or persistent memory (not shown) on the model server140. Within the model server140, the applications, programs, files and data may be stored in volatile memory (not shown), and executable code within the applications and programs may be executed by a processor of the model server140. Similarly, a processor (not shown) on the target proxy server150may execute appropriate code to form the final configuration model, and a processor (not shown) on the target computing device110may execute the final configuration model to configure the target device110with the desired operating system and/or applications.

FIG. 2illustrates additional details of the system100ofFIG. 1. Specifically,FIG. 2illustrates some of the programming elements180of the system100. InFIG. 2, the programming elements180include user interface engine181, desired-state model engine183, overlay engine185, and translator187. The interface engine181includes the programming that produces the various displays, menus and windows provided to the computer system administrator at the Web U/I120and receives administrator selections, including the late-binding configuration action selections125. The desired state model engine183includes the programming that selects the generic desired-state model, and adds the appropriate target computing device data130to that model. The overlay engine185adds the late-binding configuration actions to the model. Finally, the translator187translates the model into a format or language appropriate to the target computing device110to produce the translated final configuration model155.

The programming elements180shown inFIG. 2may be installed on the servers140and150as appropriate. Alternately, the servers140and150may be combined into one server, and the programming elements180installed on this single server. The programming elements180may be stored in persistent memory such as the central device repository130; the programming elements180may be maintained in memory in the servers140and150, and the executable code of the programming elements180may be executed by processors on the servers140and150.

FIG. 3is a flowchart illustrating an example configuration control operation200executed on the system100ofFIG. 1. InFIG. 3, operation200begins with block205when the system administrator, using Web U/I120initiates deployment of an operating system on target device110by sending a deployment trigger115to the target device110. The actual operating system programming may be provided with the trigger115. A processor at the target computing device110reads the trigger115. In block210, the computer system administrator, using the Web U/I120, provides, and the model server140receives, late-binding configuration actions125, which ultimately will be combined with the generic desired-state model to produce a final configuration model155by which the target device110is configured with the operating system. In block215, the model server receives an initiate deployment request117.

In block220, the model server140, in response to the request117, retrieves target computing device-specific configuration data135, as necessary, from central device repository130. In block225, the model server140, using the configuration data135, as required, constructs a target computing device-specific model145for the target computing device110. The target device-specific model145reflects the generic desired-state model as it applies to the target computing device110. Note, however, that the generic desired-state model may not require modification with the configuration data135.

In block230, the model server140sends the target computing device-specific model145(that is, the generic desired state model and any target computing device-specific configuration data135) to target proxy server150. In block235, the target proxy server150, using the late-binding data125and the target computing device-specific model145, generates a final version of the generic desired-state model that overlays the late-binding data125on the model145. This overlay process executed on the server150includes changing configuration actions, inserting new configuration actions, and deleting, without replacement, existing configuration actions. In block240, the target proxy server150translates the final configuration model into a form or language readable by the target device110. For example, the final configuration model is translated into an XML-formatted document or file. Finally, in block245, the target proxy server150sends the translated final configuration model155to the target device110, where it is used by the target computing device's BIOS to install the operating system.