WO2025147246A1 - Automated dependency verification and provisioning for software systems - Google Patents

Abstract

Methods for automated dependency verification and provisioning for software systems and corresponding systems and computer-readable mediums. A method (200) includes receiving (202), by a computer system (100), dependency information (308) corresponding to a target application and building (204) a dependency graph (310) based on the dependency information (308). The method includes inspecting (206) program code of the target application (154) to identify application dependencies and inspecting (208) a target system (516) to identify current components. The method includes comparing (210), according to the dependency graph (310), the application dependencies and the current components, and, based on the comparison, determining (212) additional required components. The method includes deploying (214) the target application (154) and the required components to the target system (516).

Description

AUTOMATED DEPENDENCY VERIFICATION AND PROVISIONING FOR SOFTWARE SYSTEMS

TECHNICAL FIELD

[0001] The present disclosure is directed, in general, to systems and methods for deployment and management of software systems.

BACKGROUND OF THE DISCLOSURE

[0002] Complex software systems, including by not limited to machine learning models and artificial intelligence (Al) applications, rely on a complex system of software dependencies including drivers, frameworks, libraries, runtimes, etc. that must be installed and properly configured on the target deployment platform to ensure proper execution of the deployed software systems. These software dependencies may have conflicting or unforeseen requirements both in their own dependencies and in their relations to each other. Current systems are unable to effectively manage these dependencies in any sort of automated fashion. Improved systems are desirable.

SUMMARY OF THE DISCLOSURE

[0003] Various disclosed embodiments include methods for automated dependency verification and provisioning for software systems and corresponding systems and computer-readable mediums. A method includes receiving, by the computer system, dependency information corresponding to a target application and building a dependency graph based on the dependency information. The method includes inspecting program code of the target application to identify application dependencies and inspecting a target system to identify current components. The method includes comparing, according to the dependency graph, the application dependencies and the current components, and. based on the comparison, determining additional required components. The method includes deploying the target application and the required components to the target system.

[0004] In various embodiments, the dependency information includes information from open-source repositories and/or formal dependency requirements. In various embodiments, the dependency information is derived from testing and validation processes. In various embodiments, receiving the dependency information and building the dependency graph are performed repeatedly and concurrently. In various embodiments, the dependency graph includes software and hardware components represented as nodes and dependencies represented as links between the nodes.

[0005] Various embodiments also include performing testing and validation processes according to the dependency graph to verify correct dependencies and remove weak or incorrect dependencies.

[0006] In various embodiments, the target application is an Artificial Intelligence software application.

[0007] Disclosed embodiments also include a computer system having a processor and an accessible memory, configured to perform processes as disclosed herein, and a non-transitory computer-readable medium encoded with executable instructions that, when executed, cause one or more computer systems to perform processes as disclosed herein.

[0008] The foregoing has outlined rather broadly the features and technical advantages of the present disclosure so that those skilled in the art may better understand the detailed description that follows. Additional features and advantages of the disclosure will be described hereinafter that form the subject of the claims. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the disclosure in its broadest form.

[0009] Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words or phrases used throughout this patent document: the terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation; the term “or” is inclusive, meaning and/or; the phrases “associated with” and “associated therewith,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term “controller” means any device, system or part thereof that controls at least one operation, whether such a device is implemented in hardware, firmware, software or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understand that such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases. While some terms may include a wide variety of embodiments, the appended claims may expressly limit these terms to specific embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:

[0011] FIG. 1 illustrates a block diagram of a computer system in which an embodiment can be implemented;

[0012] FIG. 2 depicts a flowchart of a process in accordance with disclosed embodiments;

[0013] FIG. 3 illustrates an example of receiving dependency information and building a dependency graph in accordance with disclosed embodiments;

[0014] FIG. 4 illustrates an example of a process 400 for testing and validation in accordance with disclosed embodiments; and

[0015] FIG. 5 illustrates an example of a system architecture for dependency validation and target application deployment in an Artificial Intelligence system architecture in accordance with disclosed embodiments.

DETAILED DESCRIPTION

[0016] FIGURES 1 through 5, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

[0017] Dependencies in software systems may have conflicting or unforeseen requirements both in their own dependencies and in their relations to each other. For this reason, disclosed embodiments address systems and methods for automated dependency verification and provisioning of software systems.

[0018] Various embodiments address dependency verification, including processes to evaluate the resources and other requirements or dependencies of a target platform, and to compare these to the dependencies required by the application to be deployed. This is accomplished in an automated fashion, providing the distinct technical advantage of a fast, efficient, and reliable evaluation of the requirements for deployment.

[0019] Various embodiments also address platform provisioning, to automatically provision the target platform with the required dependencies while ensuring that other installed applications will not be adversely affected. This accomplishes a highly complex task that is cannot be practically performed manually, particularly in shared Al and other complex application platforms.

[0020] Disclosed embodiments can also address managing dependencies and conflicts across multiple different system levels, including applications, runtime libraries, drivers, operating systems, and hardware. For example, on certain operating systems or platforms, installing or running a given application-level component may first require a specific runtime-level component to be successfully compiled and installed.

[0021] FIG. 1 illustrates a block diagram of a computer system 100 in which an embodiment can be implemented, for example as a computer system particularly configured by software or otherwise to perform the processes as described herein, and in particular as each one of a plurality of interconnected and communicating systems as described herein. In particular, the computer system 100 is an example of a computer system that can perform the processes disclosed herein to perform dependency evaluation and verification and to deploy software tools according to that evaluation, and is also an example of a computer system that can be the “target” system for such provisioning.

[0022] The computer system 100 depicted includes a processor 102 connected to a level two cache/bridge 104, which is connected in turn to a local system bus 106. Local system bus 106 may be, for example, a peripheral component interconnect (PCI) architecture bus. Also connected to local system bus in the depicted example are a main memory 108 and a graphics adapter 110. The graphics adapter 110 may be connected to display 111.

[0023] Other peripherals, such as local area network (LAN) / Wide Area Network / Wireless (e.g. WiFi) adapter 112, may also be connected to local system bus 106. Expansion bus interface 114 connects local system bus 106 to input/output (I/O) bus 116. I/O bus 116 is connected to keyboard/mouse adapter 118, disk controller 120, and I/O adapter 122. Disk controller 120 can be connected to a storage 126, which can be any suitable machine usable or machine readable storage medium, including but not limited to nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), magnetic tape storage, and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and other known optical, electrical, or magnetic storage devices.

[0024] Also connected to I/O bus 116 in the example shown is audio adapter 124, to which speakers (not shown) may be connected for playing sounds. Keyboard/mouse adapter 118 provides a connection for a pointing device (not shown), such as a mouse, trackball, trackpointer, touchscreen, etc.

[0025] Those of ordinary skill in the art will appreciate that the hardware depicted in Figure 1 may vary for particular implementations. For example, other peripheral devices, such as an optical disk drive and the like, also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

[0026] A computer system in accordance with an embodiment of the present disclosure includes an operating system employing a graphical user interface. The operating system permits multiple display windows to be presented in the graphical user interface simultaneously, with each display window providing an interface to a different application or to a different instance of the same application. A cursor in the graphical user interface may be manipulated by a user through the pointing device. The position of the cursor may be changed and/or an event, such as clicking a mouse button, generated to actuate a desired response.

[0027] One of various commercial operating systems, such as a version of Microsoft Windows™, a product of Microsoft Corporation located in Redmond, Wash, may be employed if suitably modified. The operating system is modified or created in accordance with the present disclosure as described.

[0028] LAN/ WAN/Wireless adapter 112 can be connected to a network 130 (not a part of computer system 100), which can be any public or private data computer network or combination of networks, as known to those of skill in the art, including the Internet. Computer system 100 can communicate over network 130 with server system 140, which is also not part of computer system 100, but can be implemented, for example, as a separate computer system 100.

[0029] Storage 126 can store any data necessary or useful for performing processes as described herein, including but not limited to program code 152, target application 154, dependency information 156, dependency graphs 158, virtual machines 160, dependency requirements 162, and other data 164.

[0030] Current processes to attempt to manually evaluate dependencies are complex, cumbersome, and ineffective. A manual process requires a team of individuals to review documentation regarding system requirements, dependencies, and installation instructions. For example, Nvidia Corporation publishes compatibility matrices showing which driver versions are compatible with different generations of their hardware and which of their operating system libraries are compatible with different driver versions. The user is then left to manually provision the target platform with software packages according to these instructions. In case of conflicts, the user is often left to manually resolve them with the help of third-party public sources.

[0031] Some package management tools attempt to compare installed dependencies against requested ones. These tools also attempt to automate the provisioning of the target platform by downloading and updating packages to satisfy the requirements of the application being deployed. Conflicting dependencies between two applications must be resolved manually.

[0032] Some approaches employ so-called “dependency managers,” based on comprehensive project dependency files, which explicitly list required dependencies and compatible versions per target package. These tools make visible to the user which version ranges of their application’s dependencies can be used to satisfy their requirements. Additionally, such tools may provide a tree view of primary and secondary dependencies. These approaches require close manual inspection of the dependencies identified by the project dependency files.

[0033] Some approaches require creating virtual environments for each software or Al application, which can be distributed with prebuilt installation packages that include all necessary components, such as a “wheel” in the Python programming language and environment. Another example could include the use of “Docker” image files, available from Docker, Inc., where operating system-level packages like Debian packages can be pre-built and distributed inside the Docker image.

[0034] The above approaches focus only on addressing a single system layer at a time: hardware/drivers, OS-level libraries, or application packages/frameworks. For these reasons and others, the solutions described above are inefficient and incomplete.

[0035] Disclosed embodiments, by contrast, provide a holistic solution to full-stack dependency management. Disclosed processes use pre-defined knowledge, system and software inspection, and dependency validation to determine dependency requirements for and deploy software packages.

[0036] FIG. 2 depicts a flowchart of a process 200 in accordance with disclosed embodiments that may be performed, for example, by one or more computer systems as disclosed herein (generically referred to as the “system”, below), to perform dependency verification and platform provisioning of a target software product (the “target application”) on a target computer system (the “target system”).

[0037] At 202, the system receives dependency information corresponding to the target application and its components. “Receiving,” as used herein, can include loading from storage, receiving from another device or process, receiving via an interaction with a user, and otherwise. Specific examples of ways the system can received this information are described below.

[0038] For example, the system can collect dependency information from existing open-source applications (or from a stored databased derived from such applications). By accessing or “scraping” open-source repositories, such as the GITHUB repository, the system can collect information about apparent dependencies through source files indicating valid combinations of host operating system and bare metal components, container and operating system libraries such as DEBIAN packages indicated in a Dockerfile, Python packages as indicated in a requirements.txt file, and other publicly accessible or open-source dependency descriptions.

[0039] As another example, the system can collect published formal dependency requirements, such as according to Compute Unified Device Architecture (CUDA) compatibility matrices, pyproject.toml files, dpkg info, and other formal dependency requirement descriptions. The formal requirements can include user knowledge of express dependency requirements.

[0040] As another example, the system can use virtual machine and docker infrastructure to identify and verify likely or suspected dependencies, or to remove identified dependencies that cannot be successfully verified.

[0041] At 204, the system builds a dependency graph based on the dependency information. The dependency information is assembled into a graph with links between components and versions that can or must be deployed together, where software or hardware components are represented as nodes and dependencies are represented as links which can be weighted links. More frequently seen combinations and required combinations are represented with stronger or more heavily-weighted links, while rarer combinations are assigned weaker links. Note that these valid combinations represent only a sufficient condition for successful deployment, but it is possible that not all found dependencies are necessary.

[0042] In particular, processes 202 and 204 can be performed together, concurrently, or successively and repeatedly to dynamically receive the dependency information while building and refining the dependency graph. Doing so allows the system to build a more robust and accurate dependency graph, including refining the weighting of links. As other open-source and publicly-available dependency information and requirements are obtained, the system can update the dependency graph accordingly. Similarly, the system can update the dependency graph according to the virtual machine verification testing described above. As an active service, the dependency graph can be kept up-to-date by continuously receiving additional dependency information, executing new tests, and collecting additional user or formal input, for example from a new version of NVIDIA’ s compatibility matrix or to accommodate completely new packages or frameworks.

[0043] FIG. 3 illustrates an example of receiving dependency information and building a dependency graph, where open source repositories 302, formal dependency requirements 304, and testing and validation processes are all sources for receiving dependency information 308. Dependency information 308 is then used to build the dependency graph(s) 310.

[0044] Other sources of dependency information could include, for example, user feedback from previous deployments, specific deployment requirements for hardware or software that are required to be used or forbidden to be used, and other information that can influence what components should or should not be deployed and how they depend on each other.

[0045] FIG. 4 illustrates an example of a process 400 for testing and validation as described above. Testing and validation processes can be performed according to the dependency graph to verify correct dependencies and remove weak or incorrect dependencies. In this example, a job schedule 402 runs a weak dependency finder service 404, which queries the dependency graph 414 to identify weak dependencies or other dependencies to be tested. These are fed to verification test service 408, which can retrieve dependency information 406, including any open-source or formal dependency requirements, user feedback, and other sources of dependency information.

[0046] Verification test service 408 can then run tests, based on the dependency graph 414 information, the identified weak dependencies (or other dependencies to be tested) and the dependency information 306, in a virtual testing infrastructure 410. Virtual testing infrastructure can be implemented using one or more virtual machines 412, shown in this example as virtual machines 412a, 412b, and 412c. Based on the results of the tests, the verification test service 408 can update the dependency graph 414 to reinforce (or more heavily weight) proven dependency links and to remove weak or invalid dependency links.

[0047] FIG. 5 illustrates an example of a system architecture for dependency validation and target application deployment in an Artificial Intelligence system architecture 500, and is used to illustrate examples of various steps below.

[0048] Returning to FIG. 2, at 206, the system inspects program code of the target application to identify application dependencies. These can be identified in the code itself, for example in the known forms of a Dockerfile, a requirements.txt file, a Pipfile, in python import commands, etc. The target application code is represented as the Al Application Package 502 in the Artificial Intelligence system architecture 500 example of FIG. 5.

[0049] The inspection of 206 can be performed, for example, by an Al Deployment Service 504 as illustrated in FIG. 5 or similar service for non-AI implementations, that inspects the virtual environment 512 such as a Python runtime and the container environment 514 such as the Al runtime.

[0050] At 208, the system inspects the target system and its existing software packages to identify current components.

[0051] The inspection of 208 can be performed, for example, by the Al Deployment Service 504 as illustrated in FIG. 5 or similar service for non-AI implementations, that inspects the hardware platform 516 on the target system or device. [0052] At 210, the system compares the application dependencies, according to the dependency graph, to the current components on the target system to validate if the target application can be deployed without modifying the target system and existing software packages.

[0053] The comparison at 210 can be performed, for example by a dependency validation service 506 as illustrated in FIG. 5.

[0054] If dependencies do not match, the dependency validation service, or similar service, can leverage the dependency graph 310 to determine additional installation steps required and if those steps are compatible with the existing installation. For example, newer versions of certain components may require a newer driver than that currently installed on the target system.

[0055] For driver-level dependencies, the system can check hardware compatibility using a known matrix of supported hardware per driver versions. If the target hardware simply cannot support the required driver version, the system can abort the installation process and suggest alternate resolutions, such as downgrading a driver or other component.

[0056] In case two applications have conflicting dependencies, the system can recommend possible resolutions, such as upgrading or downgrading one of them (according to the dependency graph 310) and can communicate to the user that currently the apps cannot coexist. In some cases, the system only uses the dependency graph 310 to recommend compatible versions of packages but may not address significant functional or API changes to certain components, in which case the user has the option to evaluate whether their application code can be modified or refactored to use the recommended package versions.

[0057] At 212, based on the comparison, the system determines additional required components.

[0058] At 214, assuming a valid deployment is possible, the system deploys the target application and the required components to the target system. [0059] In the context of system architecture 500, dependency validation service 506 can request provisioning by an application management system 508 and a device management system 510 to execute any required installation packages or scripts to install any required components (and the target application) to container 514 and hardware platform 516 of the target system.

[0060] Processes as described herein can be duplicated across CPU architectures, since there are no cross-dependencies, but the dependency graphs will necessarily differ from between different hardware and CPU architectures. These processes can be used for validating and deploying any number of types of target software applications and are particularly advantageous in deploying Al inference applications and for Al model training pipelines.

[0061] Disclosed techniques provide a number of technical advantages. In various embodiments, dependencies are managed across different system levels (e.g., application level, operating system, driver, and hardware), whereas other approaches only consider a single level (e.g., application interdependencies). This leads to a significantly higher probability of successful deployment using disclosed techniques since cross-level conflicts can be identified and corrected before installation.

[0062] Further, several methods, including accessing open-source projects, collecting user feedback, imposing expert a priori or other formal knowledge, and verification testing of weak links, are leveraged to aggregate information into a single dependencies graph, whereas other approaches just rely on product dependency documentation. This provides a much more comprehensive and robust system for dependency verification since multiple sources of information are leveraged simultaneously.

[0063] Of course, those of skill in the art will recognize that, unless specifically indicated or required by the sequence of operations, certain steps in the processes described above may be omitted, performed concurrently or sequentially, or performed in a different order.

[0064] Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all computer systems suitable for use with the present disclosure is not being depicted or described herein. Instead, only so much of a computer system as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described. The remainder of the construction and operation of computer system 100 may conform to any of the various current implementations and practices known in the art.

[0065] It is important to note that while the disclosure includes a description in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present disclosure are capable of being distributed in the form of instructions contained within a machine-usable, computer-usable, or computer-readable medium in any of a variety of forms, and that the present disclosure applies equally regardless of the particular type of instruction or signal bearing medium or storage medium utilized to actually carry out the distribution. Examples of machine usable/readable or computer usable/readable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), and user- recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs).

[0066] Although an exemplary embodiment of the present disclosure has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements disclosed herein may be made without departing from the spirit and scope of the disclosure in its broadest form.

[0067] None of the description in the present application should be read as implying that any particular element, step, or function is an essential element which must be included in the claim scope: the scope of patented subject matter is defined only by the allowed claims. Moreover, none of these claims are intended to invoke 35 USC § 112(f) unless the exact words "means for" are followed by a participle. The use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” or “controller,” within a claim is understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and is not intended to invoke 35 U.S.C. §112(f).

Claims

WHAT IS CLAIMED IS:

1. A method (200) for automated dependency verification and provisioning for software systems, the method (200) performed by a computer system (100), comprising: receiving (202), by the computer system (100), dependency information (308) corresponding to a target application; building (204), by the computer system (100), a dependency graph (310) based on the dependency information (308); inspecting (206), by the computer system (100), program code of the target application (154) to identify application dependencies; inspecting (208), by the computer system (100), a target system (516) to identify current components; comparing (210), by the computer system (100) and according to the dependency graph (310), the application dependencies and the current components; and based on the comparison, determining (212), by the computer system (100), additional required components; and deploying (214), by the computer system (100), the target application (154) and the required components to the target system (516).

2. The method of claim 1, wherein the dependency information (308) includes information from open-source repositories (302).

3. The method of claim 1, wherein the dependency information (308) includes formal dependency requirements (304).

4. The method of claim 1, wherein the dependency information (308) is derived from testing and validation processes (306).

5. The method of claim 1, wherein receiving (202) the dependency information (308) and building (204) the dependency graph (310) are performed repeatedly and concurrently.

6. The method of claim 1, wherein the dependency graph (310) includes software and hardware components represented as nodes and dependencies represented as links between the nodes.

7. The method of claim 1, further comprising performing testing and validation processes (400) according to the dependency graph (310) to verify correct dependencies and remove weak or incorrect dependencies.

8. The method of claim 1, wherein the target application (154) is an Artificial Intelligence software application (502).

9. A computer system (100) comprising: a processor (102); and an accessible memory (108), the computer system (100) particularly configured to perform a method (200) as in any of claims 1-8.

10. A non-transitory computer-readable medium (126) encoded with executable instructions (152) that, when executed, cause one or more computer systems (100) to perform a method (200) as in any of claims 1-8.