Abstract: An energy estimator runs workloads to determine power consumed by processor cores in various power states and utilizations. This power consumption data is then used by an energy export agent for further calculations on different scenarios and cases. The energy export agent reads a total power consumption value from a CPU, data describing execution of processes from an operating system, and information regarding software components executing on the CPU from an orchestrator control plane. The agent uses data describing states of operating of the processor cores of the CPU and the total power consumption value to estimate power consumed by each processor core. Allocation and utilization of each processor core by a process and/or a container that spawned a process are then used to determine power consumption attributable to the process and/or container. A software hierarchy may be used to aggregate power consumption for applications, namespaces, or other software components.

Abstract: Systems and methods for agentless GitOps and custom resources for managing infrastructure orchestration and cluster orchestration. A system includes a plurality of bare metal servers forming an infrastructure orchestration for a cloud native platform, and a plurality of clusters running on the plurality of bare metal servers, wherein the plurality of clusters forms a cluster orchestration. The system includes a data center automation platform executed by one or more of the plurality of clusters, wherein the data center automation platform subscribes to a git repository to receive updates pertaining to one or more of the infrastructure orchestration or the cluster orchestration, and wherein the data center automation platform executes continuous delivery (CD) for each of the infrastructure orchestration and the cluster orchestration based at least in part on data received from the git repository.

Abstract: Systems and methods for git webhook authorization for GitOps management operations. A method includes generating a unique access token for a user and generating a git secret to be encrypted and stored on a git repository, wherein the git secret comprises the unique access token for the user. The method includes generating a git webhook associated with the git repository, wherein the git webhook subscribes a data center automation platform to an event channel and retrieving a payload from the git repository in response to a new event occurring on the event channel, wherein the payload comprises the git secret.

Abstract: Systems and methods for agentless GitOps and custom resources for application orchestration and management. A system includes a bare metal server running a cloud native application and a plurality of clusters running on the bare metal server, wherein at least a portion of the plurality of clusters executes an application. The system includes a data center automation platform responsible for service management and orchestration for the bare metal server, wherein the data center automation platform subscribes to a git repository to receive updates pertaining to the application, and wherein a read only token is established between the git repository and the data center automation platform.

Abstract: A workflow may include function calls to functions executed with respect to instances of elements. Health checks of elements of the workflow may be performed with reference to topology such that health checks of elements are omitted where a health check is performed by a parent in the topology. Batch processing of stages of a workflow may be performed with commencement of a stage being initiated based on completion percentage and execution time of a previous stage. Tasks of each stage may be performed by a pool of workers that are reused with pool size being selected based on expected completion time of each stage.

Abstract: A workflow may include function calls to functions executed with respect to instances of elements. Functions may be stored in a file store. When functions are edited and checked in to the file store, change to the function may be detected and workflows implicated by the change to the function are identified. Execution of the implicated workflows may then be invoked in response to detecting the change. Functions may have an exclusivity associated with them such that execution of a workflow includes executing function calls alone where required by the exclusivity or concurrently where permitted by the exclusivity. Check-in monitoring on a repository of element files (element definition and element functions) may be performed. In response to check-in of a file, workflows including elements referencing the file may be executed.

Abstract: A bare metal server, or other computing device, may be represented as a JSON file (extending the concept to infrastructure as code) containing hardware, firmware and software versions with links to a kickstarter file depending on the needs of an application, SKU type or some other criteria. Rather than a management node in an L2 network which has a DHCP server to IP lease and facilitate OS installation, a workflow then generates a bootstrap kernel which initializes the bare metal server with an IP address, VLAN, and network gateway which is used to reach out to the network to download and install a kernel, upgrade firmware for various hardware components like BIOS, BMC, NIC, RAID, SSD, NVME, FPGA, etc. The bootstrap kernel may further configure RAID and JBOD, flash custom images on hardware components and may further instruct the server to incrementally download and install an operating system.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. Components of cloned applications may communicate with one another using addresses of these components in the parent application. Jobs implementing a bundled application may be referenced with a simulated file system that generates reads to hosts only when the job log file is actually read. Job logs and a job hierarchy may be used to perform root cause analysis. Job logs may be for tasks such as creating the bundled application, cloning, rolling back, backing up, scaling out, scaling in, deleting, pruning unused application images, or the like.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be thin clones. An application may use multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and perform operations using the snapshots. Rolling back may include deleting objects other than PVCs, followed by rolling back storage volumes mounted to the PVCs, followed by recreating objects according to an application snapshot. PVCs created by a custom resource may be deleted along with the custom resource with the PVCs being recreated before recreating the custom resource.

Abstract: A workflow may include function calls to functions executed with respect to instances of elements. Health checks of elements of the workflow may be performed with reference to topology such that health checks of elements are omitted where a health check is performed by a parent in the topology. Batch processing of stages of a workflow may be performed with commencement of a stage being initiated based on completion percentage and execution time of a previous stage. Tasks of each stage may be performed by a pool of workers that are reused with pool size being selected based on expected completion time of each stage.

Abstract: A workflow may include function calls to functions executed with respect to instances of elements. Functions may be stored in a file store. When functions are edited and checked in to the file store, change to the function may be detected and workflows implicated by the change to the function are identified. Execution of the implicated workflows may then be invoked in response to detecting the change. Functions may have an exclusivity associated with them such that execution of a workflow includes executing function calls alone where required by the exclusivity or concurrently where permitted by the exclusivity. Check-in monitoring on a repository of element files (element definition and element functions) may be performed. In response to check-in of a file, workflows including elements referencing the file may be executed.

Abstract: An orchestrator generated pod specifications for role instances of a bundled application and submits these pod specifications to a KUBERNETES master. The pod specification specifies a node on which to implement a container executing the role instance, the node being selected according to an application manifest that may include affinity and anti-affinity constraints. The pod specification may be implemented by a KUBELET executing on the node, which may invoke interfaces to the orchestrator in order to obtain a network address for the container. A storage volume to be used by the container may have been mounted to the node previously by the orchestrator and be ready for use by the container. Upon failure of the node, the orchestrator generates a new pod specification according to the application manifest that instructs the master to create a new container having a same identity and state as the former container.

Abstract: Function calls, such as function calls from a workflow, may be added to queues. Function calls are selected from the queue and executed by workers of a worker pool, each worker being a container. The workers may be of different types and function calls may require execution by a worker of a specific type. The workers of the worker pool may be created or deleted such that workers are of the type required by function calls in the queue. Creation and deletion of workers may be performed according to priority of function calls in the queue. Creation and deletion of workers may be scheduled according to a workflow including the plurality of function calls.

Abstract: A bare metal server, or other computing device, may be represented as a JSON file (extending the concept to infrastructure as code) containing hardware, firmware and software versions with links to a kickstarter file depending on the needs of an application, SKU type or some other criteria. Rather than a management node in an L2 network which has a DHCP server to IP lease and facilitate OS installation, a workflow then generates a bootstrap kernel which initializes the bare metal server with an IP address, VLAN, and network gateway which is used to reach out to the network to download and install a kernel, upgrade firmware for various hardware components like BIOS, BMC, NIC, RAID, SSD, NVME, FPGA, etc. The bootstrap kernel may further configure RAID and JBOD, flash custom images on hardware components and may further instruct the server to incrementally download and install an operating system.

Abstract: Deployment of a network service pipeline may be automated by defining workflows comprising functions of instances of elements. Workflows may be defined in a graphical user interface including menus for the selection of elements, functions, and predefined workflows. A workflow may be dynamic such that addition or modification of a function invokes a trigger that automatically populates or modifies parameters of the functions of the workflow. Elements may each have a same set of functions that may be invoked by an orchestrator to perform automated implementation of the workflow. Functions of a workflow may be implemented in batches and may retrieve executable. data from a distributed file store. A test platform with hardware and network simulation may be used to develop functions and workflows.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be thin clones. An application may use multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and perform operations using the snapshots. Rolling back may include deleting objects other than PVCs, followed by rolling back storage volumes mounted to the PVCs, followed by recreating objects according to an application snapshot. PVCs created by a custom resource may be deleted along with the custom resource with the PVCs being recreated before recreating the custom resource.

Abstract: Deployment of a network service pipeline may be automated by defining workflows comprising functions of instances of elements. Workflows may be defined in a graphical user interface including menus for the selection of elements, functions, and predefined workflows. A workflow may be dynamic such that addition or modification of a function invokes a trigger that automatically populates or modifies parameters of the functions of the workflow. Elements may each have a same set of functions that may be invoked by an orchestrator to perform automated implementation of the workflow. Functions of a workflow may be implemented in batches and may retrieve executable. data from a distributed file store. A test platform with hardware and network simulation may be used to develop functions and workflows.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be thin clones. An application may use multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and perform operations using the snapshots. Rolling back may include deleting objects other than PVCs, followed by rolling back storage volumes mounted to the PVCs, followed by recreating objects according to an application snapshot. PVCs created by a custom resource may be deleted along with the custom resource with the PVCs being recreated before recreating the custom resource.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be thin clones. An application may use multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and perform operations using the snapshots. Rolling back may include deleting objects other than PVCs, followed by rolling back storage volumes mounted to the PVCs, followed by recreating objects according to an application snapshot. PVCs created by a custom resource may be deleted along with the custom resource with the PVCs being recreated before recreating the custom resource.

Abstract: A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. Components of cloned applications may communicate with one another using addresses of these components in the parent application. Jobs implementing a bundled application may be referenced with a simulated file system that generates reads to hosts only when the job log file is actually read. Job logs and a job hierarchy may be used to perform root cause analysis. Job logs may be for tasks such as creating the bundled application, cloning, rolling back, backing up, scaling out, scaling in, deleting, pruning unused application images, or the like.