Oracle International Corporation

Eric Tyler Barsalou

Nathaniel Martin Glass

Caleb Dockter

Greg Mark Jablonski

Phillip Vassenkov

Erik Joseph Miller

Techniques for implementing rollback of infrastructure changes in an infrastructure orchestration service are described. In certain examples, an infrastructure orchestration service is disclosed that manages both provisioning and deploying of infrastructure assets within a cloud environment. The service receives a plan comprising a set of instructions associated with a set of infrastructure assets of an execution target and identifies a first state of the set of infrastructure assets. The service executes the set of instructions in the plan to achieve a second state for the set of infrastructure assets. Based in part on the executing, the service receives a trigger for rolling back the plan to restore the set of infrastructure assets in the plan to the first state and executes a rollback plan for the plan. The service then transmits a result associated with the execution of the rollback plan.

Techniques for implementing rollback of infrastructure changes in a cloud infrastructure orchestration service

A test environment is provided for testing of a flock configuration. A configuration file of a service is parsed to identify one or more capabilities for executing a release of the configuration file of the service. The one or more capabilities correspond to operations performed with respect to one or more resource types. A capability-aware-proxy server included in the test environment is configured based on the one or more capabilities identified from the configuration file of the service. The release of the configuration file of the service is executed in the test environment in accordance with the configured capability aware-proxy server. The capability aware-proxy server generates a response message corresponding to an execution result of the release of the configuration file of the service.

Regional capability aware proxy testing

Techniques for implementing an infrastructure orchestration service are described. A configuration file for a deployment to a first execution target and a second execution target can be received. A first safety plan can be generated for the first execution target that comprises a first list of resources and operations associated with deployment at the first execution target. Approval of the first safety plan can be received. A second safety plan can be generated for the second execution target that comprises a second list of resources and operations associated with deployment at the second execution target. A determination can be made whether the second safety plan is a subset of the first safety plan. If the determination is that the second safety plan is a subset of the first safety plan, the second safety plan can automatically be approved and transmitted to the second execution target for deployment.

Techniques for managing drift in a deployment orchestrator

Techniques are disclosed for managing dependencies in an orchestration service. A computer-implemented method can include operations performed by a declarative infrastructure provisioner (DIP). In some embodiments, the DIP parses configuration data associated with a computing system and generates a directed acyclic graph (DAG) for booting a first resource. The DAG may specify a dependency of the first resource on a capability of a second resource. The DIP may traverse the DAG and determine, based at least in part on the traversal, that the dependency has been reached. The DIP may publish, to a scheduling process, an indication that the first resource is awaiting availability of the capability of the second resource. In some embodiments, the DIP receives a subsequent indication that the capability is available, regenerates the DAG, and recommences traversal of the DAG. Additional operations for booting the first resource may be performed in accordance with the recommenced traversal.

Techniques for managing dependencies of an orchestration service

Techniques for implementing an infrastructure orchestration service are described. A safety plan comprising a list of resources and operations based at least in part on a deployment configuration file can be received. Upon receiving approval of the safety plan, an operation corresponding to at least one of the list of resources can be prepared to be performed. The operation can be compared to the safety plan. If the operation is part of the safety plan, the operation can be performed. If the operation is not part of the safety plan, the deployment can be halted, and a notification that the deployment is not in compliance with the safety plan can be transmitted.

Techniques for detecting drift in a deployment orchestrator

Techniques for implementing an infrastructure orchestration service are described. In some examples, a declarative provisioner of the infrastructure orchestration service receives instructions for deployment of a resource. The declarative provisioner identifies that the deployment of the resource is a long-running task stores state information corresponding to the deployment of the resource. In certain embodiments, upon identifying that the deployment of the resource is a long-running task, the declarative provisioner pauses its execution of the long-running task. Responsive to a trigger received from the infrastructure orchestration service, the declarative provisioner resumes execution of the deployment of the resource using the state information and transmits deployment information corresponding to the deployment of the resource to the infrastructure orchestration service.

Techniques for managing long-running tasks with a declarative provisioner

Techniques for implementing an infrastructure orchestration service are described. In certain embodiments, a cloud infrastructure orchestration system (CIOS) is disclosed that generates customized flock configurations for services to be deployed to different regions supported by the CIOS. The CIOS receives generic configuration information describing a set of infrastructure assets associated with a service and identifies first portions of the generic configuration information for deploying the set of infrastructure assets associated with the service that are configurable. The CIOS receives region configuration information for configuring the generic configuration information and updates the generic configuration information based on the region configuration information. The CIOS then transmits the updated configuration information to set of regions managed by the CIOS.

Environment agnostic configuration with a declarative infrastructure provisioner

Techniques are disclosed for implementing, by a computer infrastructure orchestration service (CIOS) changes to a first service. The CIOS may manage a declarative infrastructure provisioner to deploy infrastructure resources and artifacts based at least in part on declarative instructions. CIOS may detect a first modification to a first service (e.g., a sidecar application). CIOS may identify that configuration data of a second service references (e.g., via a git submodule) the first service. In response to identifying a second modification to the second service, CIOS may present, via a graphical interface, changes comprising the first modification to the first service. User input may be received indicating acceptance or rejection of the changes of the first modification. CIOS may then implement the changes to the first service according to the user input. For example, CIOS may ensure that the first service, as modified, is deployed alongside the second service in subsequent deployments.

Growing community of inventors

Seattle, WA, United States of America

Eric Tyler Barsalou