Managing data center orchestration using service plans and manifests

Abstract

Cloud Infrastructure Orchestration Services (CIOS) may be used to generate service plans and manifests (SPAMs) that define the deterministic order of releases for bootstrapping services into a cloud computing environment (e.g., a data center) (e.g., provisioning and deploying service resources). The corresponding manifests may be used to identify that they are configuration files and artifacts. The manifests may be used to validate the service plans. CIOS may be configured to validate SPAMs. SPAMs may be added to a set of SPAMs if compatible. The set of SPAMs (a collection of SPAMs corresponding to each service) may be used to extract a version set (identifying configuration file and artifact versions), which may generate a directed acyclic graph. CIOS bootstraps various services into the data center based at least in part on traversing the directed acyclic graph.

Description

【Technical Field】 【0001】 Cross - Reference to Related Applications This non - provisional application claims priority to U.S. Provisional Patent Application No. 63 / 503,145, filed on May 18, 2023, entitled "Region Build Orchestration using Skills and Capabilities" and U.S. Non - Provisional Patent Application No. 18 / 661,401, filed on May 10, 2024, entitled "Managing Data Center Orchestration using Service Plans and Manifests1", the disclosures of which are hereby incorporated by reference in their entirety for all purposes. 【0002】 Field of the Invention The present disclosure relates to using service plans and manifests (SPAMs) that individually serve as specifications for a bootstrap process for one service. Service plans and manifests (SPAMs) provide a complete service build description that specifies the releases that may (or are) necessary to build a service and the definitive / clear order of those releases. SPAMs may include a clear prediction of the progress expected for each migration (e.g., each release execution corresponding to a specific phase / execution target). One or more services (e.g., all services bootstrapped within a region) may be associated with corresponding SPAMs. The information provided by these SPAMs may be used to eliminate various errors that may occur in data center construction by identifying problems earlier in the build lifecycle rather than at build time (e.g., at the time of SPAM submission). 【Background Art】 【0003】 Background Today, cloud infrastructure services utilize many individual services to build data centers (for example, to bootstrap various resources into data centers in a specific geographical region). A region is a logical abstraction corresponding to a local geographical area where one or more data centers are located (or will be located). Building a data center (also called performing a “region build”) may include provisioning and configuring infrastructure resources and deploying code to these resources (for example, to implement various services). Any appropriate number of data centers may be contained within a region, and therefore, a region build may include operations to build a large number of data centers. A bootstrap operation for one service may depend on other functions and / or services within the region. As the number of service teams and regions increases, the tasks performed to orchestrate provisioning and deployment increase dramatically. Traditional tools for building regions require significant manual effort, or automated technologies offer drawbacks in terms of overhead, accuracy, and ease of use. Improvements can be made. [Overview of the project] [Problems that the invention aims to solve] 【0004】 Brief Overview Embodiments of this disclosure relate to techniques for constructing data centers. Previous implementations lacked a centralized description from which to derive the operations required to construct services. Instead, service construction information was scattered across numerous configuration files. Current implementations lack specifications on how services are constructed and only include implementation details. This leads to a lack of understanding of service construction and significantly increases the effort required to resolve problems during data center construction. This disclosure relates to the use of service plans and manifests to generate or validate directed acyclic graphs from which orchestration operations are performed. A service plan refers to a description of how services are constructed in a data center. A "service manifest" details which configuration files (e.g., "flocks") and artifacts (e.g., software) should be used to construct the services. 【0005】 At least one embodiment relates to a method performed by a computer (abbreviated as the “Method”). The Method may include obtaining a service plan from a cloud infrastructure orchestration system that defines a first sequence for executing one or more releases as part of a first process for bootstrapping services within a cloud computing environment. The Method may include obtaining a manifest from a cloud infrastructure orchestration service that identifies configuration files defining operations associated with executing one or more releases. The Method may include generating a directed acyclic graph from a plurality of service plans, including the service plan, at least in part, from the cloud infrastructure orchestration service. The directed acyclic graph may define a second sequence for executing a set of releases, including the releases. The set of releases may be associated with a second process for bootstrapping multiple services within a cloud computing environment. The Method may include executing a subset of the releases from the set of releases associated with the second process for bootstrapping multiple services within a cloud computing environment, from the cloud infrastructure orchestration service. In some embodiments, the subset of releases may be executed according to a second sequence, at least in part, based on traversing the directed acyclic graph. 【0006】 The method may include validating the service plan based at least partially on the manifest by a cloud infrastructure orchestration service. In some embodiments, validating the service plan based at least partially on the manifest further includes: 1) the cloud infrastructure orchestration service obtaining static flock analysis data corresponding to the configuration files identified by the manifest, the static flock analysis indicating a first set of dependencies; 2) the cloud infrastructure orchestration service determining a second set of dependencies based at least partially on the service plan; and 3) the cloud infrastructure orchestration service determining that the first set of dependencies matches the second set of dependencies. 【0007】 The method may further include determining that the service plan is consistent, at least in part, based on the cloud infrastructure orchestration service determining that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. 【0008】 The method may further include, by a cloud infrastructure orchestration service, determining that the multiple service plans are compatible, at least in part, based on 1) generating a directed graph at least in part on multiple service plans, and 2) determining that the directed graph lacks cycles. In some embodiments, the method may include, by a cloud infrastructure orchestration service, adding a service plan to a set of service plans that includes multiple service plans. In some embodiments, the service plan is added to the set of service plans at least in part on determining that the multiple service plans are compatible. The method may also include, by a cloud infrastructure orchestration service, extracting a version set that identifies multiple configuration files, which are in the middle of a second process for bootstrapping multiple services within a cloud computing environment. The version set may be extracted at least in part on a set of service plans. 【0009】 In some embodiments, a version set includes multiple version set items, the first of which is associated with a corresponding service plan, and the second of which is unrelated to any service plan associations. 【0010】 In some embodiments, the method may further include determining that multiple service plans are compatible, at least in part, based on the determination by a cloud infrastructure orchestration service that no replication capability publications exist between the multiple service plans. 【0011】 Another embodiment relates to a cloud computing service that includes one or more processors and a memory storing instructions, when executed by the one or more processors, causing the cloud computing service to perform the methods disclosed herein. 【0012】 Another embodiment relates to a non-temporary computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a cloud computing service, cause the cloud computing service to perform the methods disclosed herein. 【0013】 To facilitate the identification of any particular element or action, the most important one or more digits in the reference number represent the drawing number in which that element is first introduced. [Brief explanation of the drawing] 【0014】 [Figure 1] This is a block diagram of an environment in which a cloud infrastructure orchestration system (CIOS), according to at least one embodiment, may operate to dynamically bootstrap services in a region. [Figure 2] This block diagram shows an environment and method for constructing a virtual bootstrap environment (ViBE) according to at least one embodiment. [Figure 3] This block diagram shows an environment and method for bootstrapping a service to a target region using ViBE, according to at least one embodiment. [Figure 4] This block diagram shows a data model representing various skill-related metadata in at least one embodiment. [Figure 5] A block diagram showing a data model representing various metadata associated with SPAM, according to at least one embodiment. [Figure 6]Block diagram showing exemplary service plan and manifest construction milestone entities according to at least one embodiment. [Figure 7] An exemplary execution unit entity of an exemplary service plan is shown in at least one embodiment. [Figure 8] An exemplary flock setting entity for an exemplary service plan is shown according to at least one embodiment. [Figure 9] This is a block diagram illustrating the relationship between parts of a service plan and a manifest, according to at least one embodiment. [Figure 10] This is a block diagram illustrating the relationship between a flock, a number of phases, a corresponding number of execution targets for each phase, and one or more execution target checkpoints of the execution targets, according to at least one embodiment. [Figure 11] This flowchart illustrates a method for generating a service plan, according to at least one embodiment. [Figure 12] This flowchart illustrates a method for generating service plans and manifests (SPAM) according to at least one embodiment. [Figure 13] This flowchart illustrates a method for adding SPAM to a SPAM set, according to at least one embodiment. [Figure 14] This block diagram shows an exemplary lifecycle for a skill, according to at least one embodiment. [Figure 15] This flowchart illustrates an exemplary method for managing skill status during data center / region construction, according to at least one embodiment. [Figure 16] This block diagram shows an exemplary method for managing compatibility between capabilities and skills, according to at least one embodiment. [Figure 17]A flowchart showing an exemplary method for using a service plan and a manifest to determine or verify the operation of a data center construction, according to at least one embodiment. [Figure 18] A block diagram showing one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 19] A block diagram showing another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 20] A block diagram showing another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 21] A block diagram showing another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 22] A block diagram showing an exemplary computer system, according to at least one embodiment. **DETAILED DESCRIPTION OF THE INVENTION** 【0015】 Detailed Description In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of one embodiment. However, it will be apparent that various embodiments may be practiced without these specific details. The drawings and the description are not intended to be restrictive. The term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments or designs. 【0016】 Exemplary Automated Data Center Construction (Region Construction) Infrastructure The adoption of cloud services has shown rapid growth in recent years. Now, various types of cloud services are offered by various cloud service providers (CSPs). The term "cloud service" is generally used to refer to services or functions made available on demand (e.g., via a subscription model) by a CSP to users or customers using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure used to provide cloud services to customers are separate from the customer's own self-operated servers and systems. Therefore, customers can use cloud services provided by a CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide subscribers with easy, scalable, and on-demand access to applications and computing resources without the need for customers to invest in procuring the infrastructure used to deliver the service or function. Various different types or models of cloud services may be offered, such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and others. Customers can subscribe to one or more cloud services offered by a CSP. Customers can be any entity, including individuals, organizations, and companies. 【0017】 As described above, a CSP is responsible for providing the infrastructure and resources used to provide cloud services to its subscribing customers. The resources provided by a CSP can include both hardware and software resources. These resources can include, for example, compute resources (e.g., virtual machines, containers, applications, processors), memory resources (e.g., databases, datastores), network resources (e.g., routers, host machines, load balancers), identity, and other resources. In one implementation, the resources provided by a CSP to provide a set of cloud service CSPs are organized in a data center. The data center may be configured to provide a particular set of cloud services. The CSP is responsible for providing the infrastructure and resources used to provide that particular set of cloud services in the data center. A CSP may build one or more data centers. 【0018】 Data centers provided by a CSP may be hosted in different regions. A region is a local geographical area and may be identified by a region name. Regions are generally independent of each other and can be separated by large distances, such as across countries or even continents. Regions are grouped into realms. Examples of regions for a CSP may include US West, US East, Australia East, Australia Southeast, and so on. 【0019】 A region may contain one or more data centers, which are located within a geographical area corresponding to the region. For example, a data center in a region may be located in a city within that region. For instance, for a particular CSP, a data center in the US West region may be located in San Jose, California; a data center in the US East region may be located in Ashburn, Virginia; a data center in the Australia East region may be located in Sydney, Australia; and a data center in the Australia Southeast region may be located in Melbourne, Australia. 【0020】 Data centers within a region may be organized into one or more availability domains, which are used for high availability and disaster recovery purposes. An availability domain can contain one or more data centers within a region. Availability domains within a region are isolated from each other, fault-tolerant, and designed to make it very unlikely that data centers in multiple availability domains will fail simultaneously. For example, availability domains within a region may be structured so that a failure in one availability domain within a region is unlikely to affect the availability of data centers in other availability domains within the same region. 【0021】 When a customer or subscriber subscribes to or contracts for one or more services provided by a CSP, the CSP creates a tenancy for the customer. A tenancy is like an account created for the customer. In one implementation, a customer's tenancy resides in a single realm and has access to all regions belonging to that realm. Therefore, the customer's users can access the services subscribed to by the customer under this tenancy. 【0022】 As described above, CSPs build or deploy data centers to provide cloud services to their customers. As a CSP's customer base grows, CSPs typically build new data centers in new regions or increase the capacity of existing data centers to serve the growing demand of their customers and to better serve their customers. Preferably, data centers are built in geographical proximity to the locations of customers served by those data centers. Geographic proximity between a data center and the customers served by that data center leads to more efficient use of resources and faster, more reliable service for customers. Therefore, CSPs typically build new data centers in new regions in geographical areas that are geographically close to the customers served by the data centers. For example, for a growing customer base in Germany, a CSP may build one or more data centers in a new region in Germany. 【0023】 Building a data center (or a number of data centers) in a region is sometimes also referred to as building a region. The term “region building” is used to refer to building one or more data centers in a region. Building a data center in a region requires provisioning or generating a new set of resources that are needed or used to provide the set of services that the data center is configured to provide. The final result of the region building process is the creation of a data center in the region that can provide the set of services intended for that data center and includes the set of resources used to provide that set of services. 【0024】 Building a new data center in a region is an extremely complex activity that requires coordination between various service teams. At a high level, this involves performing and coordinating various tasks, such as identifying the set of services the data center will provide, identifying the various resources required to provide those services, generating, provisioning, and deploying the identified resources, and properly wiring the resources so that they can be used in the intended way. Each of these tasks has subtasks that need to be coordinated, further increasing the complexity. This complexity means that building a data center in a region currently requires several manually initiated or manually controlled tasks that require careful manual coordination. As a result, the task of building a new region (i.e., building one or more data centers in a region) is extremely time-consuming. Building a data center can take time, for example, several months. In addition, the process is highly error-prone and sometimes requires several iterations before the desired configuration of the data center is achieved, which further increases the time it takes to build a data center. These limitations and issues significantly restrict the CSP's ability to grow in a timely manner in response to increasing customer needs. 【0025】 Bootstrap operations are coordinated and orchestrated by an orchestrator (e.g., a multi-flock orchestrator, orchestration service, etc.). In previous implementations, the orchestrator attempted to automatically detect dependencies between operations. The orchestrator utilized various versions of configuration files and / or software artifacts, attempting to intelligently and automatically identify the artifacts and the form in which the data center construction was performed. Once the data center was built, the orchestrator utilized capabilities (e.g., tags that could be toggled on or off to indicate the availability of resources or functions) to drive these operations. However, both the use of automated detection techniques and capabilities had drawbacks. 【0026】 Previous implementations of the orchestrator lacked a precise plan of the work that might (or might be required) to build the data center before the actual build. The orchestrator utilized service build definitions distributed across numerous flock configuration files ("flock settings") and interpreted by the orchestrator at runtime. This resulted in the orchestrator executing an unspecified number of releases in an unspecified order, with each orchestrator publishing an unspecified number of capabilities for each release. To compensate for this non-deterministic behavior, manually curated microschedules were generated and used to track the work and order of operations required to build the data center. These microschedules were neither machine-executable nor derived from code. Service teams were not prevented from modifying build automation that might override existing microschedules. Additionally, when configuration files for a service depended on external data, it was impossible to determine the exact behavior of the service build. 【0027】 Technical effects In previous implementations, region build tasks were triggered by publishing capabilities. Capability availability was not constant across releases, and the publication of any selective capabilities mid-release led to nondeterminism in planned activities. Additionally, the use of selective capabilities made it difficult to determine when a release was expected to publish certain capabilities as it was about to be generated. Service teams could also introduce changes that created unsatisfactory periodic dependencies between services, either deadlocking builds or relying on capabilities that were never published. For these reasons alone, it was impossible to determine when dependent releases would be unblocked. Heterogeneity across different regions also meant there was no single plan for how services should be bootstrapped. Rather, different plans existed for each area, which compounded the difficulty of understanding how services should be built, as capabilities were made dependent on or published in certain types of regions and not dependent on or not published in other types of regions. 【0028】 Embodiments of this disclosure relate to the use of service plans and manifests (SPAMs) that individually function as deterministic specifications for the bootstrapping process of a single service. A service plan and manifest (SPAM) provides a complete service build description specifying the releases that may (or are) required to build the service and the deterministic / explicit order of those releases. A SPAM may include clear predictions for the progress expected by each migration (e.g., each release execution corresponds to a specific phase / execution target). One or more services (e.g., all services to be bootstrapped within a region) may be associated with a corresponding SPAM. The information provided by these SPAMs may be used to eliminate various errors that may occur in data center construction by identifying problems early in the build lifecycle (e.g., at the time of SPAM submission) rather than at build time. 【0029】 SPAM may be composed of an orchestrator (e.g., a multi-flock orchestrator, orchestration service, etc.) and may be used to form a directed acyclic graph (DAG) of work (e.g., releases) that identifies the expected order of release executions (which may be required (or in some examples required) to build a data center) and capability dependencies between these releases. The defined graph may be pre-certified for anomalies such as cycles in generation and subsequent region updates. The graph may be used to support improved error detection both before and during construction. The graph generated from SPAM may be used to drive region construction operations and / or to authenticate different graphs (e.g., graphs generated from flock configurations, as in previous implementations) used to drive region construction. SPAM provides a deterministic specification for the construction implementation for the required service, which reduces, if not eliminates, the non-deterministic drawbacks present in previous implementations that relied on numerous flock configurations to identify the releases that may be required (or required) to build the service. This improves the observability and understanding of region construction, and reduces the time and complexity required to identify root causes when errors occur during region construction. 【0030】 definition A "region" is a logical abstraction corresponding to a geographical location. A region can contain any appropriate number of one or more execution targets. 【0031】 A "phase" refers to a group of execution targets that can be run simultaneously. An "execution target" refers to a unit of change for executing a release. Execution targets may be region and tenancy specific. Execution targets may be aggregated into one or more phases. For some services, an execution target represents an "instance" of the service. A single service can be bootstrapped into one or more execution targets. Execution targets may be associated with a set of devices (e.g., a data center). 【0032】 A “release” is an expression of intent to orchestrate a specific change to a service (e.g., Deployment Version 9, “Add Internal DNS”). In some embodiments, a release corresponds to an instance of infrastructure provisioning or application deployment. A release may target one or more phases or execution targets. 【0033】 "Bootstrapping" is intended to refer to the collective task associated with provisioning and deploying any appropriate number of resources (e.g., infrastructure components, artifacts, etc.) corresponding to a single service. 【0034】 A "service" refers to the functionality provided by a set of resources. The set of resources for a service includes any suitable combination of infrastructure, platforms, or software (e.g., applications) hosted by a cloud provider that can be configured to provide the functionality of the service. A service can be made available to users over the internet. 【0035】 "Artifact" means, but is not limited to, code deployed to infrastructure components (e.g., physical or virtual hosts) or Kubernetes engine clusters. This may also include, but is not limited to, software (e.g., applications), configuration information for infrastructure components (e.g., configuration files), etc. 【0036】 A “flock configuration file,” or simply “flock configuration,” refers to a configuration file that describes a set of resources associated with a service (e.g., infrastructure components and artifacts, also called “flocks”). A flock configuration may correspond to a single release (e.g., provisioning and / or deployment tasks performed as a unit). A flock configuration may correspond to an infrastructure release or an application release. A service may be built using any appropriate number of releases and corresponding flock configurations. A flock configuration may contain declarative statements that specify one or more embodiments of the service's resources corresponding to a desired state for that release. 【0037】 A "flock" refers to a set of CIOS-managed resources or execution targets that can be deployed as a unit. Flocks may reside within an organizational unit called a "project." 【0038】 "Service state" refers to a snapshot of all resources associated with a service (e.g., infrastructure resources, artifacts, etc.) at the present time. The service state indicates the status corresponding to the provisioning and / or deployment tasks associated with the service resources. 【0039】 IaaS provisioning (or "provisioning") means acquiring computers or virtual hosts for use, and even installing necessary libraries or services on them. The expression "provisioning a device" means developing a device into a state where it can be used by an end user for their specific use. A device that has undergone the provisioning process may be called a "provisioned device." Preparing a provisioned device (installing libraries and daemons) may be part of provisioning. This preparation is different from deploying a new application or a new version of an application to a prepared device. In most cases, deployment does not involve provisioning, and provisioning may need to be performed first. Once prepared, a device may be called an "infrastructure component." 【0040】 IaaS deployment (or “deployment”) refers to the process of providing and / or installing a new application or a new version of an application to provisioned infrastructure components. Once infrastructure components are provisioned (e.g., acquired, assigned, prepared), additional software may be deployed (e.g., provided and installed on the infrastructure components). After provisioning and deployment are complete, infrastructure components can be referred to as “resources.” Examples of resources may include, but are not limited to, virtual machines, databases, object storage, block storage, and load balancers. 【0041】 A "Virtual Bootstrap Environment" (ViBE) refers to a virtual cloud network provisioned over an existing region (e.g., a "host region"). Once provisioned, the ViBE connects to the new region using a communication channel (e.g., an IPsec tunnel VPN). Certain essential core services (or "seed" services), such as a deployment orchestrator and public key infrastructure (PKI) services, can be provisioned in the ViBE. These services can bring hardware online, establish a chain of trust to the new region, and provide the capabilities needed to deploy the remaining services in the new region. Utilizing a virtual bootstrap environment prevents circular dependencies between bootstrap resources by leveraging the resources of the host region. Services can be staged and tested in the ViBE before the physical region (e.g., the target region) becomes available. 【0042】 A "Cloud Infrastructure Orchestration Service" (CIOS) can refer to a system configured to manage provisioning and deployment operations for any appropriate number of services as part of region construction. 【0043】 The "host region" refers to the region that hosts the virtual bootstrap environment (ViBE). The host region can be used to bootstrap the ViBE. 【0044】 "Target region" refers to the region being built. A "capability" is a resource used during region construction to signal that another resource, service, or feature is available or that an event has occurred. For example, a capability can be published to indicate that a resource is available for authorization / authentication processing (a subset of the functionality provided by the service). Another example is publishing a capability to indicate that the full functionality of a service is available. Capabilities may also be used to identify the functionality on which a resource or service depends and / or the functionality of resources or services available for use. Capabilities may be associated with alphanumeric identifiers, which may be used to indicate whether a capability is available or unavailable. 【0045】 "Publishing a capability" means "publishing" as used in a "publisher-subscriber" computing design or other context that provides instructions that a particular capability is available (or unavailable). Capabilities are "published" (e.g., collected by a capability service, provided to a capability service, pushed, pulled, etc.) to provide instructions that a resource / service function is available or that an event has occurred. In some embodiments, capabilities may be published / transmitted via events, notifications, data transmissions, function calls, API calls, etc. Events (or other notifications / data transmissions / etc.) indicating the availability of a particular capability can be broadcast / addressed (e.g., published) to a capability service. 【0046】 A "Capability Service" may be a service configured to monitor and maintain capability data indicating which capabilities are currently available in a region. The Capability Service may be provided within a cloud infrastructure orchestration system and may be used to identify which capabilities, services, or features have been made available in a region, or what events have occurred in that region. The described Capability Service may act as a central repository / authority for all capabilities published in a region (e.g., during region construction). 【0047】 The term "orchestrator" is intended to refer to a service or system that initiates the task of bootstrapping one or more services during region construction. An example of an orchestrator is a multi-flock orchestrator (MFO), which may be a computing component (e.g., a service) configured to coordinate events among CIOS components to provision and deploy services in a target region (e.g., a new region). The orchestrator may track relevant events for each service in region construction (indicated through capabilities and / or skills as described herein) and take action in response to these events (e.g., based on determining that upstream dependencies have been met for a given release / skill). 【0048】 A "Real-time Regional Data Distributor" (RRDD) can be a service or system configured to manage regional data. This regional data can be injected into a flock configuration to dynamically generate execution targets for new regions. 【0049】 A “telemetry service” may be a service or system configured to manage / monitor time-series data associated with one or more services / resources and to trigger various alarms and / or corresponding alarm states (e.g., publish, store, etc.) based on at least partially analyzing the time-series data. 【0050】 A “skill service” (also known as a “puffin”) may be a service or system configured to store planned and / or actual dependencies between units of services, resources, or functions (also known as “service functions”). Units of functions should be allowed to relate to mechanisms provided by computing components other than services. 【0051】 A “skill” may represent a functional unit that a service exposes to and provides to a consumer (e.g., another service). This functional unit (also called a “service function”) may include all or a subset of all functionalities associated with the service. In some embodiments, a skill may be scoped where access is controlled based on access and / or authentication policies and / or association with a particular namespace. A skill may be provided in a number of versions in which one or more aspects of the skill differ from other versions, and each skill version represents a particular implementation of the skill. Each skill version may be identifiable using a unique skill identifier. A skill is intended to replace (some or all) capabilities and enable improved and more accurate progress tracking and enhanced root cause analysis capabilities when errors or unexpected events occur in the build. In some embodiments, a skill may be associated with one or more previously defined capabilities to provide backward compatibility with previous capability-based region build implementations. A skill may be monitored for health and may be configured to maintain health data. "Skill" may collectively mean any appropriate number of data structures (e.g., skill metadata 404 in Figure 4) where data defining skills may be maintained. 【0052】 "Fleet" refers to a logical environment (e.g., pre-production, production, etc.) to which a skill can be scoped. For example, a skill associated with a production fleet may be distinct from a skill with the same name used with a pre-production fleet. "Project" may be used similarly to scope a skill. In some embodiments, a skill may be scoped / applied to a specific environment at least in part on any appropriate combination of attributes such as skillID, skillversionID, compartmentID, namespaceID, producerServiceID, skillName, fleet, and project, which collectively identify a particular application of the skill. 【0053】 A "service plan specification," or simply "service plan," refers to a specification for the build implementation of a service. A service plan may include any appropriate combination of build milestones, execution units, and flock configurations. The service plan details the specific releases that may (or may be) required to build the service and the order in which releases will be made to build the service. The service plan may separate inter-service coordination and intra-service coordination. The service plan may specify the expected state of the service at any appropriate point in the region build. 【0054】 A "service manifest," or simply a "manifest," identifies the versions of the flock configurations and artifacts used to build a service. A service manifest may consist of a set of service manifest items, each of which identifies a specific flock configuration or artifact that may (or may be) required to build the service. In some embodiments, a service manifest item may be associated with the git commit hash of the flock and all version declarations for any artifacts required in the application release for building the service. 【0055】 A “SPAM” (also known as a “Service Build Description”) refers to a combination of a service plan and a manifest that collectively provides a deterministic specification of the process for building a service. In some embodiments, a SPAM details the combination and sequence of releases that may (or may be required) to build a service. The manifest in a SPAM may define all resources used for the releases, while the service plan specifies the order of release executions based on capability dependencies. SPAMs may be used to track compliance for regional builds. A SPAM details the releases that may (or may be required) to build a service, each release of which may be associated with prerequisites and postconditions. Prerequisites may mean capabilities that may (or, in some examples, must) exist in order to generate a release that results in the fulfillment of a postcondition. Postconditions may be capabilities that should (or, in some cases, must) be published as a result of a successful release. SPAMs may be generated by a service team and may be extracted from a YAML file written by the service team. SPAM may be described in separate sections, including execution units that define transitions between clearly defined points in the construction of a service, known as “construction milestones.” A service may transition from one construction milestone to the next by executing releases defined by the execution units. Execution units may specify external dependencies (capabilities) that may be required (or are required) to execute releases defined within the unit. Construction milestones may specify capabilities to be published by the service that should (or, in some cases, must be) made available when the service reaches that milestone. In some embodiments, capabilities specified by a construction milestone include capabilities intended for consumption by other services. 【0056】 A “SPAM set” means a collection on SPAM that is compatible with each other and / or is pre-associated with each other. A SPAM set may be used to extract a set of versions, by which a directed acyclic graph may be generated, and may be used to drive operations for building a data center. In some embodiments, a SPAM set may be associated with a scope and / or regional context. 【0057】 A “construction milestone” refers to an entity defined in a service plan that identifies a point of synchronization between service construction (e.g., the process for building a specific service) and the rest of the data center construction. Construction milestones may be broadly defined to limit their number and provide a high-level overview of the process for building the service. As a non-limiting example, a set of construction milestones for a service may include “absent” (e.g., the default starting milestone), “Service Function X Available,” “Service Available,” and “Service Construction Complete.” 【0058】 An "execution unit" refers to another entity in a service plan. One or more execution units may describe a process for moving from one build milestone to the next build milestone through a directed acyclic graph of CIOS releases (e.g., infrastructure and / or application releases). 【0059】 An "execution target checkpoint," or "ET checkpoint" for short, refers to a defined point in the construction of a given execution target data center. An ET checkpoint may be associated with certain prerequisites (e.g., required capability dependencies) and post-conditions (capability publications) that must be met when the ET checkpoint is reached. In some embodiments, a step identified within an execution unit may refer to an ET checkpoint transition that can be logically mapped to an expected CIOS release (e.g., an infrastructure or application release). 【0060】 A "region archetype" may represent the overall structure of a region (e.g., an ONSR region, a single availability domain region, or the first region in a realm) that can be used to influence the installation of a service. In some embodiments, a service plan may refer to a dimension of the region archetype to conditionally modify the service plan definition. 【0061】 A “version set” may be used to define all flock configuration files and artifact versions across all services in a specific regional context (for example, a specific region such as “region1” and a specific version set identifier such as “golden” or “break glass” are given). A version set may consist of many version set items, each of which may specify a flock and the artifacts for that flock. These entities may identify the presence of SPAM and SPAM sets. For example, in some embodiments, a version set may be associated with a corresponding SPAM set. Any suitable version set item may be associated with the SPAM corresponding to the service from which it was extracted and / or a common service. 【0062】 "Static flock analysis" refers to performing a static analysis of the code (identifying data center infrastructure components as objects using a declarative construct language) to infer capability publications and / or dependencies. In some embodiments, static flock analysis may be performed using infrastructure-as-code software tools (e.g., Terraform®). In some embodiments, this software tool may generate one or more data structures (e.g., a directed acyclic graph) representing these dependencies / publications. Each node in the graph may correspond to a flock setting and / or release, and edges identify dependencies between capability publications and / or releases. 【0063】 In some examples, techniques for implementing Cloud Infrastructure Orchestration Services (CIOS) are described herein. Such techniques can be configured to manage the bootstrapping of infrastructure components within a cloud environment (e.g., a region) (e.g., provisioning and deploying software to infrastructure components), as briefly described above. In some examples, CIOS may include compute components (e.g., CIOS Central and CIOS Regional) that can be configured to manage bootstrap tasks (provisioning and deployment) for a given service, and orchestrators (e.g., multi-flock orchestrators) configured to initiate / manage region construction (e.g., bootstrap operations for a number of services in a region / data center). 【0064】 CIOS enables region / datacenter construction and global infrastructure provisioning and code deployment with minimal manual runtime effort from service teams (e.g., beyond initial hardware approval and / or physical transport in some cases). High-level responsibilities of CIOS include, but are not limited to, coordinating region construction in an automated form with minimal human intervention, providing users with a current view of resources managed by CIOS (e.g., regional, cross-region, global, etc.), and managing bootstrap operations to bootstrap resources within a region. 【0065】 CIOS may provide view reconciliation, where a view of a resource in a desired state (e.g., a desired configuration) can be reconciled by the resource's current / actual state (e.g., current configuration). In some examples, view reconciliation may involve retrieving state data to identify which resources are actually running and their current configuration and / or state. Reconciliation can be performed at various granularities, such as at the service level. 【0066】 CIOS can perform plan generation, which identifies the difference between the desired state and the current state of a resource. The plan generation part may include identifying the operations that need to be performed to bring the resource from its current state to the desired state. If the user is satisfied with the plan, it can then be marked as approved or rejected. Therefore, the user can spend less time deciding on the plan, and because the plan is machine-generated, it is more accurate. The plan is almost too detailed for human consumption. However, CIOS can provide this data through a highly sophisticated user interface (UI). 【0067】 In some cases, CIOS can handle change management execution by automatically executing approved plans. Once an execution plan is generated and approved, engineers may no longer need to be involved in change management until CIOS initiates the rollback. CIOS can handle rollbacks to previous service versions by automatically generating a plan to revert the service to a previous state (e.g., pre-release) (for example, when CIOS detects a service health degradation while executing). 【0068】 CIOS can measure service health by monitoring alarms and performing integration tests. CIOS can help teams quickly define rollback behavior in the event of a service degradation, and then automatically execute that rollback behavior later. CIOS can automatically generate and display plans and track approvals. CIOS can combine provisioning and deployment capabilities in a single system that coordinates these tasks across region builds. CIOS can discover dependencies between execution tasks at all levels (e.g., resource level, execution target level, phase level, service level, etc.) by static analysis of one or more configuration files (e.g., including parsing and processing content). Using these dependencies, CIOS can generate various data structures from them, which can be used to drive task execution (e.g., tasks related to provisioning infrastructure resources and deploying artifacts across regions). 【0069】 Today, during large-scale events (LSEs) (e.g., events resulting in significant errors, disruptions, or delays in region construction), incident management and region construction operators often face extensive overhead and delays in gathering information, such as status, problem attributes, impact assessments, and service recovery, due to the significantly human-based and unsystematic approach of traditional methods. The complexity of various inter-service dependencies can make it extremely difficult and time-consuming for operators to identify the root cause of an event. This results in delays in remediation and the ability to assess when the event was completed. Similarly, region construction involves challenges where human involvement may be utilized to resolve and / or detect failure or disruption situations. Traditionally, it has been difficult for service teams to determine what dependencies exist for a service and when, both in terms of the dependencies a service may have on other services and vice versa. Additionally, service teams have incomplete indicators before actual region construction of whether the region construction design has significant issues (such as cyclical dependencies) that could hinder or delay service construction. 【0070】 Figure 1 is a block diagram of an environment 100 in which a cloud infrastructure orchestration system (CIOS) 102 may operate to dynamically bootstrap services in a region / data center, according to at least one embodiment. CIOS 102 may include, but is not limited to, the following components: a real-time regional data distributor (RRDD) 104, an orchestrator 106, a CIOS central 108, a CIOS regional 110, capability services 112, a virtual bootstrap environment 116, a Puffin central 118, a Puffin regional 120, and alarm services 122. Specific functionalities provided by the CIOS central 108 and CIOS regional 110 are described in detail in U.S. Patent Application No. 17 / 016,754, entitled "Techniques for Deploying Infrastructure Resources with a Declarative Provisioning Tool," the entire content of which is incorporated as a whole for all purposes. In some embodiments, any suitable combination of the components of CIOS 102 may be provided as a service. In some embodiments, a portion of CIOS102 may be deployed in a region (for example, a data center represented by host region 103). In some embodiments, CIOS102 may include any appropriate number of cloud services (not shown in Figure 1) which will be considered in more detail below with respect to Figures 2 and 3. 【0071】 The Real-Time Regional Data Distributor (RRDD) 104 may be configured to maintain and provide regional data that identifies realms, regions, execution targets, and availability domains. In some cases, the regional data may be in any appropriate format (e.g., JSON format, data object / container, XML, etc.). The regional data maintained by RRDD 104 may include any appropriate number of subsets of data that can be individually referenced by corresponding identifiers. For example, the identifier "all_regions" may be associated with a data structure (e.g., a list, structure, object, etc.) containing metadata for all defined regions. As another example, an identifier such as "realm" may be associated with a data structure that identifies metadata for a number of realms and a set of regions corresponding to each realm. Generally, the regional data may maintain any appropriate attributes of one or more realms, regions, availability domains (ADs), execution targets (ETs), etc., such as identifiers, DNS extensions, and state (e.g., state of the region). RRDD 104 may be configured to manage the regional state as part of the regional data. The regional state may include any appropriate information that indicates the state of the bootstrap within the region. For example, some exemplary region states may include “Initial,” “Building,” “Production,” “Hibernation,” or “Decommissioned.” The “Initial” state may indicate a region that has not yet been bootstrapped. The “Building” state may indicate that bootstrapping has begun for one or more flocks within the region. The “Production” state may indicate that bootstrapping is complete and the region is ready for verification. The “Hibernation” state may indicate that CIOS Central 108 or CIOS Regional 110 has suspended internal interaction with the regional stack, possibly due to operational issues. The “Decommissioned” state may indicate that a region is decommissioned and is likely to become unavailable and / or will not be contacted again. 【0072】 CIOS Central 108 is configured to provide any appropriate number of user interfaces through which a user (e.g., user 109) can interact with CIOS 102. For example, a user can make changes to regional data through a user interface provided by CIOS Central 108. CIOS Central 108 may also provide various interfaces that allow users to view changes made to flock settings and / or artifacts, generate and view plans, approve / reject plans, and view the status of plan execution (e.g., infrastructure provisioning, deployment, region building, and / or desired state for any appropriate number of resources managed by CIOS 102). CIOS Central 108 may enforce a control plane configured to manage any appropriate number of CIOS Regional 110 instances. CIOS Central 108 can provide one or more user interfaces to represent regional data, allowing user 109 to view and / or modify regional data. CIOS Central 108 can be configured to invoke the functions of RRDD 104 through any appropriate number of interfaces. Generally, CIOS Central 108 (also known as the “Provisioning and Deployment Manager”) may be configured to manage regional data directly or indirectly (e.g., via RRDD 104). CIOS Central 108 may be configured to compile flock configurations (and / or SPAMs) to inject regional data as variables within the flock configurations (and / or SPAMs). CIOS Central 108 may be instructed (e.g., by Orchestrator 106) to execute one or more releases (e.g., infrastructure or application releases) corresponding to the flock configurations. 【0073】 Each instance of CIOS Regional 110 may correspond to a module configured to perform a bootstrap task associated with a service in a region (e.g., a data center such as host region 103). CIOS Regional 110 can receive desired state data from CIOS Central 108. In some embodiments, the desired state data may include flock settings that declare the desired state of the resources associated with the service (e.g., via declaration statements). CIOS Central 108 can maintain current state data that represents any appropriate aspect of the current state of the resources associated with the service. In some embodiments, CIOS Regional 110 can identify changes that may be (or are) necessary for one or more resources by comparing the desired state data with the current state data. For example, CIOS Regional 110 can determine that one or more infrastructure components need to be provisioned, one or more artifacts need to be deployed, or any appropriate changes that may be (or are) necessary for the resources of the service to bring the state of these resources to match the desired state. As CIOS Regional 110 performs the bootstrap operation, CIOS Regional 110 may issue data indicating the various capabilities of a resource as it becomes available. “Capability” identifies a unit of functionality associated with a service. A unit can be some or all of the functionality provided by the service. For example, a capability may be issued indicating that a resource is available for authorization / authentication processing (e.g., a subset of the functionality provided by the resource). Another example is the issuance of a capability indicating that the full functionality of a service is available. Capabilities can be used to identify the functionality on which a resource or service depends and / or the functionality of a resource or service available for use.In some embodiments, the CIOS regional 110 may transmit data indicating a skill state transition. For example, in some embodiments, the CIOS regional 110 performs a bootstrap operation that results in publishing the skill (e.g., transmitting skill metadata including a skill state value indicating that the skill has been installed). The skill metadata may be sent to Puffin (e.g., the Puffin regional 120) and used to update the corresponding skill state. 【0074】 The capability service 112 is configured to maintain capability data indicating 1) which capabilities of various services are currently available, 2) whether any resource / service is waiting in a particular capability, and 3) which particular resource and / or service is waiting in a given capability, or any appropriate combination of the above. The capability service 112 may provide an interface through which capability data can be requested. The capability service 112 may provide one or more interfaces (e.g., an application programming interface) that enable the transmission of capability data to the orchestrator 106, the CIOS regional 110 (e.g., each instance of the CIOS regional 110), the Puffin regional 120, and / or Puffin Central 118. In some embodiments, the capability service 112 may store capability data in a data store accessible to one or more components of CIOS 102, the orchestrator 106, CIOS regional 110 (e.g., each instance of CIOS regional 110), Puffin regional 120, and / or Puffin Central 118, and / or any suitable component or module of CIOS regional 110 may be configured to request capability data from the capability service 112 or to retrieve capability data (e.g., from a data store configured to store capability data generated by the capability service 112). Although the capability service 112 is depicted as a separate component of CIOS 102, in some embodiments, the functionality provided by the capability service 112 may be provided, in whole or in part, as part of a skills service through any suitable combination of Puffin Central 118 and Puffin regional 120. 【0075】 In some embodiments, each regional component, such as CIOS Regional 110, Capability Services 112, Puffin Regional 120, and / or Virtual Bootstrap Environment 116, may be one of many regional components. Each regional component may be specific to a given region (e.g., Host Region 103, as shown in Figure 1). Thus, another region may include similar, but distinct, components specific to that region. In some embodiments, a central component (e.g., Orchestrator 106, CIOS Central 108, RRDD 104, and Puffin Central 118) may include one or more components configured to manage build operations corresponding to one or more regions. As just one example, one orchestrator (Orchestrator 106) may be used to manage bootstrap operations for building any appropriate number of data centers, or a number of instances of Orchestrator 106 may be used, each driving bootstrap operations for these data centers or a subset of one data center. 【0076】 In some embodiments, the orchestrator 106 (which may be a multi-flock orchestrator, an orchestration service, etc.) may be configured to drive region building efforts. In some embodiments, the orchestrator 106 may manage information describing which flock configuration version and / or artifact version is used to bootstrap a given service within a region (or to make units of changes in a target region). In some embodiments, the orchestrator 106 may manage any suitable combination of flock configurations and / or service plans. In some embodiments, the orchestrator 106 may be configured to monitor (or be notified of) changes to region data managed by a real-time regional data distributor 104. In some embodiments, region building may be triggered by the orchestrator 106 upon receiving notification that region data has been changed. In some embodiments, the orchestrator 106 may collect various flock configurations, artifacts, and / or SPAM for use in region building. Some or all of the flock configurations and / or SPAM may be configured to be region-agnostic; that is, the flock configurations and / or SPAM may not explicitly identify which region is bootstrapped to which flock. In some embodiments, the orchestrator 106 may trigger a data injection process through which the collected flock configurations and / or SPAM are recompiled (e.g., by CIOS Central 108). During recompilation, operations may be performed (e.g., by CIOS Central 108) to inject region data maintained by the real-time regional data distributor 104 into the configuration files and / or SPAM.Flock configurations and / or SPAMs can reference regional data via variables / parameters without requiring hardcoded identification of the regional data. Flock configurations and / or SPAMs can dynamically modify regional data at runtime using this data injection rather than having the regional data hardcoded, and are therefore more difficult to change. 【0077】 In some embodiments, the orchestrator 106 may perform a static flock analysis in which the flock configuration and / or service plan are parsed to identify dependencies between resources, execution targets, execution target checkpoints, phases, and flocks, in particular to identify circular dependencies that need to be removed. In some embodiments, the static flock analysis (SFA) data corresponding to this analysis is stored for subsequent use (e.g., via DB312). In some embodiments, the orchestrator 106 may generate any number of appropriate data structures based on the identified dependencies. These data structures (e.g., directed acyclic graphs, linked lists, etc.) may be utilized by CIOS 102 to drive operations for performing region construction. For example, these data structures may collectively define the order in which services are bootstrapped within a region. An example of such a data structure is further discussed below with respect to the construction dependency graph 338 in Figure 3. If circular dependencies exist (e.g., service A requests service B, and vice versa) and are identified by static flock analysis and / or graphs, orchestrator 106 may be configured to notify any appropriate service team that changes are required to the corresponding flock settings in order to correct these circular dependencies. Orchestrator 106 may be configured to traverse one or more data structures to manage the order in which services are bootstrapped into a region. Orchestrator 106 can identify capabilities available within a given region at any given time (e.g., using data obtained from capability service 112). Orchestrator 106 may use this data to identify when a service can be bootstrapped, when a bootstrap is blocked, and / or when a previously blocked service and associated bootstrap operation can be resumed.Based on this traverse, the orchestrator 106 can execute various releases in which instructions are sent from the orchestrator 106 to the CIOS central 108 to perform bootstrap operations corresponding to any appropriate number of flock settings. In some examples, the orchestrator 106 may be configured to identify that one or more flock settings may require a large number of releases due to circular dependencies found in the graph. As a result, the orchestrator 106 may send a large set of instructions to the CIOS central 108 for a given flock setting to break the identified circular dependencies in the graph. 【0078】 In some embodiments, one or a service plan and manifest (SPAM) may be utilized by the orchestrator 106. The service plan and manifest may provide a more deterministic specification of the build description for the service than those previously provided by one or more flock settings. While a flock setting specifies one release configuration associated with one service, a service plan may provide a single specification of sequence and conditional requirements to execute all of the releases that may (or are) required to build a given service. Previous implementations of flock settings included selective dependencies that allowed for some degree of non-deterministic behavior with respect to the order in which operations were performed during region build. The inclusion of selective dependencies may require the orchestrator 106 to execute numerous paths in the build dependency graph, resulting in redundant processing. These types of dependencies make it difficult, if not impossible, for the system to track region build progress, identify any remaining operations that have not yet been performed, and / or identify build completion. Service plans and manifestos (SPAMs) may be used to eliminate at least some of the shortcomings of the previous non-deterministic approach. 【0079】 SPAM (where one SPAM corresponds to one service bootstrapped in a region) allows service teams to describe the corresponding operations that may (or may be) required to build a service, and may allow for the separation of internal coordination (e.g., coordination of operations within a service) and external coordination (e.g., coordination of operations between components of different services). Numerous visualizations may be provided through one or more user interfaces (e.g., through any appropriate component of Orchestrator 106 or CIOS 102). One visualization may draw a directed acyclic graph describing the internal build operations of a given service, and another visualization may draw a directed acyclic graph describing the sequence of build operations corresponding to a number of services (e.g., all services in a region / data center). As a specific example, one or more visualizations may provide a region-level directed acyclic graph (DAG) that includes only the external coordination (e.g., the sequence of operations corresponding to coordination between services) while omitting the internal operations for each service. This DAG could, for example, depict nodes corresponding to the capabilities (or skills) of a single service that other services depend on, while excluding nodes corresponding to capability (or skill) dependencies between service components / functional units of the same service. 【0080】 SPAM may include an external interaction interface that includes a service build definition containing a number of build milestones. Each build milestone may be associated with a set of capabilities (and / or skills) that the service is expected to publish when it reaches a given milestone. To transition between build milestones, SPAM may include execution units that encapsulate a directed acyclic graph (DAG) of one or more releases, each release being equivalent to an operation previously defined in a single flock setting. Each execution unit may define a set of build time dependencies that identify one or more capabilities (and / or skills) required by at least one of the releases of the execution unit. 【0081】 SPAM may include service build implementations. SPAM execution units may describe one or more releases that may (or may be) required to build a service, potentially defining a large number of execution units. Each execution unit is associated with one or more execution target checkpoint migrations, each of which may be used to specify the releases to be published as a result of executing the release and the expected capabilities that should be available before the time of the capabilities execution. 【0082】 In some embodiments, the orchestrator 106 may be configured to aggregate SPAMs corresponding to each service deployed in a region to generate a larger directed acyclic graph (e.g., build-dependent graph 338 in Figure 3) which may capture all operations necessary to build the region / data center. The collection of SPAMs identified from this aggregation may be called a “SPAM set”. In some embodiments, the orchestrator 106 may utilize a DAG generated from the SPAM set to authenticate the DAG and / or operations to be performed using a flock configuration, while the DAG generated from the flock configuration is used to drive the build operation / release execution. Alternatively, the orchestrator 106 may utilize a DAG generated from SPAMs to drive the build operation / release execution. The use of SPAMs / SPAM sets may be utilized by the system to generate a deterministic execution plan by which the region build may be performed. 【0083】 In some embodiments, Puffin Central 118 may provide a number of user interfaces through which one or more skills can be defined. Skills may be used in conjunction with or instead of previous capabilities, enabling improvements over previous capability-based implementations. In contrast to capabilities, skills may be scoped (e.g., controllable via access and authentication policies), versioned, and attributed to specific services and / or contacts. Skills may be associated with a lifecycle, monitored for health, and designed to be far more visible / accessible than capabilities. Puffin Central 118 may provide a trusted registry for skills; various user interfaces managed by Puffin Central 118 may be used to define, maintain, and manage skills offered by each service and their dependencies on other services. Puffin Central 118 may be used to declare and assert strongly defined metadata for services in a versioned format. This metadata may be used to generate blueprints for build time and runtime dependencies. These blueprints can be used to validate build plans in order to drive orchestration decisions during region build and to improve time-versus-engagement and time-versus-diagnostic measures during region build and / or Large-Scale Events (LSEs). 【0084】 Puffin Central 118 may be configured to act as a source of truth for services, maintaining metadata including upstream and downstream dependencies of each service, as well as service cheek contact information and methods for each service across regions and realms (e.g., sets of regions). Each skill may represent a functional unit that a service exposes to and provides to a consumer (e.g., another service). In some embodiments, skills may be scoped where access is controlled based on access and / or authentication policies and / or association with a particular namespace. A skill may be associated with a number of versions in which one or more aspects of the skill differ from previous versions, where each skill version represents a particular implementation form of the skill. Each skill version may be identifiable using a unique skill identifier. In some embodiments, Puffin Central 118 may be configured to generate skills corresponding to previously defined capabilities in order to provide backward compatibility with previous capability-based region-building implementation forms. 【0085】 In some embodiments, Puffin may support compatibility between skills and capabilities, so that any suitable combination of the two may be used to define the process by which a service is built. Based on maintaining a mapping between skills and / or capabilities that a service publishes, Puffin may ensure that skills may be migrated based on capabilities, and / or capabilities may be published by a state change of the corresponding skill. In some embodiments, Puffin may generate "shadow skills" (e.g., system-generated skills representing the corresponding capabilities) and / or shadow capabilities (e.g., system-generated capabilities that are published when the corresponding skill is migrated to an installed state). These features provided by Puffin enable the orchestrator to use any suitable combination of skills and / or capabilities to drive the orchestration during region construction (e.g., during the process of building a data center). 【0086】 In some embodiments, a skill may be mapped to one or more capabilities. Puffin Regional 120 may be configured to publish and / or store skill metadata based on capability data published (or stored) by capability service 112. In some embodiments, Puffin Regional 120 may publish capability data to capability service 112 and / or store such data, at least in part on publishing a skill or identifying that a skill has been moved to or associated with a particular state. In some embodiments, some services may utilize a flock configuration that uses capabilities to represent progress, while others may utilize service plans and manifests that define a deterministic building process in which progress is represented by capabilities and / or skills. Using mappings (or multiple mappings) between skills and capabilities, Puffin Regional 120 may enable region construction to be performed using any appropriate combination of capabilities and / or skills to indicate that 1) a service or resource function is available, 2) a specific event has occurred, 3) a specific fact is true, 4) a condition has been met, or any appropriate combination of the above. This mapping enables CIOS 102 to perform region construction / data center construction using any appropriate combination of capabilities and / or skills, and allows service teams to gradually transition from a capability-based implementation to a skill-based implementation. 【0087】 In some embodiments, any suitable computing component of the Puffin service (e.g., Puffin Central 118 and / or Puffin Regional 120) may be configured to monitor the health and / or lifecycle of a skill according to a certain skill lifecycle. Health monitoring may be performed using one or more alarms associated with a given skill. In some embodiments, a telemetry service (e.g., an alarm service 122) may utilize an application programming interface provided by the Puffin service (including Puffin Central 118 and / or Puffin Regional 120) when an alarm is triggered. As another example, the Puffin service (e.g., Puffin Regional 120) may request alarm data from the alarm service 122 and / or from a storage location where the alarm service 122 stores alarm data. The Puffin service may provide information related to the health of a skill, based on the alarms corresponding to the retrieved alarm data and their corresponding associations with a given skill, via one or more user interfaces. 【0088】 In some embodiments, a Puffin service (e.g., Puffin Central 118 and / or Puffin Regional 120) may expose one or more application programming interfaces (APIs) through which authentication operations may be performed. For example, a SPAM describing a build process for one or more services may be provided via a given API (e.g., by an orchestrator 106). The Puffin service (e.g., Puffin Central 118) may perform any appropriate operations to authenticate that all services and skills identified in the SPAM have been previously registered by the Puffin service, and that the build process defined in the SPAM does not break any previously defined dependencies maintained by the Puffin service. Additionally or alternatively, the orchestrator 106 may perform any appropriate authentication checks, such as determining whether each flock setting and / or artifact identified in a given service manifest is referenced in the corresponding service plan for the service and / or whether the flock setting and / or artifact is not referenced in a service plan that is not referenced in the manifest. The orchestrator 106 may perform authentication operations (e.g., static analysis including parsing the service plan) to determine that the service plan is free of circular dependencies. If circular dependencies are found in the service plan, the orchestrator 106 may provide a notification and / or restrict the use of the service plan and the corresponding manifest. In some embodiments, such restrictions may include restricting the service plan and manifest from being added to a set of SPAMs (e.g., a set of SPAMs used to build a region). In some embodiments, the orchestrator 106 may perform any appropriate authentication operations to ensure that SPAMs in a set of SPAMs and / or SPAMs considered to be additions to a pre-existing set of SPAMs are mutually compatible.This may include analyzing the SPAM set (either alone or with SPAMs considered for addition) to ensure that the SPAMs in the SPAM set do not have circular dependencies. 【0089】 In some embodiments, a user may request the creation of a new region (e.g., target region 114). This may require bootstrapping resources to support various services. In some embodiments, target region 114 may not be communicatively available (and / or secure) at the time the region creation request is initiated. Rather than delaying the bootstrap until such a time when target region 114 is available and configured to perform the bootstrap operation, CIOS 102 may initiate region creation using a virtual bootstrap environment (e.g., a virtual bootstrap environment (ViBE) 116). ViBE 116 may be an overlay network hosted by host region 103 (a pre-existing region pre-configured with a core set of services, and which is communicatively available and secure). The orchestrator 106 may leverage the resources of host region 103 to bootstrap resources to ViBE 116 (commonly referred to as "building the ViBE"). For example, the orchestrator 106 may leverage the resources of host region 103 (e.g., host An instruction can be provided through CIOS Central 108 to bootstrap another instance of the CIOS regional in ViBE 116 to an instance of CIOS regional 110 in region 103). Once the CIOS regional in ViBE becomes available for processing, the bootstrapping of services for target region 114 can continue within ViBE 116. When target region 114 becomes available to perform the bootstrap operation, previously bootstrapped services within ViBE 116 may be moved to target region 114. By utilizing these techniques, CIOS 102 can significantly increase the speed at which regions are built by dramatically reducing the need for any manual input and / or configuration to be provided.In some embodiments, any suitable combination of components shown as part of CIOS102 may individually be examples of cloud services in Figures 13-17 (e.g., 1356 in Figure 13) and may be configured to operate in any suitable infrastructure pattern, as described below in relation to Figures 13-17. 【0090】 Figure 2 is a block diagram illustrating an environment and method 200 for constructing a virtual bootstrap environment (ViBE) 202 (an example being ViBE 116 in Figure 1) according to at least one embodiment. ViBE 202 represents a virtual cloud network provisioned on an overlay of an existing region (e.g., host region 204, an example being host region 103 in Figure 1 and the embodiment, which is a host region service enclave). ViBE 202 represents an environment in which services can be staged for a target region (e.g., a region under construction, such as target region 114 in Figure 1) before the target region becomes available. 【0091】 A core set of services may be bootstrapped to bootstrap a new region (for example, target region 114 in Figure 1). These core sets of services may reside in host region 204 but not yet in ViBE (or in the target region). These essential core services provide the functionality required to provision devices, establish a chain of trust to the new region, and deploy the remaining services within the region. ViBE202 may be a tenancy deployed in host region 204 and used as a virtual region. 【0092】 Once the target region becomes available to provide bootstrap operations, ViBE202 can be connected to the target region, allowing services in ViBE to interact with services and / or infrastructure components in the target region. This enables the deployment of production-level services instead of self-contained seed services as in the previous system, and may be connected to the target region over the internet. Traditionally, seed services were deployed as part of container collection and used to bootstrap the dependencies necessary to build the region. Using existing regional infrastructure / tools, resources may be bootstrapped (e.g., provisioned and deployed) into ViBE202 and connected to a service enclave in the region (e.g., host region 204) to provision (reserve and / or configure) hardware and deployment services until the target region becomes self-sufficient, and can communicate directly. Leveraging ViBE202 makes it possible to provide services that need to provision / prepare infrastructure and deploy software while using resources in the host region to satisfy dependencies and break circular dependencies of core services. 【0093】 The orchestrator 206 (an example of orchestrator 106 in Figure 1) may be configured to perform operations to build (e.g., configure) ViBE 202. The orchestrator 206 can obtain applicable flock configurations and / or SPAM corresponding to various resources to be bootstrapped into a new region (in this case, the ViBE region, ViBE 202). For example, the orchestrator 206 may obtain a flock configuration (e.g., "ViBE flock configuration") that identifies the configuration to bootstrap a capability service 208 (e.g., an example of capability service 112) and / or worker 210. In some embodiments, the orchestrator 206 may additionally obtain a flock configuration that identifies the configuration to bootstrap any appropriate portion of a skill service (e.g., Puffin Regional 120 in Figure 1). In some embodiments, one or more service plans and manifests (SPAMs) may be used to identify these aspects (for example, specifying one or more flock configuration files and / or predefined operations in resources / artifacts that may be required (or are required) to bootstrap any suitable combination of capability services 208, workers 210, and / or Puffin regionals 209) to bootstrap the service from start to finish. As another example, orchestrator 206 may obtain a different flock configuration and / or SPAM corresponding to bootstrap Domain Name Service (DNS) 212 to ViBE 202. 【0094】 Method 200 begins in step 1, where the orchestrator 206 may instruct the CIOS central 214 (for example, examples of CIOS centrals 108 and 214 in Figures 1 and 2, respectively). For example, the orchestrator 206 may send a request (which may be a single flock setting identified in the service plan, including a ViBE flock setting) to request the bootstrapping of capability services 208 and workers 210 (and in some embodiments, puffin regional 209) that do not yet exist in ViBE 202 at this point. In some embodiments, corresponding SPAM for capability services 208, workers 210, and / or puffin regional 209 may be used instead of or in addition to the ViBE flock setting. In some embodiments, the CIOS central 214 may have access to all flock settings and / or SPAM. Therefore, in some examples, the orchestrator 206 may transmit an identifier for the ViBE flock setting, and the CIOS central 214 may independently retrieve the ViBE flock setting from storage (e.g., database (DB) 308 or DB312 in Figure 3). 【0095】 In step 2, CIOS Central 214 may provide ViBE flock configuration in response to a corresponding request to CIOS Regional 216. CIOS Regional 216 may parse the ViBE flock configuration in step 3 to identify and perform specific infrastructure provisioning and deployment operations. 【0096】 In some embodiments, CIOS Regional 216 may provide additional corresponding services for provisioning and deployment. For example, in step 4, CIOS Regional 216 may instruct a deployment orchestrator 218 (e.g., a core service in host region 204, or other example of write, build, and deploy application software) to execute the instruction, which then causes capability service 208, worker 210, and, in some embodiments, Puffin Regional 209 to bootstrap within ViBE 202. 【0097】 In step 5, capability data may be sent to capability service 208 (via CIOS regional 216, deployment orchestrator 218 to worker 210 or otherwise) indicating that a resource corresponding to the ViBE flock is available. Capability service 208 may persist this data. In some embodiments, capability service 208 adds this information to its maintained list of capabilities available with ViBE. For example, the capabilities provided to capability service 208 in step 5 may indicate that capability service 208 and worker 210 (and in some embodiments, Puffin regional 209) are available for processing. In some embodiments, skill metadata may be sent to Puffin regional 209 indicating that any appropriate combination of capabilities corresponding to capability service 208, worker 210, and / or Puffin regional 209 is available. 【0098】 In step 6, the orchestrator 206 may identify that the capability service 208, the worker 210, and / or the puffin regional 209 are available based on receiving or obtaining data (identifiers corresponding to capabilities and / or skills) from the capability service 208 and / or the puffin regional 209. 【0099】 In some embodiments, published capabilities may be processed by a Puffin Regional 209 (e.g., Puffin Regional 120 in Figure 1) before being processed by the Orchestrator 206. In some embodiments, Puffin Regional 209 may be configured to provide forward and backward compatibility between skills and capabilities. For example, in some embodiments, once a capability is published to Puffin Regional 209, Puffin Regional 209 may query known skills to check whether any skills are associated with the capability (e.g., via a skill table or other appropriate record of registered / previously generated skills). If a skill is not associated with a capability, Puffin Regional 209 may be configured to generate a skill (referred to as a “shadow skill”) to represent the capability using a skill construct (e.g., including a data structure described below in relation to Figure 4). When the orchestrator 206 publishes a skill (or updates the skill status) during the region building process, the Puffin Regional 209 may receive this data and identify one or more capabilities associated with the corresponding skill. The Puffin Regional 209 may publish any or all capabilities associated with a skill that has not yet been published. In some embodiments, publishing such data may include remembering an indication that these capabilities are available. In this form, the Puffin Regional 209 may support a complete capability between capabilities and skills, so that any suitable combination of the two may be used to drive operations performed during region building. 【0100】 While some embodiments describe shadow skill generation occurring during build time, it should be acknowledged that the Puffin service may generate shadow skills in various ways at any appropriate time. For example, historical capability data (e.g., capability data previously published during one or more previous region builds) may be retrieved by the Puffin service (e.g., Puffin Central 118 and / or Puffin Regional 120 in Figure 1, and / or Puffin Regional 209 in Figure 2) at any appropriate time (e.g., before the start of a region build, before deployment within a region, or upon completion of a region build). In some embodiments, historical capability data may be stored in a data store accessible to the Puffin service (e.g., an instance of capability service 112 in Figure 1). The Puffin service may process historical capability data (e.g., one or more files, records, tables, data structures, etc.) to identify one or more capabilities for which the corresponding skill does not currently exist. Identifying a corresponding skill may involve matching any appropriate part of a capability's tag or label with any appropriate attribute and / or part of an attribute associated with the service (e.g., one or more tokens / words of the service name and / or identifier). Shadow skills may be generated by the Puffin service for each previously published capability that does not match any known skill. As described above, these shadow skills may be configured to represent the corresponding previously published capability and may be used to maintain compatibility between skills and capabilities, and between skill-based service build definitions (e.g., SPAM) and capability-based service build definitions (e.g., Flock, SPAM, etc.). 【0101】 In step 7, as a result of receiving / acquiring data in step 6, the orchestrator 206 may instruct the CIOS central 214 to bootstrap a DNS service (e.g., DNS212) to ViBE202. The instruction may identify or include specific flock settings and / or SPAM corresponding to the DNS service. 【0102】 In step 8, the CIOS Central 214 may instruct the CIOS Regional 216 to deploy DNS212 to ViBE202. In some embodiments, DNS flock settings and / or SPAM for DNS212 may be provided by the CIOS Central 214. 【0103】 In step 9, worker 210, now deployed in ViBE202, may be assigned by CIOS regional 216 to the task of deploying DNS212. The worker may run a declarative infrastructure provisioner in the form described above in relation to Figure 3 to identify the set of operations required to deploy DNS212. These operations may be identified at least in part on comparing the flock configuration (desired state) or the corresponding portion of the SPAM with the current state of the (currently non-existent) resource associated with DNS212. 【0104】 In step 10, the deployment orchestrator 218 may instruct worker 210 to deploy DNS212 according to the operation identified in step 9. As shown, worker 210 proceeds to perform the operation to deploy DNS212 to ViBE202 in step 11. In step 12, worker 210 may notify capability service 208 (via capability) or Puffin Regional 209 (directly or via capability service 208 using skills) that DNS212 is available in ViBE202. Orchestrator 206 may then identify that the ViBE flock configuration and the resources associated with the DNS flock configuration are available and may proceed to bootstrap any appropriate number of additional resources to ViBE. 【0105】 After steps 1-12 are completed, the process for building ViBE202 may be considered complete, and ViBE202 may be considered built and ready for additional bootstrapping (e.g., bootstrapping various cloud services such as cloud service 1356 in Figure 13). At any appropriate time between steps 1-12, Puffin Regional 209 may receive and / or retrieve alarm data from one or more alarm services (e.g., alarm service 122 in Figure 1). In some embodiments, the alarm data may be processed by Puffin Regional 209 (or Puffin Regional 209 may communicate the alarm data or data extracted from the alarm data to Puffin Central 118 in Figure 1). In some embodiments, Puffin Regional 209 (and / or Puffin Central 118) may communicate skill health information indicating the corresponding health status associated with one or more skills to Orchestrator 206. In some embodiments, the Puffin Regional 209, Puffin Central 118, and / or the Orchestrator 206 may be configured to perform an operation that may pause (partially or completely) any appropriate part of the operation considered above in relation to Method 200. In some embodiments, this may cause the region state associated with the region on which Method 200 is performed to be updated to a state indicating that the construction of the region is paused. In some embodiments, the Puffin Regional 209, Puffin Central 118, and / or the Orchestrator 206 may be configured to resume the operation of Method 200 (and correspondingly update the region state) based at least partially on user input, subsequent alarm data indicating an update to the health state of one or more skills, skill health override values, etc. 【0106】 Figure 3 is a block diagram illustrating an environment and method 300 for bootstrapping a service to a target region using ViBE, according to at least one embodiment. 【0107】 Method 300 may begin in step 1, where user 302 (e.g., a service team member) may interact with any number of appropriate user interfaces managed by Puffin Central 340 (e.g., Puffin Central 118 in Figure 1). Puffin Central 340 may be configured to read service and / or skill metadata from certain files, or user 302 may input service and / or skill metadata in one or more of the provided user interfaces. In some embodiments, Puffin Central 340 may store all service and skill metadata and act as a centralized authority for that purpose. At any appropriate time, any appropriate user may view the service and / or skill metadata before and / or during the execution of a region build, etc. 【0108】 In step 2, user 303 may utilize any suitable user interface provided by CIOS Central 304 (examples of CIOS Central 108 and CIOS Central 214 in Figures 1 and 2, respectively) to modify the region data. For example, user 303 may create a new region where numerous services are bootstrapped. 【0109】 In step 3, the CIOS central 304 may perform an operation to send the changes to the RRDD 306 (for example, an example of RRDD 104 in Figure 1). In step 4, the RRDD 306 may store the received region data in a data store configured to store the region data, including any appropriate identifiers, attributes, and statuses such as database 308, region, AD, realm, ET, etc. In some embodiments, the updater 307 may be used to store the region data in database 308 or any appropriate data store from which such updates may be accessible (for example, to a service team). In some embodiments, the updater 307 may be configured to notify of updates made to database 308 (for example, via any appropriate electronic notification). 【0110】 In step 5, the orchestrator 310 (examples of orchestrators 106 and / or 206 in Figures 1 and 2, respectively) may detect changes in the region data. In some embodiments, the orchestrator 310 may be configured to poll the RRDD 306 for changes in the region data. In some embodiments, the RRDD 306 may be configured to publish or otherwise notify the orchestrator 310 of the changes in the region data. 【0111】 In step 6, detecting a change in region data may trigger orchestrator 310 to retrieve a version set (e.g., a version set associated with a specific identifier, such as a “golden version set” identifier) ​​that identifies a specific version for each flock configuration and a specific version for each artifact used to build the region. The version set may be retrieved from DB312. As flock configurations and / or artifacts evolve and change over time, numerous versions of each may be maintained, and a certain version of each may be used for region construction. The version set may be persisted in DB312, so that orchestrator 310 can identify which versions of flock configurations and artifacts to use to build regions (e.g., ViBE regions, target regions / non-ViBE regions, etc.). Flock configurations (e.g., all versions of a flock configuration) and / or artifacts (e.g., all versions of an artifact) may be stored in DB308, DB312, or any suitable data store accessible to CIOS Central 304 and / or orchestrator 310. 【0112】 In some embodiments, the orchestrator 310 may identify any appropriate number of SPAMs (collectively referred to as “SPAM sets”) corresponding to the infrastructure being provisioned and the artifacts to be deployed as part of the region construction. In some embodiments, each SPAM may identify versions corresponding to one or more flock configurations and / or one or more artifacts that may be required (or are required) to build a service. In embodiments where one or more SPAMs are used, the SPAM (or any appropriate part of the SPAM) may be stored in DB312 and used to identify specific flock configurations and / or artifact versions used to build a region. In some embodiments, the flock configurations and / or artifact versions of a SPAM set may be included in a version set and stored in DB312. This allows some service teams to utilize the flock configuration settings to define the build implementation of their service, while other service teams may choose to utilize SPAMs to define the build implementation of their service. 【0113】 In some embodiments, any appropriate flock version set and / or version set item may be drawn from any appropriate number of SPAMs, and the orchestrator 310 may be configured to verify that the compliance of the flock's behavior (e.g., build / orchestration operations identified within the flock configuration) conforms to the processes defined by the corresponding SPAMs. The orchestrator 310 may be configured to take in SPAMs that provide information that may be required (or in some cases required) to build an up-front plan for the work and introduce better guardrails than those available in previous implementation forms. Any appropriate number of SPAMs may be aggregated into corresponding SPAMs, just as flocks may be aggregated into version sets. A set of SPAMs may perform invariants such that all SPAMs in the set are mutually compatible to form an executable graph and together constitute an executable graph of releases required to build a region. In some embodiments, a set of SPAMs may be used within a given regional context to improve service build progress tracking. SPAM operations may be enabled before they are applied and may be rejected if they are disabled, unlike version set item operations which are applied unconditionally. The use of SPAM may enable orchestrator 310 to build a deterministic plan of work before building a region, block updates that jeopardize or break ongoing and future builds, improve tracking of the service build process, detect deviations of flock behavior from the SPAM specification, and alert operators of deviations and status. 【0114】 In step 7, the orchestrator 310 may request the CIOS central 304 to recompile each flock setting associated with the version set (including any appropriate number of flock settings identified by SPAM in the SPAM set) with the current region data. In some embodiments, the request may specify the version for each flock setting and / or artifact. 【0115】 In step 8, CIOS Central 304 may retrieve the current regional data from DB 308 (for example, directly or via the real-time regional data distributor 306) and look up any appropriate flock settings and artifacts according to the version requested by the orchestrator 310. 【0116】 In step 9, the CIOS central 304 may recompile the acquired flock settings with the region data acquired in step 8 in order to inject the current region data into these flock settings. The CIOS central 304 may return the compiled flock settings to the orchestrator 310. In some embodiments, the CIOS central 304 may simply indicate that compilation has been performed, and the orchestrator 310 may access the recompiled flock settings via the RRDD 306. 【0117】 In some embodiments, in step 10, the orchestrator 310 may perform a static flock analysis of the recompiled flock configuration (and / or SPAM). As part of the static flock analysis, the orchestrator 310 may parse the flock configuration (and / or SPAM) to identify dependencies (e.g., using a library associated with a declarative infrastructure provisioner (e.g., Terraform®)). The data generated by the static flock analysis (e.g., “SFA data” including identified dependencies) may be stored for subsequent use. From the analysis and identified dependencies (e.g., SFA data), the orchestrator 310 may generate any appropriate number of data structures (e.g., directed acyclic graphs) that identify the sequence for releases identified in the flock configuration (or from any appropriate part of one or more service plans, such as from the flock configuration entities of a service plan). A DAG generated based on a flock configuration (and / or any part of the SPAM, including but not limited to the flock configuration entity 800 in Figure 8), which specifies the releases and the order of releases required to build a service, may be called a “service DAG.” In some embodiments, the orchestrator 310 may generate a directed acyclic graph (called a “build diagram”) corresponding to each SPAM, where each node represents a build milestone with an edge indicating an execution unit, and a capability (and / or skill) that moves the service between the build milestones. Each execution unit may represent a number of releases that, when executed, move the service between the build milestones. Any appropriate number of service DAGs can be combined to form a build dependency graph 338. The build dependency graph 338 may be a directed acyclic graph that identifies the order in which releases are executed to bootstrap one or more services within a new region. 【0118】 In some embodiments, the build dependency graph 338 may be a region-level dependency graph containing all releases that may (or may be required) for all services to be bootstrapped within a region / data center. Each node in the build dependency graph 338 may correspond to bootstrapping any appropriate part of a service. For example, each node in the build dependency graph 338 may correspond to a single release. A particular bootstrapping order (e.g., the order of release execution) may be identified based at least in part on dependencies. In some embodiments, dependencies may be represented as attributes of nodes and / or shown via graph edges connecting nodes. The orchestrator 310 may traverse the build dependency graph 338 (e.g., starting at the start node) to drive the region build operation. Any appropriate part of the service DAG and / or the build dependency graph 338 may be represented via one or more user interfaces (e.g., one or more interfaces provided by any appropriate component of CIOS 102 in Figure 1, including the orchestrator 310, CIOS Central 304, etc.). 【0119】 In some embodiments, the orchestrator 310 may utilize a cycle detection algorithm to detect the presence of cycles (e.g., service A depends on service B, and vice versa). The orchestrator 310 can identify orphaned capability dependencies. For example, the orchestrator 310 can identify orphaned nodes in the build dependency graph 338 that are not connected to any other nodes. The orchestrator 310 may identify misissued capabilities (e.g., when a capability is issued too early and the corresponding functionality is not yet actually available). The orchestrator 310 can detect from the graph that there are one or more instances issuing the same capability. In some embodiments, any appropriate number of these errors may be detected, and the orchestrator 310 (or another appropriate component such as CIOS Central 304) may be configured to notify or otherwise present this information to the user (e.g., via electronic notification, user interface, etc.). In some embodiments, the orchestrator 310 may be configured to force the deletion / reproduction of resources to break circular dependencies and may again instruct the CIOS central 304 to perform bootstrap operations for these resources and / or corresponding flock settings. 【0120】 The starting node of the build dependency graph 338 may correspond to building ViBE316 (or individual services within ViBE), and the second node may correspond to bootstrapping DNS. Steps 11-16 may correspond to deploying resources and / or artifacts identified in the corresponding VIBE flock configuration or SPAM to ViBE316 (e.g., examples of ViBE116 and 202 in Figures 1 and 2, respectively) via the deployment orchestrator 317 (an example of the deployment orchestrator 218 in Figure 2). In other words, steps 11-16 in Figure 3 generally correspond to steps 1-6 in Figure 2. When notified that a capability (or skill) exists (for example, that capability service 318, worker 320, and / or Puffin Regional 342, corresponding to capability service 208, worker 210, and Puffin Regional 209 in Figure 2, are deployed / available), orchestrator 310 may resume traversing the build dependency graph 338 to identify which operation / release will be performed next. 【0121】 The orchestrator 310 may continue traversing the build dependency graph 338 to identify that one or more releases corresponding to deploying DNS322 are being executed. Steps 17-22 may be performed to deploy DNS322 (an example of DNS212 in Figure 2). These operations may generally correspond to steps 7-12 in Figure 2. 【0122】 In step 22, a capability (or skill) indicating that DNS322 is available may be published and / or stored. In some embodiments, the CIOS regional 314 and / or the deployment orchestrator 317 may first communicate the availability of the capability or skill (e.g., to capability service 318 or Puffin regional 342, respectively). Once the skill is published, Puffin regional 342 may send data to capability service 318 to indicate that one or more corresponding capabilities have been published. Upon detecting the publishing of the capability (e.g., via data provided by capability service 318, which may be triggered based on skill-related data provided by Puffin regional 342), the orchestrator 310 may resume traversing the build dependency graph 338. During this traverse, the orchestrator 310 may notify that any appropriate portion of an instance of a CIOS regional (for example, one instance of CIOS regional 314) is to be deployed to ViBE 316. In some embodiments, steps 17-22 may be substantially repeated with respect to deploying a CIOS regional (ViBE) 326 (an instance of CIOS regional 314, CIOS regional 110 in Figure 1) and worker 328 to ViBE 316. Capabilities may be sent to the capability service 318 where CIOS regional (ViBE) 326 is available. If a skill is used to indicate that CIOS regional (ViBE) 326 is available, the Puffin regional 342 may send data to the capability service 318 indicating that one or more corresponding capabilities are available. The interaction between Puffin Regional 342 and Capability Service 318 allows any appropriate combination of capabilities and / or skills to be utilized to represent progress through region building.In some embodiments, when the build dependency graph 338 identifies a transition through capability publishing and dependencies, the progress demonstrated in skill publishing may be used to trigger the corresponding capability publishing, enabling the skill to trigger progress in region building. 【0123】 When the orchestrator 310 detects that the CIOS regional (ViBE) 326 is available, it may resume traversing the build dependency graph 338. During this traverse, the orchestrator 310 may identify that a deployment orchestrator (e.g., deployment orchestrator 330, one example of deployment orchestrator 317) is being deployed to ViBE 316. In some embodiments, steps 16-21 may be substantially repeated with respect to deploying deployment orchestrator 330. Capability-identifying information may also be sent to the capability service 318 (e.g., by the CIOS regional 314, worker 320, and / or Puffin regional 342) indicating that deployment orchestrator 330 is available. 【0124】 Once the deployment orchestrator 330 is deployed, ViBE 316 may be considered available to process subsequent requests. Upon detecting that the deployment orchestrator 330 is available, orchestrator 310 may instruct subsequent bootstrap requests to be routed to the ViBE component rather than utilizing the host region component (the component in host region 322). Thus, orchestrator 310 can continue traversing the build dependency graph 338 at each node and instruct ViBE 316 to execute a release via CIOS Central 304. CIOS Central 304 may send a release request CIOS Regional (ViBE) 326 to cause a release execution as instructed by orchestrator 310. 【0125】 At any appropriate point in this process, target region 334 may become available. An indication that the target region is available may be identifiable from the region data for target region 334 provided by user 303 (as an update to the region data). The availability of target region 334 may depend on establishing a network connection between target region 334 and an external network (e.g., the Internet). The network connection may be supported over a public network (e.g., the Internet), or a software security tool (e.g., IPSec) may be used to provide one or more encrypted tunnels (e.g., IPSec tunnels such as tunnel 336) from ViBE316 to target region 334. As used herein, "IPSec" means a set of protocols for authenticating and encrypting network traffic over a network using Internet Protocol (IP), and may include one or more available implementations of the set of protocols (e.g., Openswan, Libreswan, strongSwan, etc.). The network may connect ViBE316 to a service enclave in target region 334. 【0126】 Before establishing an IPSec tunnel, initial network connectivity to target region 334 may be over sufficient connectivity (e.g., an out-of-band VPN tunnel) to allow the bootstrapping of networking services until IPSec can be deployed on assets (e.g., bare metal assets) in target region 334. To bootstrapping network resources in the target region, deployment orchestrator 330 may deploy an IPSec gateway on an asset within target region 334. Deployment orchestrator 330 may then deploy a VPN host in target region 334 configured to terminate the IPSec tunnel from ViBE316. Services in ViBE316 (e.g., deployment orchestrator 330, service A, etc.) can establish IPSec connectivity with the VPN host in target region 334, and the bootstrap operation from ViBE316 to target region 334 may commence. 【0127】 In some embodiments, the bootstrap operation may be initiated by a service in ViBE316 provisioning resources in target region 334 to support hosting instances of the core service when deployed from ViBE316. For example, a host provisioning service may provision a hypervisor on infrastructure (e.g., bare metal hosts) in target region 334 to allocate computing resources for VMs. Once the host provisioning service has completed allocating the physical resources in target region 334, it may issue information indicating a capability that the physical resources in target region 334 have been allocated. The capability may be issued to a capability service 318 via a CIOS regional (ViBE) 326 (e.g., by a worker 328). 【0128】 Once the hardware allocation for target region 334 is established and posted to capability service 318, CIOS regional (ViBE) 326 can orchestrate the deployment of core service instances from ViBE 316 to target region 334. This deployment may be similar to the process described above for building ViBE 316, but using ViBE components (e.g., CIOS regional (ViBE) 326, worker 328, deployment orchestrator 330) instead of components from the host region 332 service enclave (e.g., CIOS regional 314 and deployment orchestrator 317). The deployment operation may generally correspond to steps 17-22 described above. 【0129】 When a service is deployed from ViBE316 to target region 334, the DNS record associated with the service may correspond to the instance of the service in ViBE316. The DNS record associated with the service may be updated at any appropriate time to complete the deployment of the service to target region 334. In other words, the instance of the service in ViBE316 may continue to receive traffic (e.g., requests) until the DNS record is updated. The service may be partially deployed within target region 334, and information indicating the capability for the service to be partially deployed may be published (e.g., to capability service 318). For example, a service running in ViBE316 may be deployed within target region 334 with the corresponding compute instance, load balancer, and associated application and other software, but may need to wait for the database data to move to target region 334 before being fully deployed. The DNS record (e.g., managed by DNS322) may still be associated with the service in ViBE316. Once the data migration for the service is complete, the DNS record may be updated to point to the operational service deployed in target region 334. A service deployed in target region 334 may then receive traffic for the service (e.g., requests), whereas an instance of the service in ViBE316 may no longer receive traffic for the service. 【0130】 At any appropriate time during Method 300, Puffin Regional 209 may receive and / or acquire alarm data from one or more alarm services (e.g., alarm service 344, which is an example of alarm service 122 in Figure 1). In some embodiments, the alarm data may be processed by Puffin Regional 342 (or Puffin Regional 342 may communicate the alarm data or data extracted from the alarm data to Puffin Central 340). In some embodiments, Puffin Regional 342 and / or Puffin Central 340 may communicate skill health information to Orchestrator 310, indicating the corresponding health status associated with one or more skills. In some embodiments, Puffin Regional 342, Puffin Central 340, and / or Orchestrator 310 may be configured to perform operations that pause or otherwise stop any appropriate part of the operations considered above in relation to Method 300. In some embodiments, Puffin Regional 342, Puffin Central 340, and / or Orchestrator 310 may be configured to resume and / or execute any appropriate part of the operation of Method 300 (for example, based at least in part on user input, subsequent alarm data indicating an update to the health status associated with one or more skills, and at least in part on skill health override values, etc.). 【0131】 Figure 4 is a block diagram showing a data model 400 representing skill-related metadata according to at least one embodiment. Each of the data structures shown in Figure 4 may include an ID (e.g., an identifier) ​​that individually identifies the data structure. This ID may be used to point to a particular instance of a particular data structure. 【0132】 In some embodiments, service metadata 402 may include any appropriate data corresponding to the service. Service metadata 402 may include any appropriate attributes and corresponding values ​​of the service, while skill metadata 404 may similarly include any appropriate attributes and corresponding values ​​of the skill. The association between service metadata 402 and skill metadata 404 may indicate a relationship between a service and a skill (for example, a service is expected to publish a skill during build or runtime). As shown in Figure 4, service metadata 402 may be stored in a number of data structures (e.g., namespace data structure 408 and service data structure 406), but any appropriate number or type of data structures may be utilized. Service metadata may include, but is not limited to, an ID, a service name (corresponding to the name of the service), a compartment ID (corresponding to an identifier for the compartment in which the service is deployed), a product part ID, a namespace ID (an identifier for the namespace associated with the service), a namespace name (a name associated with the namespace associated with the service), and / or a compartment ID corresponding to the namespace. In some embodiments, the service metadata 402 may be curated (e.g., read from memory, uploaded to Puffin Central 118 in Figure 1). In some embodiments, the service metadata 402 may be retrieved by Puffin Central 118 from another system or, generally speaking, through a process that does not involve user input of the information via any user interface provided by Puffin Central. 【0133】 Skill metadata 404 may include any appropriate number of data structures (e.g., data structures 410-420). In some embodiments, skill data structure 410 may include attributes and values ​​corresponding to any appropriate combination of skill ID, skill name, skill fleet, major version, deprecation indicator, one or more capabilities (e.g., a set of capability identifiers), substitute indicator, compartment ID, producer ID, namespace ID, and recovery ring level. In some embodiments, the values ​​stored in skill data structure 410 for compartment ID, producer ID, and / or namespace ID may match the compartment ID, service name, or namespace name in service metadata 402, respectively. Matches between one or more of these attribute values ​​may be used as an association between skill metadata 404 and service metadata 402 (indicating that the corresponding service is expected to publish skills at some point in time). 【0134】 Skill version data structure 412 may be associated with skill data structure 410 at least in part on matching values ​​of the skill ID in skill version data structure 412 and the ID in skill data structure 410. Skill version data structure 412 may include attributes and values ​​corresponding to any appropriate combination of the following: ID (for skill version), skill ID (e.g., a unique identifier for the skill), major and / or minor versions that individually or collectively identify a particular implementation form of the skill, patch version (a version identifier that identifies a skill used to correct a previously erroneous skill version), deprecation indicator (indicating whether the skill is deprecated), health check attribute (referencing one or more instances of alarm data for one or more instances of health check data structure 414), installation status (indicating an installation status such as declared, selected, install, installed, prohibited, retired, uninstalled, etc.), health status (indicating the health of the skill such as unknown, healthy, unhealthy, etc.), and observability attribute. The observability attribute may be used to store any appropriate data that identifies the operation or data point required to collect telemetry, alarms, and / or log data for the skill version. The skill version data structure 412 may be associated with a health check data structure 414, which may be configured to maintain any appropriate number of alarm labels associated with the skill. For example, the healthCheck attribute of the skill version data structure 412 may refer to any appropriate number of health check data structures corresponding to one or more instances of the health check data structure 414. 【0135】 In some embodiments, the health check data structure 414 may include any suitable combination of an alarm identifier (an alarm ID indicating a unique identifier for the alarm), an alarm label name (the name of the alarm), a compartment identifier (a compartment ID indicating the compartment to which the alarm is scoped), a continuation token (a token by which the alarm transition history may be obtained), a namespace identifier (a namespace ID indicating a specific namespace to which the alarm is scoped), and a status value (indicating the health status corresponding to the alarm). Alarm data corresponding to a large number of alarms may be maintained in the health check data structure 414. For example, the alarm ID may include a list of a large number of alarm IDs corresponding to a list of alarm label names stored in the alarm label name attribute. The compartment ID attribute may be a list of compartment IDs corresponding to the alarms and labels in the alarm ID and alarm label name ID attributes of the health check data structure 414. In some embodiments, a large number of sets of attributes for alarmID, alarmLabelName, compartmentID, continuationToken, and status may be stored, each set of attributes corresponding to one alarm. 【0136】 In some embodiments, the health check data structure 414 may store data corresponding to one or more alarm services (e.g., alarm service 344 in Figure 3, alarm service 122 in Figure 1). For example, the namespace identifier of the health check data structure may store the namespace corresponding to a skill (e.g., corresponding to an instance of the skill data structure 410). In some embodiments, the association between a skill and an alarm may be maintained at least in part on storing the same namespace identifier in the namespace ID attribute of the instance of the health check data structure 414 and in the namespace ID attribute of the instance of the skill data structure 410. In some embodiments, the status attribute may store a value indicating the health of the skill and the status of alarms (e.g., an alarm identified by alarmID, an alarm identified by namespaceID, etc.). In embodiments where statuses from multiple alarm services are utilized, multiple status attributes may be used to maintain the status of each corresponding alarm (e.g., one status for alarmID, another status for namespaceID, etc.). 【0137】 Skill data structure 410 may be associated with skill metadata data structure 416. Skill metadata data structure 416 may include attributes and values ​​for any appropriate combination of ID (for an instance of skill metadata data structure 416), Jira queue, owner contact, organization leader, and phonebook ID. The phonebook ID may be an identifier corresponding to a separate system configured to store contact data. Skill metadata structure 416 may be used to store any appropriate contact data (such as name, email, address, and phone number) for entities associated with the skill (e.g., service team members) and services to which the skill is associated. 【0138】 The skill data structure 410 may be associated with the skill consumer data structure 418. The skill consumer data structure 418 may include attributes and values ​​for any appropriate combination of ID (for the skill consumer), type, status, consuming region, version request, consuming skill ID, and consuming service ID. The skill consumer data structure 418 may be configured to store any appropriate information about the services and / or skills that depend on the skill defined by the skill metadata 404. 【0139】 The skill data structure 410 may be associated with the skill group data structure 420. The skill group data structure may include attributes and values ​​for any suitable combination of an ID (for the skill group), a skill group name, and one or more skill IDs associated with the skill group. 【0140】 Each of the data structures 406-420 may be stored in one or more data stores, and the data structures may be identified and retrieved (e.g., via lookup and / or query operations) at least partially based on values ​​stored in other data structures by the associations considered above. For example, all skills associated with a service may be identified by querying the data store for all skill data structures associated with a producer ID that matches the ID from the service data structure 406 in the service metadata 402. 【0141】 While the number and specific combinations of data structures are shown in Figure 4, any appropriate number or type of attributes and / or values ​​and / or data structures may be used. In some embodiments, the data of any data structure shown in Figure 4 may be separated or combined into a number of data structures and stored in fewer data structures than those shown in Figure 4. The relationships shown between these data structures may be the same as those shown in Figure 4, or the relationships may be different. As a non-limiting example, the data shown with data structures 410-420 may similarly be stored in more or fewer data structures. For example, the data shown within data structures 410-420 may, in some embodiments, be provided in a single data structure. 【0142】 Each data structure in Figure 4 may be associated with other data structures in Figure 4, at least in part, by referencing identifiers of one or more other data structures. For example, an instance of the skill version data structure 412 may be associated with a particular instance of the skill data structure 410, at least in part, by having a value for the skillID attribute of the skill version data structure 412 that matches the value of the ID attribute of a particular instance of the skill data structure 410. As another example, the skill consumer data structure 418 may be associated with a skill by referencing the ID of the skill data structure 410 in the consumeSkillID attribute. As yet another example, an instance of the skill group data structure 420 may be associated with one or more instances of the skill data structure 410 by referencing the IDs of those skills in the skill attribute. As yet another example, the skill version data structure 412 may reference one or more instances of the health check data structure 41, at least in part, by referencing the IDs of those health check data structures in the healthCheck attribute. An instance of skill data structure 410 may be associated with a particular service at least in part on the basis of referencing the ID of the service data structure 406 corresponding to the service via the producerServiceID attribute. 【0143】 Any appropriate number of instances of skill metadata 404 (corresponding to individual skills) may be associated with one instance of service metadata 402 and may be used to represent the process of deploying a service whose deployment task sequence is represented through the instances of skill metadata 404. Each skill corresponding to an instance of skill metadata 404 for a service may be tracked, updated, or otherwise analyzed to provide information about the deployment process for the service, to drive the deployment of the service, to authenticate the build plan or build dependency graph 338 in Figure 3, etc. 【0144】 Figure 5 is a block diagram showing a data model 500 representing various metadata associated with SPAM (e.g., service plans and manifests) according to at least one embodiment. Each data structure 502-508 may have any appropriate number of attributes (shown) having corresponding values. These data structures may be identified in a common file or any appropriate number of files. SPAM may be maintained in the data structures shown in Figure 5 or in different data structures. The data structures in Figure 5 may be combined or separated in any appropriate form to support the metadata corresponding to SPAM. 【0145】 SPAM may be represented by a combination of the data structures shown in Figure 5 (e.g., data structures 502-508). Each of these data structures may include an ID (e.g., an identifier) ​​with a corresponding value that uniquely identifies the data structure. This ID may be used to point to a specific instance of a particular data structure. Each of the data structures 502-508 may include an attribute corresponding to "spamName" which may be used to maintain relationships between the data structures 502-508 (e.g., to indicate that each of the data structures 502-508 corresponds to the same SPAM). Any suitable number of SPAMs may be combined and collectively referred to as a SPAM set, an example of which includes SPAM set 510. 【0146】 In some embodiments, the SPAM data structure 502 may include any appropriate data corresponding to the SPAM. Any appropriate part of the SPAM data structure 502 may be included in the service plan data structure 504 and / or service manifest 506. As shown in Figure 5, the SPAM data structure 502 includes a phonebookID attribute. The corresponding value for this attribute may identify the service and / or contact identified as the owner of the SPAM. In some embodiments, the value corresponding to the attribute "phonebookID" may be an identifier corresponding to a separate system or database configured to maintain contact information for a service team. The value of phonebookID may be used as a lookup value to retrieve the corresponding contact information (e.g., email, service team name, phone number, etc.) for the service that owns the SPAM corresponding to the SPAM data structure 502. The SPAM data structure 502 may include corresponding IDs that identify specific instances of the service plan data structure (e.g., service plan data structure 504) and service manifest (e.g., service manifest 506) via the attributes "servicePlanID" and "serviceManifestID," respectively. Therefore, in some embodiments, the SPAM data structure 502 maintains a mapping between service plans (represented by the service plan data structure 504) and manifests (represented by the service manifest data structure 506). 【0147】 The service plan data structure 504 may represent a service plan and entities contained within the service plan. The service plan data structure 504 may include a "buildMilestones" entity having a corresponding value that contains an ordered list of build milestone identifiers (e.g., a name, an alphanumeric string, etc.). The "buildMilestones" attribute may identify, contain, or otherwise correspond to the build milestone entity 600 in Figure 6. 【0148】 Figure 6 is a block diagram showing a service plan and manifest construction milestone entity 600 according to at least one embodiment. The construction milestone entity 600 may identify any appropriate number of construction milestones corresponding to service construction. As shown in Figure 6, the construction milestone entity 600 identifies four construction milestones corresponding to code segments 602-608. 【0149】 Code segment 602 identifies a build milestone titled "absent," a corresponding description, and a list of capability publications (also called "capability dependencies" or capabilities on which this build milestone depends) that point to the capabilities that should (and in some examples, must) be published before moving to this build milestone. In this example, the list of capability publications is blank, indicating that no capability publications are expected to be "absent" before moving to the build milestone. 【0150】 Code segment 604 identifies a build milestone titled "service-partial" and a list of capability publications that indicate capabilities that should (and in some examples, must be) published before transitioning to this build milestone. In this example, the list of capability publications includes "serviceA_namespace," indicating that a publication of the "serviceA_namespace" capability is expected / required before the transition to the build milestone "service-partial" may occur. 【0151】 Code segment 606 identifies a build milestone titled "service-available," a corresponding description, and a list of capability publications that indicate the capabilities to be published (and in some examples, must be published) before transitioning to this build milestone. In this example, the list of capability publications includes "serviceA_backend," and the publication for the "serviceA_backend" capability is expected / required before the transition to the build milestone "service-available" may occur. 【0152】 Code segment 608 identifies a build milestone titled "complete," a corresponding description, and a list of capability publications that indicate the capabilities to be published (and in some examples, must be published) before transitioning to this build milestone. In this example, the list of capability publications is blank, indicating that no capability publications are expected before the transition to the build milestone "complete" may occur. 【0153】 In some embodiments, each build milestone specifies a capability publication that the service should be published before reaching a particular build milestone. A set of build milestones may also provide a high-level overview of the process for building a service and may be utilized / consumed by external consumers (e.g., other services that depend on the service to which the build milestones relate). Build milestones may be defined and used to indicate that a functional portion is available for a service. This may allow other service builds to progress when functionalities on which other services depend are available, rather than waiting for the service in question to be fully available. Build milestones may be used for coordination between services. When building a service does not involve coordination with other services, the service plan for that service may not include build milestones or a number of default build milestones (e.g., "absent" and "complete"). In some embodiments, build milestones defined in all service plans for use in region builds may be used to generate high-level graphs and / or sequencing diagrams. This may provide the service team with a simplified complexity graph view, which may make the region building process easier to understand and synthesize. As a non-restrictive example, the graph / diagram generated using the building milestones for each corresponding service may contain a reduced number of nodes (e.g., 3 per service, 4 per service, depending on the service's building milestone implementation) from the building dependency graph 338 in Figure 3, which may contain several dozen nodes per service (representing capabilities). 【0154】 Referring to Figure 5, the service plan represented by the service plan data structure 504 may include execution unit entities. As shown, the S Jarvis plan data structure 504 includes an "ExecutionUnit" attribute with a corresponding value that contains a set of execution units. Each execution unit may be used to describe how a service moves from one build milestone to the next. Execution units may describe a directed acyclic graph of releases that need to be executed. The definition of this graph centralizes the definition of how releases (e.g., flocks / phases / change types (e.g., infrastructure or apps)) interact with each other. The order of execution units may be driven by the order of build milestones defined in the corresponding build milestone entities. 【0155】 Figure 7 shows an exemplary execution unit entity 700 of an exemplary service plan according to at least one embodiment. The execution unit entity 700 may identify any appropriate number of execution units (e.g., one execution unit for each transition between ordered pairs of construction milestones identified by corresponding construction milestone entities, such as the construction milestone entity 600 in Figure 6). Figure 7 shows two such transitions (e.g., the transition between construction milestones “absent” and “service-partial” and another transition between construction milestones “service-partial” and “service-available”). Another execution unit may be defined for the transition between construction milestones “service-available” and “complete”, but is not shown in Figure 7 for simplicity. Since construction milestones are defined to have an order, execution units also have an order in relation to ordered construction milestones. 【0156】 As shown in Figure 7, the execution unit entity 700 includes execution units 702 and 704. Execution unit 702 may correspond to the transition between the build milestones "absent" and "service-partial". Execution unit 704 may correspond to the transition between the build milestones "service-partial" and "service-available". Additional execution units may be included in the execution unit entity 700, but are not shown in Figure 7. 【0157】 Each execution unit may include one or more external capability dependencies. For example, execution unit 702 specifies external capability dependencies in a set of external capability dependencies as shown in 705. These external capability dependencies may include one or more capabilities that should be published (or, in some examples, must be published) before moving from one build milestone (e.g., the "absent" build milestone) to another build milestone (e.g., the "service-partial" build milestone). The set of external capability dependencies may be a union of external capability requests for all releases defined in the step section of the corresponding execution unit. As shown in Figure 5, the external capability dependency is shown as including the capabilities "certificate_service_ready" and "capability_service_ready". Any appropriate number of external capability dependencies may be specified. In some embodiments, an execution step may not include any external capability dependencies. 【0158】 Each execution unit may indicate one or more capabilities that are expected to be published when the execution of the release corresponding to the execution unit is complete. For example, execution unit 702 specifies a set of capability publications in 707 that represent a superset of all capabilities that are expected to be published when the execution of the release shown in step section 706 is complete. Capability publications may additionally or alternatively be defined as being associated with the build milestones to which the execution is relevant. 【0159】 Each execution unit may include any appropriate number of steps (groups of steps) that, when executed, move a service from one build milestone to another. For example, execution unit 702 specifies a step section 706 containing an InfraAppPair step type. The InfraAppPair step specifies one or more infrastructure releases represented using ET aliases (e.g., ET:Alias ​​flock_DP / phase_DP / alarms_et) and flock / phase execution target (ET) transitions (e.g., Transition:absent→DP_complete_alarms_infra). Each release reference may indicate that an ET checkpoint transition is performed by the release for each ET alias. In some embodiments, an orchestrator (e.g., orchestrator 106 in Figure 1) may be configured to enforce that the infrastructure release defined in the InfraAppPair step is executed before the release defined in the corresponding App section of the same InfraAppPair step. In the example provided in Figure 7, the releases corresponding to transition absent→DP_complete_alarms_infra and absent→DP_initial_region_infra may be executed before the application releases corresponding to absent→DP_complete_alarms_app and absent→DP_initial_region_app, as specified in step section 706. In some embodiments, the orchestrator may generate a directed acyclic graph or another suitable ordered execution plan that orders the infrastructure releases before the application releases defined in the InfraAppPair step type.In some embodiments, execution targets in different phases do not have to be included in the same InfraAppPair step and / or ET ordering is required to radius the order defined in the corresponding flock setting if ordering is imposed in that flock setting. 【0160】 Other step types may be used. For example, if the region building phases are not dependent on each other, the parallel step type may be used and may run in parallel (e.g., substantially simultaneously, concurrently, and / or overlapping) if their external dependencies are resolved substantially simultaneously. If two separate phases (e.g., having separate names) are directly dependent on each other, the serial step type may be used (their corresponding releases are expected to run sequentially). 【0161】 All expected publications for a build milestone (e.g., a build milestone that is being migrated) may be published when all releases of the corresponding execution unit that caused the migration are complete. For example, the capability "serviceA_namespace" may be published when migrating to the build milestone "service-partial," as shown in code segment 604 of Figure 6. 【0162】 As another example, execution unit 704 includes a step section 708 containing a number of InfraAppPair step types, each containing one or more infrastructure and application releases. These InfraAppPair steps are grouped and ordered using serial step types as shown in 710. 【0163】 Figure 8 shows an exemplary flock configuration entity 800 of an exemplary service plan according to at least one embodiment. The flock configuration entity 800 may be used to specify a generalized configuration of the release represented in the execution unit entity 700 of Figure 7. Specifications for all execution units included in the installation process may be shown here. The flock configuration entity 800 may include any appropriate number of projects (e.g., project "sample-project" identified in 802) and any appropriate number of flocks for each project (e.g., flock "service-dp" identified in 804). Any appropriate number of phases may be defined for each flock in the phase section 806. Similarly, any appropriate number of execution targets may be defined for each phase in the execution target section 808. Each execution target section may include any appropriate number of execution target (ET) checkpoints defined in the checkpoint section 810. In some embodiments, a service plan including a flock configuration entity 800 may be authenticated to ensure that all references included in the service plan refer to valid components (for example, components managed by CIOS102 in Figure 1). 【0164】 The checkpoint section 810 may define any appropriate number of checkpoints. These checkpoints may be grouped by type (e.g., “Infra” indicating infrastructure change types, “App” indicating application change types), as shown, or each checkpoint may indicate a corresponding change type. In some embodiments, the order in which checkpoints are provided within the checkpoint section 810 may define the order in which the checkpoints are executed. In some embodiments, when checkpoints indicate a corresponding change type, infrastructure change-related releases may be ordered before any application change-related releases, even when application change-related releases are enumerated within the checkpoint section 810 in a position prior to infrastructure releases. Each checkpoint may indicate a corresponding flock configuration file, as shown in 812, external and / or internal capability dependencies, as shown in 814, and capability publications for each release, as shown in 816. Providing these mappings within the flock configuration entity 800 allows for the simplification of the execution unit entity 700 in Figure 7. The flock configuration entity 800 may be used to map execution unit steps that point to the ET checkpoint of the flock configuration entity 800 to CIOS-managed components that define the release (e.g., flock configuration files). Providing this mapping within the flock configuration entity 800 simplifies the execution unit entity 700 in Figure 7. 【0165】 One of the challenges of the previous build implementation was understanding what progress should occur each time a release is executed for a particular phase and change type of flock, especially when the phases have selective capability dependencies. It was not clear to the orchestrator (e.g., orchestrator 106 in Figure 1) which selective capability dependencies were required for each release initiated in the previous implementation, and which capabilities should be published through the release execution. The ET checkpoints defined in the flock configuration entity 800 may resolve this ambiguity by stating clear predictions of capability dependencies and capability publications for each release of the execution target. 【0166】 Figure 9 is a block diagram 900 showing the relationship between parts of a service plan (e.g., service plan 902, which is an exemplary service plan corresponding to the service plan data structure 504 in Figure 5) and a manifest (manifest 904, which is an example of a service manifest corresponding to the service manifest 506 in Figure 5) according to at least one embodiment. 【0167】 Service plan 902 may include any appropriate combination of the build milestone entity 600 in Figure 6, the execution unit entity 700 in Figure 7, and the flock setting entity 800 in Figure 8. In some embodiments, service plan 902 shows service build implementations at different levels of granularity. The highest level of granularity shows build milestones (build milestones 906-912, defined by the build milestone entity 600 and its corresponding build milestone entity). Service plan 902 may be used to specify service build in a sequence of build milestones in which the service progresses during its build. Each milestone may represent an interaction occurring between a given service and other services (e.g., publishing a capability that unblocks other services from build, and / or consuming a new capability published by another service). These build milestones may be used to understand a high-level picture of how the service builds and the in-service coordination required for that service, without needing to understand all the flocks and their in-service coordination. 【0168】 Build milestones 906-912 may be individually associated with a set of external capabilities on which the transition to the build milestone depends. These capabilities may include expected published capabilities relevant for external services (services 914, including other services in the region build). As a non-limiting example, build milestone 906 may depend on capability set 916 (containing one or more capabilities) as defined in the corresponding execution unit transition specifying the transition to build milestone 906. Build milestones 906-912 may be associated with the publication of capabilities required to start / continue the installation of another service. For example, build milestone 908 may be associated with capability set 918, which contains one or more capabilities expected to be published before transitioning to build milestone 908. In some embodiments, build milestones may be used to generate a high-level sequencing diagram that may be used to identify progress in the region build. 【0169】 Each build milestone may be associated with a corresponding execution unit. For example, build milestone 906 may be associated with execution unit 920 (corresponding to an instance of execution unit entity 700 in Figure 7). Each execution unit, including execution unit 920, may include any appropriate number of releases, such as release 922, and the order in which these releases are executed. Each release may be represented within the execution unit as an execution target checkpoint migration. The corresponding execution target checkpoint may indicate external and / or internal capability dependencies for the migration / release and may provide a mapping to the corresponding flock setting identified in service manifest 904. For example, release 922 may ultimately be mapped to a specific flock setting using service manifest item 924. Service manifest item 924 may be identified by an identifier referenced by execution unit 920 and provided in the execution target checkpoint corresponding to release 922. 【0170】 Using the entities of a service plan, one or more acyclic graphs may be generated. As a non-limiting example, a directed acyclic graph that defines a service build may be generated. This DAG may be called a “service DAG” and may include any appropriate number of nodes representing corresponding releases and the order in which these releases are executed to build the service. Nodes themselves, or edges between nodes, may be associated with external and / or internal capability dependencies. In some embodiments, graphs, lists, sequence diagrams, or any appropriate data structure may be generated for a service and / or for a region build using build milestones corresponding to the service. This data structure may be called a “milestone plan”. As yet another example, the build dependency graph 338 in Figure 3 may be generated using a service plan (e.g., as part of a SPAM set containing service plans and manifests corresponding to one or more services). As described above in Figure 3, the build dependency graph 338 may be used to drive a region build operation (e.g., to execute a deterministic order of infrastructure and application releases for a region / data center) (e.g., by the orchestrator 310 in Figure 3). 【0171】 In some embodiments, service manifest 904 may be used to specify the flock version and artifact version used to generate releases for execution targets specified in service plan 902. Service manifest 904 may be used to authenticate service plan 902, at least in part, by identifying that each release identified in service plan 902 is included in service manifest 904. In some embodiments, each service manifest item (e.g., service manifest item 924) may be mapped to a version set item so that the service manifest can be used to authenticate the version set used by CIOS 102 to perform region construction. As a non-limiting example, a SPAM set may be all constructed SPAM corresponding to services bootstrapped within a region / data center. The SPAM manifest may be used to authenticate the version set, if used to ensure that all flock configuration files and artifacts referenced in the SPAM set are included in the version set used to build the region. 【0172】 Figure 10 is a block diagram showing the relationship between a flock 1000, a number of phases, a corresponding number of execution targets for each phase, and one or more execution target checkpoints of the execution targets, according to at least one embodiment. The flock (e.g., the resources of a service) may be provisioned and deployed to the number of execution targets. Each execution target in Figure 10 is intended to represent a different location and / or set of devices to which the flock 1000 (e.g., the resources corresponding to a service) will be bootstrapped. For example, each execution target in Figure 10 may represent a different data center or set of devices. For any given data center build (one example being a “region build” referring to a data center build corresponding to a particular regional context), the resources of the flock (e.g., the resources corresponding to a service) may be bootstrapped to any appropriate number of execution targets. In some embodiments, the bootstrapping operation for a set of execution targets may be associated with “phases,” and potentially a number of phases may be defined. However, it may be associated with one or more sets of execution targets. In some embodiments, a sequence in which bootstrapping operations are performed for a set of execution targets (e.g., ET-1 to ET-3, collectively called “execution target 1002”) may be defined and associated with a phase (e.g., phase 1), while another set of execution targets (e.g., ET-8 to ET-13, collectively called “execution target 1004”) may be defined and associated with another phase (e.g., phase 2). In some embodiments, there may be a specified sequence in which the phases are performed. One phase (e.g., phase 2) may depend on the completion of an operation associated with another phase (e.g., phase 1). Similarly, one execution target (e.g., ET-2) may depend on an operation that corresponds to the completion of one or more other execution targets (e.g., ET-1).To identify a set of phases (e.g., one or more) that bootstrap a given service across multiple execution targets, a data structure (e.g., phase data structure 1006) may be generated by CIOS102 in Figure 1, where each phase is associated with one or more execution targets. Any appropriate number of data structures (e.g., one or more directed acyclic graphs, linked lists, etc.) may be generated to identify a set of execution targets (e.g., execution targets 1002) and the order in which bootstrapping a service across these sets of execution targets is performed. 【0173】 The execution targets may be associated with tenancies and regions as shown in Figure 10 (e.g., unstable-tenancy / region1, stable-tenancy / region2, prod-tenancy / region3). In some embodiments, CIOS102 in Figure 1 may allow flocks to be modeled using many tenancies within a realm and many regions within tenancies. However, CIOS102 may not allow the same region within a tenancy to be used twice (however, the same region may be used twice within a realm in different tenancies). Although not shown in Figure 1, each of ET-8 to ET13 may be associated with a corresponding tenancy and region. 【0174】 Each execution target (e.g., ET-1) may be associated with one or more execution target (ET) checkpoints (e.g., ETCKPT-1 and ETCKPT-2). Phases (e.g., Phase 1, Phase 2, etc.), execution targets (e.g., ET-1 to ET-13), and execution target checkpoints may be defined and / or specified within the flock configuration entity 800 in Figure 8. ET checkpoints may be associated with a corresponding set of releases. ET checkpoints may be ordered (e.g., in an ordered list as shown in Figure 8, or in nested lists (e.g., ordered lists of Infra and App)), each representing a unit of progress for the execution target being built. 【0175】 In some embodiments, the orchestrator 310 in Figure 3 may maintain any appropriate number of data structures (e.g., the build dependency graph 338 in Figure 3, linked lists, directed acyclic graphs, objects, etc.) to maintain dependencies between flocks, phases, execution targets, execution target checkpoints, releases, and / or similar. Similarly, the orchestrator 310 may generate data structures to maintain dependencies between build milestones, execution targets, execution target checkpoints, and / or releases. 【0176】 Figure 11 is a flowchart showing a method 1100 for generating a service plan according to at least one embodiment. Method 1100 may be performed by an orchestrator 1102 (e.g., orchestrator 106 in Figure 1). Method 1100 may include more or fewer operations than those described in relation to Figure 11. The operations of Method 1100 may be performed in any appropriate order. In some embodiments, orchestrator 106 may interact with an artifact 1104, a data store 1106, a flock store 1108, and a phone book 1110, each of which may be configured to store specific data as further described below. 【0177】 In some embodiments, service plans and manifests (SPAMs) (e.g., service plan 902 in Figure 9, and / or manifest 904 in Figure 9, each containing entities 600-800 in Figures 6-8, respectively) may be packaged and stored in a data store and / or repository (e.g., by a build service (e.g., one of the build service 1202 in Figure 12, cloud service 1856 in Figure 18), by a user, etc.) at any appropriate time (e.g., an artifact factory 1104, which is a repository manager configured to manage artifacts, binaries, files, containers, etc.). In some embodiments, one or more SPAMs may correspond to data center / region builds. In some embodiments, the artifact factory 1104 may be used to package and store service plans that have not yet been combined with manifests. 【0178】 Method 1100 may begin in 1112, where user device 1114 may be used to download / retrieve a service plan archive (or service plan) from artifact 1104 (e.g., from a specific designated path within artifact 1104). In some embodiments, the service plan archive may include an archive file (e.g., a zip, tar, tar.gz, tgz file, etc.) containing a service plan (or multiple service plans) corresponding to a specific data center / region build, and any appropriate metadata associated with the service plan. In some embodiments, the service plan may be represented by the data service plan data structure 504 in Figure 4, and the metadata may be represented by the SPAM metadata 502 in Figure 5. In some embodiments, the service plan and / or metadata may not yet be associated with a manifest (represented by the manifest data structure 506 in Figure 5). User device 1114 may provide a command-line interface (or graphical interface) through which the service plan archive and / or service plan may be retrieved. 【0179】 In 1116, the user device 1114 may send the service plan to the orchestrator 1102 along with the service plan artifact recoordinate (e.g., component / distribution / architecture coordinate, or other lookup values ​​corresponding to the service plan). In some embodiments, the service plan and / or the corresponding artifact recoordinate may be provided to the orchestrator 1102 at least in part based on a command (or user selection) provided in a command-line (or graphical) interface. 【0180】 In step 1118, the orchestrator 1102 may generate a work request ID, associate the work request ID with the service plan, metadata, and corresponding service plan coordination, and store it in the data store 1106. In step 1120, the orchestrator 1102 may send the work request ID to the user 1114 (for example, via the command line / graphical interface). 【0181】 In 1122, the orchestrator 1102 may perform an operation to determine whether the service plan is consistent. This determination may include identifying whether one component (e.g., a build milestone entity, an execution entity, a flock setting entity, or any appropriate combination and / or part thereof) matches another component of the service plan (e.g., a build milestone entity, an execution entity, a flock setting entity, or any appropriate combination and / or part thereof). For example, determining whether the service plan is consistent may include determining whether the data corresponding to the build milestones defined in the service plan matches the data corresponding to the execution unit definitions. For example, the orchestrator 1102 may determine whether the defined execution units (e.g., execution units 702, 704 in Figure 7) of the execution unit entity (e.g., execution unit entity 700 in Figure 7) of the service plan indicate build milestone names / identifiers (e.g., "from" and / or "to" attributes) that match those provided in the corresponding build milestone entity (e.g., build milestone entity 600 in Figure 6). The orchestrator 1102 may determine whether the execution unit defines all possible transitions (and potentially only) between consecutive pairs of build milestones (e.g., absent to service-partial, service-partial to service-available, service-available to complete, corresponding to the build milestones in Figure 6). If no transitions exist (or extra transitions exist), the method may proceed to 1124, where the orchestrator 1102 may reject the work request. Rejecting a work request may include, in 1126, marking the work request rejected in 1124 and / or sending a status indicating rejection along with the work request ID via the command line (or graphical) interface.Once all transitions (and potentially only) between consecutive pairs of construction milestones have been identified, method 1100 may proceed to 1128. 【0182】 In 1128 (or as part of determining whether the service plan is consistent in 1122), the orchestrator 1102 may perform an operation to determine whether there are concurrent releases for the same phase. Determining whether there are concurrent releases for the same phase may involve parsing the service plan's flock setting entities (e.g., flock setting entity 800 in Figure 8) to identify whether a checkpoint section for a given phase (e.g., checkpoint section 810) contains two or more releases (e.g., having the same or different names) that are defined as being able to run concurrently. If so, the orchestrator 1102 may be configured to reject the work request (e.g., marking the work request as rejected in 1124 and / or sending a status indicating the work request as rejected in 1126). Otherwise, method 1100 may proceed to 1130. 【0183】 In 1130, the orchestrator 1102 may perform an operation to determine whether a flock (e.g., a flock configuration) referenced in the service plan exists. For example, the orchestrator 1102 may send a request to the flock store 1108 to determine whether each flock referenced in the service plan (e.g., including the flock configuration referenced in 810 of Figure 8) is stored in the flock store 1108. The flock store 1108 may be managed by the CIOS central 108 in Figure 1, or the flock store 1108 may be a separate data store configured to store flock configuration files. In some embodiments, the flock store 1108 is an example of DB312 in Figure 3. If a flock setting is referenced in the service plan but is not stored in the flock store 1108, the orchestrator 1102 may be configured to reject the work request (for example, by marking the work request as rejected in 1124 and / or sending a status indicating that the work request has been rejected in 1126). Otherwise, method 1100 may proceed to 1126. 【0184】 In 1132, the orchestrator 1102 may perform an operation to determine whether a phonebook entry exists for the service. The phonebook entry refers to contact data corresponding to one of the phonebookIDs in the data structure of Figure 5. The phonebookID may be an attribute contained within the service plan (or metadata corresponding to the service plan) that identifies the service team and / or contact information for the owner of the service plan. In some embodiments, the phonebookID may be a unique identifier assigned and managed by another service / system (e.g., a phonebook service) configured to manage contact information (e.g., email, phone number, etc.) for any appropriate number of entities. As a non-restrictive example, the orchestrator 1102 may send a request to a phonebook 1110 (e.g., a service) that has a phonebookID obtained from the service plan. If the phonebook 1110 returns contact information corresponding to the phonebookID, method 1100 may proceed to 1134. Otherwise, the orchestrator 1102 may be configured to reject the work request (for example, by marking the rejected work request in 1124 and / or by sending a status in 1126 indicating that the work request has been rejected). 【0185】 In 1134, the service plan and metadata may be stored in the data store 1106. In some embodiments, a work request may be marked as completed in 1136. Marking a work request as completed may include updating the status associated with the work request and / or sending a status indicating that the work request has been completed (for example, via the command line or graphical interface used to submit the request in 1116). 【0186】 Figure 12 is a flowchart illustrating a method 1200 for generating service plans and manifests (SPAM) (represented by data structures 502-508 in Figure 5, service plan 902 and manifest 904 in Figure 9, etc.) according to at least one embodiment. Method 1200 may be performed by a build service 1202 (an example of cloud service 1856 in Figure 18), an orchestrator 1204 (e.g., orchestrator 106 in Figure 1), a CIOS central 1208 (e.g., CIOS central 108 in Figure 1), or any appropriate part of CIOS 102. Method 1200 may include more or fewer operations than those described in relation to Figure 12. The operations of Method 1200 may be performed in any appropriate order. In some embodiments, the orchestrator 106 may interact with a data store 1206 (e.g., data store 1106 in Figure 11) and an artifact 1210 (e.g., artifact 1102 in Figure 11), each of which may be configured to store specific data as described herein. 【0187】 The method may begin at 1212, where a SPAM generation work request may be sent to generate a SPAM service plan (e.g., service plan 902 in Figure 9) and manifest M (e.g., manifest 904 in Figure 9), having entries x, y, z (corresponding to their respective flock settings). In some embodiments, the SPAM generation work request may include a service plan ID, any appropriate SPAM data (e.g., any appropriate data corresponding to the attributes of the SPAM data structure 502 in Figure 5), a locally stored manifest (a manifest stored on user device 1214), and / or entries x, y, z (e.g., flock ID, gitCommit hash, one or more artifact versions as shown in service manifest item 924 in Figure 9, or any appropriate data corresponding to the service manifest item data structure 508 in Figure 5), and may be sent to orchestrator 1204 via the SPAM generation work request. In some embodiments, the service plan ID, manifest, and / or data corresponding to entries x, y, and z may be transmitted at least in part on the basis of entering commands via a command-line interface provided to the user device 1214. In some embodiments, the SPAM generation work request may be transmitted to the orchestrator 1204 through the build service 1202 (for example, the request may be transmitted first to the build service 1202 and then transmitted to the orchestrator 1204 by the build service 1202). In some embodiments, the build service 1202 may initialize the SPAM generation work request. The manifest M may be stored (and potentially generated) locally on the user device 1214, or the manifest M may be stored in a storage location accessible to the build service 1202 and / or the orchestrator 1204. 【0188】 In 1214, the orchestrator 1204 may save the SPAM generation work request to the data store 1208 for record-keeping purposes. 【0189】 In 1216, the orchestrator 1204 may retrieve the service plan (and potentially the metadata corresponding to the service plan) at least in part based on submitting a query to the data store 1208 that includes the service plan ID received in 1212. In some embodiments, retrieving the service plan and metadata may be performed using a separate query to the data store 1208. If the service plan and / or metadata are not returned, the orchestrator 1204 may determine that the requested SPAM is valid and reject the SPAM generation work request. Rejecting the SPAM generation work request includes, in 1218, marking the SPAM work request stored in 1214 as rejected, and / or, in 1220, sending a status indicating that the SPAM work request has been rejected. If the service plan (and metadata, if requested) are returned, method 1200 may proceed to 1222. 【0190】 In 1222, the orchestrator 1204 may obtain static flock analysis (SFA) data for the flock configuration files corresponding to entries x, y, and z from the CIOS central 1206. In some embodiments, the SFA data may be generated at least in part on performing a static flock analysis (e.g., by the CIOS central 1206) on one or more flock configuration files (e.g., at least the flock configuration files corresponding to entries x, y, and z) as described above with respect to Figure 3. In some embodiments, the SFA data may include dependencies identified from the static flock analysis. In some embodiments, obtaining the SFA data for entries x, y, and z may involve requesting the CIOS central 1206 to parse the flock configuration files corresponding to entries x, y, and z. 【0191】 In 1224, the orchestrator 1204 may perform any appropriate operations to determine whether the SFA data for the flocks corresponding to x, y, and z are consistent with the service plan. In some embodiments, determining consistency may include determining whether the dependencies identified in the SFA data match / conform to the dependencies declared in the service plan (e.g., the external and / or internal capability dependencies of the execution unit 700 in Figure 7 and / or the flock setting entity 800 in Figure 8). In some embodiments, determining consistency may include determining whether the order of releases shown in the SFA data matches the order of releases defined in the service plan. If it is determined that the SFA data is inconsistent with the service plan, the orchestrator 1204 may be configured to consider the requested SPAM invalid and may reject the SPAM generation work request (e.g., in 1218, marking the SPAM generation work request as rejected and / or in 1220, sending a status indicating that the SPAM generation work request has been rejected). 【0192】 In step 1224, the orchestrator 1204 may verify that the flock configuration files corresponding to entries x, y, and za are stored in the artifact 1210. If so, method 1200 may proceed to 1228. Otherwise, the orchestrator 1204 may consider the requested SPAM invalid and reject the SPAM generation work request (including, for example, in step 1218, marking the SPAM generation work request as rejected and / or in step 1220, sending a status indicating that the SPAM generation work request has been rejected). 【0193】 In 1228, the orchestrator 1204 may determine that the requested SPAM is valid. In some embodiments, the orchestrator 1204 may generate a manifest from entries x, y, and z (if a manifest was not provided in 1212). The service plan and manifest (and potentially any metadata corresponding to the service plan and / or manifest) may be stored in the data store 1208 as a new SPAM. This may involve generating a unique identifier for the SPAM and storing this identifier as part of the SPAM (for example, via the SPAM data structure 502 in Figure 5, associated with the service plan represented by the service plan data structure 504 in Figure 5 and the manifest represented by the service manifest data structure 506 in Figure 5, each containing entries x, y, and z represented by the service manifest item, each corresponding to an instance of the service manifest item data structure 508 in Figure 5). 【0194】 At 1230, the orchestrator 1204 may perform an operation to mark the SPAM generation work request as complete. This may include updating the SPAM generation work request with a status value indicating completion. 【0195】 Figure 13 is a flowchart illustrating a method 1300 for adding SPAM (e.g., service plan 902 and manifest 904, represented by data structures 502-508 in Figure 5) to a SPAM set (e.g., a SPAM set) according to at least one embodiment. Method 1300 may be performed by an orchestrator 1302 (e.g., orchestrator 106 in Figure 1). Method 1300 may include more or fewer operations than those described in relation to Figure 13. The operations of Method 1300 may be performed in any appropriate order. In some embodiments, orchestrator 1302 may interact with SPAM set proposals 1304 (e.g., a data store configured to store SPAM set proposal data, queues, etc.) and data store 1306 (e.g., data store 1208 in Figure 12), each of which may be configured to store specific data as described herein. 【0196】 In some embodiments, SPAM may only become active when it is added to a SPAM set that associates SPAM with a regional context (e.g., SPAM set 510 in Figure 5). SPAM may be stored and associated with any appropriate number of SPAM sets (e.g., 0, 1, 2, etc.). Method 1300 may be performed to add SPAM to a SPAM set. 【0197】 Method 1300 may begin at 1310, where a SPAM set update proposal may be received by the orchestrator 1302 from the user device 1308. The SPAM set update proposal may be in any suitable format and may include an identifier corresponding to SPAM (e.g., for illustrative purposes, "SPAM X", SPAM name) which is represented by any suitable combination of one or more instances of the SPAM data structure 502, a service plan data structure 504 which includes, for example, the service plan 902 in Figure 9, a manifest represented by the service manifest data structure 506, and, for example, the manifest item data structure 508 in Figure 5 which includes, for example, the manifest 904 in Figure 9). In some embodiments, an identifier for a SPAM set (e.g., for illustrative purposes, "SPAM set S") may be included in the SPAM set update proposal. 【0198】 In step 1312, a new proposal corresponding to "Add SPAM X" may be generated by the orchestrator 1302, assigned a work request ID, and then added to the SPAM set proposal 1304 (for example, a database table used to track SPAM set proposals). In some embodiments, the SPAM set proposal 1304 may include a first-in, first-out queue. In some embodiments, the orchestrator 1302 may store entries corresponding to SPAM set update proposals in the data store 1306 (for example, a data store that also stores SPAM sets, such as DB312 in Figure 3). 【0199】 In step 1314, the orchestrator 1302 may send the work request ID generated in step 1312 to the user device 1308. 【0200】 In 1316, when it is time to process the proposal, the orchestrator 1302 (or one of the set of high-availability worker nodes not shown) may retrieve the SPAM set proposal "Add SPAM X" from the SPAM set proposal 1304. 【0201】 In 1318, the orchestrator 1302 (or worker node) may retrieve SPAM set S from datastore 1308 (for example, DB312 in Figure 3) using the SPAM set identifier obtained from the proposal. SPAM set S may contain any appropriate number of SPAMs that have been previously determined to be compatible with one another (for example, by the orchestrator 1302). 【0202】 At 1320, the orchestrator 1302 (or worker node) may perform any appropriate operations to determine whether SPAM X is compatible with SPAM already included in SPAM set S. In some embodiments, this may include determining whether a capability publication is duplicated. The SPAM set update proposal may be marked as rejected at 1322, the proposal may be removed from SPAM set proposal 1304 at 1324, and a status indicating that the SPAM set proposal corresponding to the work request ID has been rejected may be sent at 1326. If no duplicate exists, the invariant conditions of SPAM set S are not broken by the addition of SPAM X, and / or SPAM X is determined to be compatible with SPAM set S based at least partially on a given set of rules, and the method may proceed to 1328. 【0203】 In 1328, the orchestrator 1302 (or worker node) may generate a graph (e.g., the construction-dependent graph 338 in Figure 3) using a combination of SPAM X and SPAM set S. 【0204】 At 1330, the orchestrator 1302 may perform any appropriate operations to identify cycles in the graph. If one or more cycles are identified, at 1332, the SPAM set update proposal may be marked as rejected (and cycle information associated with the identified cycles may be stored in the SPAM set update proposal), at 1324 the proposal may be removed from the SPAM set proposal 1304, and at 1326 a status may be sent indicating that the SPAM set proposal corresponding to the work request ID has been rejected. Otherwise, method 1300 may proceed to 1322. 【0205】 At 1332, the orchestrator 1302 (or worker node) may update SPAM set S to include SPAM X and send the updated SPAM set to data store 1306 to maintain the changes. At 1334, the SPAM set update proposal may be marked as accepted (and associated with a status indicating that the proposal has been accepted), at 1324, the proposal may be removed from SPAM set proposal 1304, and at 1326, a status may be sent indicating that SPAM set proposal 1304 corresponding to the work request ID has been accepted. 【0206】 It should be acknowledged that Method 1300 may be performed for SPAM set update proposals for SPAMs that, when added to a SPAM set, structurally alter the build dependency graph generated for that SPAM set. For example, Method 1300 may be performed for SPAMs that include new capability dependency and / or artifact version updates. Updates that do not affect the build dependency graph of a SPAM set may be handled through another process not shown, where the update may be accepted unconditionally. For example, if a SPAM is replaced with a new SPAM that shares the same service plan as the one it was replacing, the SPAM update may be accepted unconditionally, and the execution of Method 1300 is abandoned. 【0207】 Once changes to a set of SPAMs are accepted, updates to one or more version set items in one or more version sets may be initiated. For example, adding new SPAMs, removing SPAMs, or updating SPAMs may result in the creation, removal, or modification of one or more version set items. These version set items may be added to, removed from, or updated in version sets that the orchestrator 310 in Figure 3 may use to construct the build dependency graph 338 in order to drive the orchestration operations described in Figure 3. 【0208】 In some embodiments, the orchestrator 1302 (or worker node) may be configured to again guard against racing updates (e.g., two updates replacing the same SPAM in the SPAM set by different team members) by capturing the current ID of the SPAM as part of the update proposal. If the ID of the SPAM in the SPAM set is different from the one encoded in the proposal when the proposal is processed, the orchestrator 1302 (or worker node) may reject the update. 【0209】 Figure 14 is a block diagram illustrating an exemplary lifecycle 1400 for a skill according to at least one embodiment. The lifecycle 1400 may include any appropriate number of states. As illustrated, the lifecycle 1400 includes states such as declared, selected, unselected, installing, installed, prohibited, retired, and uninstalled, but other combinations of lifecycle states are possible. A lifecycle state may correspond to the installationState attribute of the skill data structure 410 in Figure 4. In some embodiments, a lifecycle state may be associated with any appropriate number of substates. Each of these substates may correspond to the healthState of the skill version data structure 412 in Figure 4. As shown in Figure 14, a skill associated with the "installed" lifecycle state may be associated with one of three substates (e.g., "unknown," "unhealthy," and "healthy"). Similarly, a skill associated with the "prohibited" state may be associated with the "healthy" and / or "unhealthy" substates. Descriptions for the conditions indicated by each state are provided below. 【0210】 [Table 1] 【0211】 In some embodiments, in step 1, selecting the option to publish the skill may generate an instance of the skill version data structure 412 in Figure 4 corresponding to the skill and update it to indicate the installation state "Declared". In step 2, the orchestrator 106 may select the skill for installation in a target region (e.g., target region 114) and send data indicating the selection (or state transition to "Selected"). Upon receiving this data, the Puffin service may update the skill version data structure 412 to "Selected". In step 3, the orchestrator 106 in Figure 1 may begin deploying the resources of the service that produces the associated skill and send new instructions for setting the skill's installation state to "Installing". Upon receiving this, the Puffin service may update the skill version data structure 412 to "Installing". In step 4, the skill's installation state may be updated to "Installed" when the installation of the service that produces the associated skill is successfully completed. In general, any of the state transitions described herein may be initiated by the orchestrator 106 (upon receiving instructions from the CIOS Regional or CIOS Central that one or more releases have been successfully executed). Upon receiving any appropriate instructions for any state transitions occurring, the Puffin service may update the installation state of the skill version data structure 412. While the skill is associated with the “installed” state, the Puffin service may monitor the skill’s health. 【0212】 In some embodiments, monitoring the health of a skill may include monitoring for indication that one or more alarms associated with the skill (e.g., alarms indicated by the alarmLabelName attribute in the health check data structure 414 in Figure 4) have been triggered (e.g., by an alarm service such as the telemetry service and / or sentinel service, each an example of one of the services of the cloud service 1856 in Figure 18). In some embodiments, if an alarm service configured to provide these alarms (e.g., the telemetry service) is unavailable, the substate corresponding to the "healthState" attribute in the skill version data structure 412 may be updated to indicate an "unknown" health state for the installed skill. If no alarms have been triggered for at least a threshold time, the healthState attribute of the skill version may be set to a value indicating a "healthy" state for the installed skill. Upon receiving an indication that an alarm associated with the skill has been triggered, the Puffin service may update the healthState attribute of the skill version to an "unhealthy" state for the installed skill. 【0213】 In step 5, the installation status may be updated to “Forbidden” (e.g., by the orchestrator, by the Puffin service, and / or based on user input) to indicate that health monitoring should continue, but only skills of the same production service should be treated as if the prohibited skill was installed. In some embodiments, the skill's installation status may revert to “Installed”. 【0214】 In some embodiments, the skill version may be retired in step 6 (for example, via user input). In the retired state, the skill version may not be (or cannot be) used by other skills and / or in any build or run. In some embodiments, the installation state of the skill version may not be modified when the skill is transitioned to the retired state. 【0215】 In some embodiments, the installation state of a skill version may transition from an “installed” state to an “uninstalling” state based at least in part on an operation performed by the orchestrator and / or user input. In some embodiments, the orchestrator 106 may determine that a service deployment should be rolled back. In these situations, the orchestrator 106 may “roll back” the installation of one or more services. During these operations, if a service is being uninstalled in step 7, the associated skill version may be updated to indicate an “uninstalling” state. Once the service associated with the skill version is successfully uninstalled, the installation state of the skill version may be updated to “selected” in step 8. 【0216】 Numerous transitions between various states and substates are possible. The lifecycle states and transitions shown in Figure 14 are illustrative and are not intended to limit the scope of disclosure. 【0217】 Figure 15 is a flowchart illustrating an exemplary method 1500 for managing skill state during data center / region construction, according to at least one embodiment. Method 1500 may be performed by any suitable combination of Puffin Central 1502 (e.g., Puffin Central 118 in Figure 1), Orchestrator 1504 (e.g., Orchestrator 106 in Figure 1), Puffin Regional 1506 (e.g., Puffin Regional 120 in Figure 1), and CIOS Central 1508 (e.g., CIOS Central 108 in Figure 1). Method 1500 may include more or fewer operations than those described in relation to Figure 15. The operations of Method 1500 may be performed in any suitable order. 【0218】 Method 1500 may begin in 1510, where Puffin Regional 1506 may be seeded by Puffin Central 1502 with all predefined skills, versions, and consumers. In some embodiments, Puffin Central 1502 may utilize an application programming interface, a function call, or another suitable method for communicating metadata corresponding to each previously defined skill (e.g., user-generated and / or system-generated skills, the latter referred to herein as “shadow skills”) to Puffin Regional 1506. In some embodiments, Puffin Central 1502 may transmit an identifier corresponding to each skill (and their skill versions), which Puffin Regional 1506 may use to retrieve a corresponding instance of skill metadata. In some embodiments, Puffin Central 1502 may be configured to identify and transmit skill metadata and / or identifiers (e.g., skill ID, major version, minor version, etc.) for skills used to build a region corresponding to Puffin Regional 1506. In some embodiments, the skill state for each of these skills may indicate that the skill has been selected but has not yet been installed. The skill state may be represented by any suitable combination of the installationState and / or healthState attributes of the corresponding skill version data structure (e.g., skill version data structure 412 in Figure 4). For example, the "installationState" attribute may be set to a predetermined value associated with the selected state. 【0219】 Operation 1511 may include any appropriate operations for constructing a target set and an ordered execution plan. For example, in 1512, the orchestrator 106 may perform any appropriate operations for identifying all skills, versions, and respective skill states for consumers for a region. This may include identifying the installation and / or health state of each skill (e.g., at least in part on the installationState and healthState attributes of the skill version data structure 412 in Figure 4), the version identifier corresponding to each skill (e.g., at least in part on the major and / or minor version attributes of the skill data structure 410 in Figure 4), and / or the identifier of each consumer of the identified skill. Consumers of identified skills may be identified at least in part on determining all instances of the skill consumer data structure 418 that indicate the ID of the skill data structure 410 and / or the service ID of the service data structure 406 corresponding to the identified skill, via any appropriate combination of the consumingSkillID and / or consumingServiceID attributes. 【0220】 In 1514, a target set and / or an ordered execution plan may be generated. In some embodiments, constructing a target set may include any appropriate combination of identifying and / or obtaining: 1) a version set of flock configurations (a "golden set" corresponding to a specific set of flock configurations individually identified by a particular version identifier and corresponding to a set of services deployed in the region); 2) a set of service plans and manifests (SPAMs) (e.g., a specific SPAM set associated with a particular version identifier and corresponding to a set of services deployed in the region); 3) a set of artifacts (e.g., program code associated with a particular version identifier used / executed to provision infrastructure and / or deploy software within the region). As described above in relation to Figure 3, constructing an ordered execution plan may include parsing the flock configurations and / or SPAMs to determine dependencies between execution units, dependencies between services, dependencies between execution units of a single service, etc. In some embodiments, constructing an ordered execution plan may include performing the static flock analysis described above to identify circular dependencies. The build dependency graph 338 in Figure 3 (or another appropriate ordered list showing the operations performed for region build) may be considered an example of an ordered execution plan generated by orchestrator 1504 in 1514. 【0221】 Once constructed, the ordered execution plan may be used by the orchestrator 1504 to perform the region construction. For example, in 1516, the orchestrator 1504 may identify all the skills on which the current step depends for the current step. As described below, the Puffin Regional 1506 may maintain compatibility between skills and capabilities. Thus, in embodiments where at least some capabilities are used to indicate the availability of a particular service, resource, or function, the Puffin Regional 1506 may generate shadow skills for these capabilities (e.g., before the region construction), and these shadow skills, by which the corresponding skill states are used to track the current state of the capabilities represented by these shadow skills. In some embodiments, the Puffin Regional 1506 may be configured to retrieve capability data from storage, from the capability service 112 in Figure 1, from the orchestrator 1504, or in any appropriate combination of the above. Puffin Regional 1506 may be configured to update skill states for any appropriate skill states based on data received from the orchestrator 1504, capability service 112, and / or alarm service (e.g., one of the cloud services 2056 in Figure 20), or any appropriate combination thereof. If a skill (e.g., a user-defined or system-defined skill) is associated with a large number of capabilities, the skill may not be considered installed or transitioned to a particular state (e.g., the "installed" state) until Puffin Regional 1506 determines that each capability has been published or otherwise indicated as available. 【0222】 In 1518, the orchestrator 1504 may query the Puffin region 1506 for the current state corresponding to each skill on which the current step depends. Skills may be identified at least in part on any suitable combination of skill ID, major version identifier, and / or minor version identifier, and / or according to any suitable combination of attribute values ​​configured to be unique across skills. At the start of region construction (e.g., in the first step, the first node of the construction dependency graph 338, the first operation in the ordered list of operations, etc.), the current step may lack relevance to any upstream skills. If no dependency is identified for the current step, method 1500 may proceed to 1520 without performing the operation in 1518. 【0223】 In a scenario where, in 1520, the orchestrator 106 returns to the corresponding skill state for one or more upstream skills (e.g., skills on which the current step depends) indicating that one or more upstream skills are not in a particular state (e.g., “installed”) and / or substate (e.g., “healthy”), the orchestrator 106 may perform an operation to indicate failure. In some embodiments, the current state of these skills may be viewed in a user interface similar to that shown in Figure 6 to allow root cause analysis to be performed (e.g., by the system or user). In some embodiments, the “unhealthy” substate of one or more upstream skills may cause the Puffin regional 1506 to trace or otherwise traverse the ordered execution plan (and / or build dependency graph 338) upward (e.g., upstream from the current step), thereby identifying the earliest upstream skill (which first occurs in the ordered execution plan) associated with the “unhealthy” state. An example of the information obtained from this trace is shown in area 616 of Figure 6. In some embodiments, the orchestrator 106 may be configured to wait and periodically resubmit queries at a predetermined frequency or schedule while waiting for an instruction that the upstream skill is associated with an installation state of “installed” and a substate of “healthy”. 【0224】 In 1522, at any appropriate time, the orchestrator 1504 may identify that upstream skills are installed and healthy based on the skill status obtained from the Puffin Regional 1506. In response to identifying that all upstream skills are installed and healthy, the orchestrator 1504 may transmit data for the skills associated with the current step, indicating that the current status of these skills is "installed". By transmitting such data, the Puffin Regional 1506 may update the installation status attribute of the skill version data structure 412 in Figure 4 associated with the skill to indicate the skill status of "installed". 【0225】 At 1524, the orchestrator 1504 may perform an operation to instruct the CIOS central 1508 to initiate one or more releases. In some embodiments, the CIOS central 1508 may instruct instances of CIOS regionals within the region (e.g., CIOS regional 110 in Figure 1, CIOS regional 110 deployed in the target region being built) to perform an operation for a given release. Examples of operations performed by the CIOS central 1508 and CIOS regional 110 are described in detail with respect to Figure 3 and are not repeated here for brevity. At 1526, the CIOS central 1508 may send an instruction that the release was successful or unsuccessful. If unsuccessful, the orchestrator 1504 may perform an operation to instruct the CIOS central 1508 again to try the release again. This retry process may be performed any appropriate number of times according to any appropriate predetermined protocol. 【0226】 In step 1528, upon successful release, the orchestrator 1504 may send data to the Puffin Regional 1506 indicating that the skill associated with the current step is now installed. Any appropriate operation performed (e.g., by the orchestrator 1504) to update the skill state (e.g., via the Puffin Regional 1506) to indicate that the skill has been installed may be referred to as “publishing the skill”. In response to receiving this data, the Puffin Region 1506 may update the skill's installation state to a value corresponding to the “installed” state. In some embodiments, the Puffin Regional 1506 may be configured to send any appropriate data (e.g., all) for any appropriate combination (e.g., all) of the capabilities associated with the skill that has been transitioned to the “installed” state (e.g., capabilities identified by the capability attribute in the skill data structure 410 in Figure 4). 【0227】 In some embodiments of 1530, the Puffin Regional 1506 may be configured to initiate an operation to monitor the health status of an installed skill. In some embodiments, this may include monitoring for one or more alarms (e.g., indicated by alarm labels in the health check data structure 414 in Figure 4). The Puffin Regional 1506 may update a substate (e.g., the healthState attribute in the health check data structure 414) in accordance with the monitoring. For example, if the Puffin Regional 1506 determines through monitoring that an alarm associated with a given skill has been triggered, it may update the skill's substate to indicate an "unhealthy" state. The Puffin Regional 1506 may be configured to update the set to indicate "healthy" or leave the skill's substate unchanged if it determines that no alarms associated with the skill have been triggered (to date, or at least over a predetermined threshold time). 【0228】 At 1532, the orchestrator 1504 may move to the next step in the ordered execution plan (for example, the next node in the build dependency graph 338). The operations described in 1516-1532 may be executed any number of appropriate times corresponding to each step in the ordered execution plan. If the plan has already reached the last step, the orchestrator 1504 may terminate the region build at 1532. 【0229】 Figure 16 is a block diagram illustrating an exemplary method 1600 for managing compatibility between capabilities and skills, according to at least one embodiment. Method 1600 may be performed by any suitable combination of capability services 1602 (e.g., capability service 112), Puffin regional 1604 (e.g., Puffin regional 118), and Puffin central 1606 (e.g., Puffin central 120 in Figure 1). Method 1600 may include more or fewer operations than those described with respect to Figure 16. The operations of Method 1600 may be performed in any suitable order. Prior to the execution of Method 1600, capability service 1602 may be configured to receive data (e.g., from CIOS regional 110, worker 320, worker 328, etc.) indicating that the capability is available in the region, or in other words, that the capability has been published. The capability service 1602 may be configured to maintain tables or other appropriate records (e.g., capability table 1608) which may be stored locally or in a storage location accessible to any appropriate combination of components of CIOS 102 in Figure 1. The capability table 1608 may contain capabilities previously published in each region. 【0230】 In step 1, at any appropriate time, Puffin Regional 1604 may receive or acquire a directive that capability A has been published. Puffin Regional 1604 may be configured to manage or otherwise maintain any appropriate records for all known skills (e.g., user-defined and / or system-generated skills, the latter referred to as “shadow skills”). As just one example, Puffin Regional 1604 may manage a skills table 1610 and a skill version table 1612. In some embodiments, the skills table 1610 may include identifiers and / or skill data structures (e.g., each corresponding to a skill data structure 410 in Figure 4) to maintain records of all known skills. Since any appropriate number of versions of a skill may be defined, the skill version table 1612 may be used to maintain knowledge of all versions corresponding to each skill. In some embodiments, upon receiving / acquiring an instruction that capability A has been published or otherwise identified as available, Puffin Regional 1604 may query the skills table 1610 associated with capability A (or look up or otherwise identify the skills data structure). This may include identifying from the skills data structure that the capability attribute of the structure is associated with a value corresponding to the identifier of capability A. If the skill is not identified as being associated with a capability, Puffin Regional 1604 may generate a shadow skill (e.g., an instance of any appropriate combination of the data structures of skill metadata 404 in Figure 4) and configure the attributes of the shadow skill to default and / or specific values ​​according to a predetermined protocol and / or the attributes of the capability (e.g., the identifier of the capability). As a non-restrictive example, Puffin Regional 1604 may generate an instance of the skills data structure 410 in step 1. This instance of the skills metadata may be called "skill A" and may be used to represent capability A. 【0231】 In step 2, when the shadow skill is generated in step 1, the Puffin regional 1604 may generate a skill version data structure 414 for the shadow skill. In some embodiments, the value for the data structure attribute associated with the shadow skill A may be set to a value that conforms to a predetermined protocol. In some embodiments, the skill version may be used to track runtime information of the skill (e.g., whether the skill is installed and / or healthy). The term “skill” may be used herein to mean any appropriate combination of user-defined skills and / or system-generated shadow skills. 【0232】 In step 3, at any appropriate time, Puffin Regional 1604 may make an Application Programming Interface (API) call to Puffin Central 1606 to inform Puffin Central 1606 of the existence of skill A. In some embodiments, the data provided by this API call may include any appropriate portion of the metadata of skill A as generated and / or modified by Puffin Regional 1604. Puffin Regional 1704 may provide any appropriate information corresponding to shadow skill A on demand through any appropriate user interface. One example of an exemplary user interface is described in detail in U.S. Patent Application No. 18 / 520,103, filed November 27, 2023, entitled “Tracking Data Center Build Dependencies with Capabilities and Skills,” the entire content of which is incorporated by reference for all purposes. 【0233】 As an example of an unrestrictive use case, Service 2 may, once dependent on Capability A, be associated with a flock configuration and / or SPAM that utilizes a skill to represent the process of building Service 2. Based at least in part on the existence of Shadow Skill A, Service 2 may register prior to Shadow Skill A in step 4, allowing Service 2's dependency on Capability A to be represented using the skill (Shadow Skill A) instead of the capability. The use of Shadow Skills allows Puffin Central 1606 and / or Puffin Regional 1604 to track the region building process using a single configuration, a skill, and the skill includes attributes that enable tracking functionality previously lacking with respect to capabilities. 【0234】 In step 5, after service 1 is associated with an ordered execution plan, which is likely to be executed in terms of skills rather than capabilities, one or more user interfaces of Puffin Central 1606 may be used for shadow skill A to be claimed by service 1. 【0235】 Figure 17 is a flowchart illustrating an exemplary method 1700 for utilizing service plans and manifests to generate or verify data center construction operations, according to at least one embodiment. The operations of method 1700 may be performed in any appropriate order by any appropriate combination of components of CIOS 102 in Figure 1. As mere example, method 1700 may be performed by the orchestrator 106 and CIOS central 108 in Figure 1. It is conceivable that method 1700 may include more or fewer operations than those shown in Figure 17. 【0236】 Method 1700 may begin in 1702, where a service plan (e.g., service plan 902 in Figure 9) is obtained, which defines a first sequence for executing one or more releases as part of a first process for bootstrapping a service within a cloud computing environment. The service plan data structure 504 in Figure 5 (which in some cases is combined with the attributes of the SPAM data structure 502 in Figure 5) may represent the service plan. In some embodiments, the service plan may include any appropriate combination of the entities described above in relation to Figures 6-8. 【0237】 In step 1704, a manifest (e.g., manifest 904 in Figure 9) may be obtained that identifies a configuration file defining the operations associated with executing one or more releases. The manifest may be obtained via a request as described in 1212 in Figure 12, or it may be stored locally or in a storage location accessible to CIOS 102 and / or orchestrator 106. The manifest may contain a number of entries corresponding to flock configuration files and / or artifacts that may (and in some examples must be) used for the first process. 【0238】 In 1706, a directed acyclic graph (e.g., the build dependency graph 338 in Figure 3) may be generated, at least partially based on multiple service plans, including a service plan. The directed acyclic graph may define a second sequence for executing a set of releases, including a release. The set of releases may be associated with a second process for fully bootstrapping multiple services within a cloud computing environment. 【0239】 In 1708, a subset of releases of a set of releases associated with a second process for fully bootstrapping multiple services within a cloud computing environment may be executed. In some embodiments, the subset of releases may be executed in a second order based at least in part on traversing a directed acyclic graph. 【0240】 Although not illustrated, Method 1700 may include validating a service plan based at least partially on a manifest by a cloud infrastructure orchestration service. In some embodiments, validating a service plan based at least partially on a manifest includes one or more of the following: 1) the cloud infrastructure orchestration service obtains static flock analysis data corresponding to configuration files identified by the manifest, the static flock analysis showing a first set of dependencies; 2) the cloud infrastructure orchestration service determines a second set of dependencies based at least partially on the service plan; and 3) the cloud infrastructure orchestration service determines that the first set of dependencies matches the second set of dependencies. The operations for validating a service plan are described in more detail with respect to Figure 12. 【0241】 Although not illustrated, Method 1700 may further include determining whether a service plan is consistent, at least in part, based on the determination by a cloud infrastructure orchestration service that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. The operations for determining whether a service plan is consistent are described in more detail with respect to Figure 11. 【0242】 Although not illustrated, Method 1700 may further include the Cloud Infrastructure Orchestration Service 1) generating a directed graph based at least partially on multiple service plans, and 2) determining that the multiple service plans are compatible based at least partially on determining that the directed graph lacks cycles. In some embodiments, the Cloud Infrastructure Orchestration Service may also include adding a service plan to a set of service plans that includes multiple service plans. In some embodiments, the service plan is added to the set of service plans based at least partially on determining that the multiple service plans are compatible. The Method may also include the Cloud Infrastructure Orchestration Service retrieving a version set that identifies multiple configuration files in order to be in the middle of a second process to fully bootstrap multiple services within a cloud computing environment. The version set may be retrieved based at least partially on a set of service plans. Exemplary operations for determining compatibility between a service plan and multiple service plans (e.g., a set of SPAMs), adding a service plan to a set of SPAMs, and retrieving a version set from a set of SPAMs are described in more detail with respect to Figure 13. 【0243】 In some embodiments, a version set includes multiple version set items, the first of which is associated with a corresponding service plan, and the second of which is unrelated to any service plan. 【0244】 Although not illustrated, Method 1700 may further include determining that multiple service plans are compatible, at least in part, based on the Cloud Infrastructure Orchestration Service determining that there are no overlapping capability publications among the multiple service plans. 【0245】 Exemplary Cloud Service Infrastructure Architecture As described above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer)). In some cases, the IaaS provider may supply various services to support these infrastructure components (exemplary services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Therefore, since these services can be policy-driven, IaaS users may implement policies to promote load balancing in order to maintain application availability and performance. 【0246】 In some cases, IaaS customers may access resources and services over a wide area network (WAN), such as the internet, and use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on those VMs. The customer can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery. 【0247】 In most cases, the cloud computing model requires the participation of a cloud provider. The cloud provider may, but does not have to be, a third-party service specializing in providing (offering, renting, or selling) IaaS. An entity may choose to deploy a private cloud and become its own provider of infrastructure services. 【0248】 In some cases, an IaaS deployment is the process of adding a new application or a new version of an application to a prepared application server, etc. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may be responsible for handling the (OS), middleware, and / or application deployment (e.g., in self-service virtual machines, e.g., those that can be spun up on demand). 【0249】 In some cases, IaaS provisioning may refer to acquiring computers or virtual hosts for use, and even installing the necessary libraries or services on them. In most cases, a deployment does not involve provisioning, and provisioning does not necessarily need to be performed first. 【0250】 In some cases, there are two distinct challenges for IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before everything is operational. Second, once everything is provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges may be solved by allowing the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which and how they work together) can be described declaratively. In some examples, once the topology is defined, workflows can be generated to produce and / or manage the different components described in the configuration files. 【0251】 In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., a potentially on-demand pool of configurable and / or shared computing resources). In some examples, there may also be one or more inbound / outbound traffic groups and one or more virtual machines (VMs) provisioned to define how inbound and / or outbound traffic for the network is set up. Other infrastructure elements such as load balancers and databases may also be provisioned. As more infrastructure elements are desired and / or added, the infrastructure can evolve incrementally. 【0252】 In some examples, sequential deployment techniques may be employed to enable the deployment of infrastructure code across various virtual computing environments. In addition, the described techniques can enable infrastructure management within these environments. In some examples, a service team may write code that is to be deployed to one or more, but often many, different production environments (e.g., across various different geographical locations, sometimes even globally). However, in some examples, the infrastructure to which the code is deployed must first be set up. In some examples, provisioning may be done manually, provisioning tools may be used to provision resources, and / or deployment tools may be used to deploy the code once the infrastructure is provisioned. 【0253】 Figure 18 is a block diagram 1800 showing an exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1802 can be connected by communication to a secure host tenancy 1804 which may include a virtual cloud network (VCN) 1806 and a secure host subnet 1808. In some examples, the service operator 1802 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays) running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS®, Windows® Phone, Android®, BlackBerry® 8, Palm OS, and with the Internet, email, short message service (SMS), Blackberry®, or other communication protocols enabled. Alternatively, a client computing device can be a general-purpose personal computer, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. A client computing device can also be a workstation computer running any of various commercially available UNIX® or UNIX-like operating systems, including, without limitation, various GNU / Linux operating systems such as Google Chrome® OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer, an internet-connected gaming system (e.g., a Microsoft Xbox® gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, that can communicate over a network that can access VCN1806 and / or the Internet. 【0254】 VCN1806 may include a local peering gateway (LPG) 1810 that can communicate with Secure Shell (SSH) VCN1812 via LPG1810 included in SSH VCN1812. SSH VCN1812 may include an SSH subnet 1814, and SSH VCN1812 may communicate with control plane VCN1816 via LPG1810 included in control plane VCN1816. Furthermore, SSH VCN1812 may communicate with data plane VCN1818 via LPG1810. Control plane VCN1816 and data plane VCN1818 may be included in a service tenancy 1819 that can be owned and / or operated by an IaaS provider. 【0255】 Control plane VCN1816 may include a control plane demilitarized zone (DMZ) tier 1820 that functions as a perimeter network (e.g., the portion of the corporate network between the corporate intranet and the external network). DMZ-based servers may have limited responsibilities and may help contain breaches. In addition, DMZ tier 1820 may include a control plane application tier 1824 that may include one or more load balancer (LB) subnets 1822, application subnets 1826, and a control plane data tier 1828 that may include database (DB) subnets 1830 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 1822, included in the control plane DMZ tier 1820, can be communicated to the application subnet 1826, included in the control plane application tier 1824, and to the Internet gateway 1834, which may be included in the control plane VCN 1816. The application subnet 1826 can be communicated to the DB subnet 1830, the service gateway 1836, and the network address translation (NAT) gateway 1838, all included in the control plane data tier 1828. The control plane VCN 1816 may include the service gateway 1836 and the NAT gateway 1838. 【0256】 The control plane VCN1816 can include a data plane mirror app tier 840, which can include an app subnet 1826. The app subnet 1826 included in the data plane mirror app tier 1840 can include a virtual network interface controller (VNIC) 1842, which can run compute instance 1844. Compute instance 1844 can communicate and connect the app subnet 1826 of the data plane mirror app tier 1840 to an app subnet 1826 that can be included in the data plane app tier 1846. 【0257】 Data plane VCN1818 may include data plane application tier 1846, data plane DMZ tier 1848, and data plane data tier 1850. Data plane DMZ tier 1848 may include LB subnet 1822, which can be connected by communication to application subnet 1826 of data plane application tier 1846 and internet gateway 1834 of data plane VCN1818. Application subnet 1826 may be connected by communication to service gateway 1836 of data plane VCN1818 and NAT gateway 1838 of data plane VCN1818. Data plane data tier 1850 may also include DB subnet 1830, which can be connected by communication to application subnet 1826 of data plane application tier 1846. 【0258】 The Internet gateway 1834 of the control plane VCN1816 and data plane VCN1818 can be connected via communication to a metadata management service 1852, which can be connected via communication to the public internet 1854. The public internet 1854 can be connected via communication to the NAT gateway 1838 of the control plane VCN1816 and data plane VCN1818. The service gateway 1836 of the control plane VCN1816 and data plane VCN1818 can be connected via communication to a cloud service 1856. 【0259】 In some cases, a service gateway 1836 of the control plane VCN1816 or data plane VCN1818 can make application programming interface (API) calls to a cloud service 1856 without passing through the public internet 1854. API calls from the service gateway 1836 to the cloud service 1856 can be one-way. The service gateway 1836 can make API calls to the cloud service 1856, and the cloud service 1856 can send the requested data to the service gateway 1836. However, the cloud service 1856 does not have to initiate the API call to the service gateway 1836. 【0260】 In some examples, a secure host tenancy 1804 can be directly connected to a service tenancy 1819, which would otherwise be isolated. A secure host subnet 1808 can communicate with an SSH subnet 1814 via an LPG 1810, which can enable bidirectional communication on systems that would otherwise be isolated. Connecting the secure host subnet 1808 to the SSH subnet 1814 may give the secure host subnet 1808 access to other entities within the service tenancy 1819. 【0261】 The control plane VCN1816 may allow users of service tenancy 1819 to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN1816 may be deployed or otherwise used in the data plane VCN1818. In some examples, the control plane VCN1816 may be isolated from the data plane VCN1818, and the data plane mirror app tier 1840 of the control plane VCN1816 may communicate with the data plane app tier 1846 of the data plane VCN1818 via VNIC 1842, which may be included in the data plane mirror app tier 1840 and the data plane app tier 1846. 【0262】 In some examples, a system user or customer can make requests, such as create, read, update, or delete (CRUD) operations, through the public internet 1854, which can communicate requests to the metadata management service 1852. The metadata management service 1852 can communicate requests to the control plane VCN 1816 through the internet gateway 1834. Requests can be received by the LB subnet 1822, which is included in the control plane DMZ tier 1820. The LB subnet 1822 may determine that the request is valid, and in response to this determination, the LB subnet 1822 may send the request to the application subnet 1826, which is included in the control plane application tier 1824. Once the request is validated and requests a call to the public internet 1854, the call to the public internet 1854 may be sent to the NAT gateway 1838, which can then make the call to the public internet 1854. Metadata that may be desired to be stored by the request can be stored in the DB subnet 1830. 【0263】 In some cases, the data plane mirror app tier 1840 can facilitate direct communication between the control plane VCN1816 and the data plane VCN1818. For example, it may be desirable that configuration changes, updates, or other appropriate modifications be applied to resources contained in the data plane VCN1818. Through VNIC 1842, the control plane VCN1816 can communicate directly with the resources contained in the data plane VCN1818, thereby enabling it to perform configuration changes, updates, or other appropriate modifications on them. In some embodiments, the control plane VCN1816 and data plane VCN1818 may be included in the service tenancy 1819. In this case, the system user or customer may not own or operate either the control plane VCN1816 or the data plane VCN1818. Instead, the IaaS provider may own or operate the control plane VCN1816 and the data plane VCN1818, and both may be included in the service tenancy 1819. This embodiment can enable network isolation that can prevent a user or customer from interacting with resources of other users or other customers. This embodiment may also enable a system user or customer to store databases privately without having to rely on the public internet 1854, which may not have the desired level of threat protection for storage. 【0264】 In other embodiments, the LB subnet 1822 included in the control plane VCN 1816 may be configured to receive signals from the service gateway 1836. In this embodiment, the control plane VCN 1816 and the data plane VCN 1818 may be configured to be called by the IaaS provider's customer without calling the public internet 1854. The IaaS provider's customer may prefer this embodiment because the database used by the customer may be stored in a service tenancy 1819 which may be controlled by the IaaS provider and isolated from the public internet 1854. 【0265】 Figure 19 is a block diagram 1900 showing another exemplary pattern of IaaS architecture according to at least one embodiment. A service operator 1902 (e.g., service operator 1802 in Figure 18) can be connected by communication to a secure host tenancy 1904 (e.g., secure host tenancy 1804 in Figure 18) which can include a virtual cloud network (VCN) 1906 (e.g., VCN1806 in Figure 18) and a secure host subnet 1908 (e.g., secure host subnet 1808 in Figure 18). VCN1906 can include a local peering gateway (LPG) 1910 (e.g., LPG1810 in Figure 18) which can be connected by communication to a secure shell (SSH) VCN1912 (e.g., SSH VCN1812 in Figure 18) via an LPG 1810 contained within an SSH VCN1912. SSH VCN1912 may contain SSH subnet 1914 (e.g., SSH subnet 1814 in Figure 18), and SSH VCN1912 may be communicated to control plane VCN1916 (e.g., control plane VCN1816 in Figure 18) via LPG1910 contained within control plane VCN1916. Control plane VCN1916 may contain service tenancy 1919 (e.g., service tenancy 1819 in Figure 18), and data plane VCN1918 (e.g., data plane VCN1818 in Figure 18) may contain customer tenancy 1921, which may be owned or operated by a user or customer of the system. 【0266】 Control plane VCN1916 may include a control plane DMZ tier 1920 (e.g., control plane DMZ tier 1820 in Figure 18) which may include an LB subnet 1922 (e.g., LB subnet 1822 in Figure 18), a control plane app tier 1924 (e.g., control plane app tier 1824 in Figure 18) which may include an app subnet 1926 (e.g., app subnet 1826 in Figure 18), and a control plane data tier 1928 (e.g., control plane data tier 1828 in Figure 18) which may include a database (DB) subnet 1930 (e.g., similar to DB subnet 1830 in Figure 18). The LB subnet 1922, included in the control plane DMZ tier 1920, can be communicated to the application subnet 1926, included in the control plane application tier 1924, and to the Internet gateway 1934 (e.g., Internet gateway 1834 in Figure 18), which may be included in the control plane VCN 1916. The application subnet 1926 can be communicated to the DB subnet 1930, the service gateway 1936 (e.g., service gateway 1836 in Figure 18), and the network address translation (NAT) gateway 1938 (e.g., NAT gateway 1838 in Figure 18), all included in the control plane data tier 1928. The control plane VCN 1916 may include the service gateway 1936 and the NAT gateway 1938. 【0267】 The control plane VCN 1916 may include a data plane mirror app tier 1940 (e.g., data plane mirror app tier 1840 in Figure 18) which may include an app subnet 1926. The app subnet 1926 included in the data plane mirror app tier 1940 may include a virtual network interface controller (VNIC) 1942 (e.g., VNIC 1842) which may run a compute instance 1944 (e.g., similar to compute instance 1844 in Figure 18). The compute instance 1944 can facilitate communication between the app subnet 1926 of the data plane mirror app tier 1940 and the app subnet 1926 that may be included in the data plane app tier 1946 (e.g., data plane app tier 1846 in Figure 18) via the VNIC 1942 included in the data plane mirror app tier 1940 and the VNIC 1942 included in the data plane app tier 1946. 【0268】 The Internet gateway 1934 included in the control plane VCN1916 can communicate with the metadata management service 1952 (e.g., the metadata management service 1852 in Figure 18), which in turn can communicate with the public internet 1954 (e.g., the public internet 1854 in Figure 18). The public internet 1954 can communicate with the NAT gateway 1938 included in the control plane VCN1916. The service gateway 1936 included in the control plane VCN1916 can communicate with the cloud service 1956 (e.g., the cloud service 1856 in Figure 18). 【0269】 In some examples, the data plane VCN1918 may be included in customer tenancy 1921. In this case, the IaaS provider may provide a control plane VCN1916 for each customer, and the IaaS provider may set up a unique compute instance 1444 included in service tenancy 1919 for each customer. Each compute instance 1444 may enable communication between the control plane VCN1916 included in service tenancy 1919 and the data plane VCN1918 included in customer tenancy 1921. Compute instance 1444 allows resources provisioned in the control plane VCN1916 included in service tenancy 1919 to be deployed or otherwise used in the data plane VCN1918 included in customer tenancy 1921. 【0270】 In other examples, an IaaS provider's customer may have a database residing in customer tenancy 1921. In this example, control plane VCN 1916 may include a data plane mirror app tier 1940 that includes app subnet 1926. The data plane mirror app tier 1940 may reside in data plane VCN 1918, but does not have to reside in data plane VCN 1918. That is, the data plane mirror app tier 1940 may have access to customer tenancy 1921, but does not have to reside in data plane VCN 1918 or be owned or operated by an IaaS provider's customer. The data plane mirror app tier 1940 may be configured to make calls to data plane VCN 1918, but does not have to be configured to make calls to any entity included in control plane VCN 1916. Customers may want to deploy or otherwise use resources in the data plane VCN1918 that are provisioned in the control plane VCN1916, but the data plane mirror app tier 1940 can facilitate the customer's desired deployment or other use of resources. 【0271】 In some embodiments, a customer of the IaaS provider can apply filters to the data plane VCN1918. In this embodiment, the customer can determine which data plane VCN1918s are accessible, and the customer may restrict access from the data plane VCN1918 to the public internet 1954. The IaaS provider may not be able to apply filters or, if not, control access of the data plane VCN1918 to any external network or database. Applying filters and controls to the data plane VCN1918 included in the customer tenancy 1921 can help isolate the data plane VCN1918 from other customers and the public internet 1954. 【0272】 In some embodiments, a cloud service 1956 can be called by a service gateway 1936 to access services in the control plane VCN 1916 or data plane VCN 1918 that may not exist on the public internet 1954. The connection between the cloud service 1956 and the control plane VCN 1916 or data plane VCN 1918 may not be live or continuous. The cloud service 1956 may reside on different networks owned or operated by the IaaS provider. The cloud service 1956 may be configured to receive calls from the service gateway 1936 and not to receive calls from the public internet 1954. Some cloud services 1956 may be isolated from other cloud services 1956, and the control plane VCN 1916 may be isolated from cloud services 1956 that may not be in the same region as the control plane VCN 1916. For example, the control plane VCN 1916 may be located in "Region 1", and the cloud service "Deployment 18" may be located in Region 1 and "Region 2". When a call is made to deployment 18 by a service gateway 1936 included in control plane VCN1916 located in region 1, the call may be sent to deployment 18 in region 1. In this example, control plane VCN1916, or deployment 18 in region 1, does not have to be connected to deployment 18 in region 2 by communication, or it may communicate with deployment 18 in region 2. 【0273】 Figure 20 is a block diagram 2000 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 2002 (e.g., service operator 1802 in Figure 18) can be connected by communication to a secure host tenancy 2004 (e.g., secure host tenancy 1804 in Figure 18) which can include a virtual cloud network (VCN) 2006 (e.g., VCN1806 in Figure 18) and a secure host subnet 2008 (e.g., secure host subnet 1808 in Figure 18). VCN2006 can include an LPG2010 (e.g., LPG1810 in Figure 18) which can be connected by communication to an SSH VCN2012 (e.g., SSH VCN1812 in Figure 18) via an LPG2010 contained in an SSH VCN2012. SSH VCN2012 may contain SSH subnet 2014 (e.g., SSH subnet 1814 in Figure 18), and SSH VCN2012 may be connected by communication to control plane VCN2016 (e.g., control plane VCN1816 in Figure 18) via LPG2010 contained in control plane VCN2016, and to data plane VCN2018 (e.g., data plane 1818 in Figure 18) via LPG2010 contained in data plane VCN2018. Control plane VCN2016 and data plane VCN2018 may be contained in service tenancy 2019 (e.g., service tenancy 1819 in Figure 18). 【0274】 Control plane VCN2016 may include control plane DMZ tier 2020 (e.g., control plane DMZ tier 1820 in Figure 18) which may include load balancer (LB) subnet 2022 (e.g., LB subnet 1822 in Figure 18), control plane app tier 2024 (e.g., control plane app tier 1824 in Figure 18) which may include app subnet 2026 (e.g., similar to app subnet 1826 in Figure 18), and control plane data tier 2028 (e.g., control plane data tier 1828 in Figure 18) which may include DB subnet 2030. The LB subnet 2022, included in the control plane DMZ tier 2020, can be communicated to the application subnet 2026, included in the control plane application tier 2024, and to the internet gateway 2034 (e.g., internet gateway 1834 in Figure 18), which may be included in the control plane VCN 2016. The application subnet 2026 can be communicated to the DB subnet 2030, the service gateway 2036 (e.g., the service gateway in Figure 18), and the network address translation (NAT) gateway 2038 (e.g., NAT gateway 1838 in Figure 18), all included in the control plane data tier 2028. The control plane VCN 2016 may include the service gateway 2036 and the NAT gateway 2038. 【0275】 The data plane VCN2018 can include data plane app tier 2046 (e.g., data plane app tier 1846 in Figure 18), data plane DMZ tier 2048 (e.g., data plane DMZ tier 1848 in Figure 18), and data plane data tier 2050 (e.g., data plane data tier 1850 in Figure 18). The data plane DMZ tier 2048 may include LB subnet 2022, which can be communicated to trusted app subnet 2060 and untrusted app subnet 2062 of data plane app tier 2046, as well as Internet gateway 2034 included in data plane VCN2018. Trusted app subnet 2060 can be communicated to service gateway 2036 included in data plane VCN2018, NAT gateway 2038 included in data plane VCN2018, and DB subnet 2030 included in data plane data tier 2050. The untrusted application subnet 2062 can be connected via communication to service gateway 2036, which is included in data plane VCN2018, and to DB subnet 2030, which is included in data plane data tier 2050. Data plane data tier 2050 may include DB subnet 2030, which can be connected via communication to service gateway 2036, which is included in data plane VCN2018. 【0276】 The untrusted application subnet 2062 can include one or more primary VNICs 2064(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 2066(1)-(N). Each tenant VM 2066(1)-(N) can be communicatively coupled to respective application subnets 2067(1)-(N) that can be included in respective container egress VCNs 2068(1)-(N) that can be included in respective customer tenancies 2070(1)-(N). Each secondary VNIC 2072(1)-(N) can facilitate communication between the untrusted application subnet 2062 included in the data plane VCN 2018 and the application subnets included in the container egress VCNs 2068(1)-(N). Each container egress VCN 2068(1)-(N) can include a NAT gateway 2038 that can be communicatively coupled to the public Internet 2054 (e.g., the public Internet 1854 of FIG. 18). 【0277】 The Internet gateway 2034 included in the control plane VCN 2016 and the data plane VCN 2018 can be communicatively coupled to a metadata management service 2052 (e.g., the metadata management system 1852 of FIG. 18) that can be communicatively coupled to the public Internet 2054. The public Internet 2054 can be communicatively coupled to the NAT gateway 2038 included in the control plane VCN 2016 and the data plane VCN 2018. The service gateway 2036 included in the control plane VCN 2016 and the data plane VCN 2018 can be communicatively coupled to cloud services 2056. 【0278】 In some embodiments, the data plane VCN 2018 can be integrated with the customer tenancy 2070. This integration may be useful or desirable for customers of the IaaS provider in some cases, such as cases where support may be desired when running code. The customer may provide code for execution that can be disruptive, or may communicate with other customer resources, or may otherwise produce undesirable effects. In response, the IaaS provider may determine whether to execute the code provided to the IaaS provider by the customer. 【0279】 In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be attached to dataplane application tier 2046. The code for executing the functionality may run in VM2066(1)~(N), and the code may be configured not to run anywhere else on dataplane VCN2018. Each VM2066(1)~(N) may be connected to a single customer tenancy 2070. Each container 2071(1)~(N) contained within VM2066(1)~(N) may be configured to execute the code. In this case, dual isolation may exist (for example, containers 2071(1)~(N) that run the code, which may be contained in VM2066(1)~(N) that are contained in at least the untrusted app subnet 2062), which may help prevent erroneous or otherwise undesirable code from damaging the IaaS provider's network or the network of a different customer. Containers 2071(1)~(N) may be coupled to customer tenancy 2070 by communication and may be configured to send or receive data from customer tenancy 2070. Containers 2071(1)~(N) may not be configured to send or receive data from any other entity in the data plane VCN2018. Once the execution of the code is complete, the IaaS provider may kill or otherwise discard containers 2071(1)~(N). 【0280】 In some embodiments, a trusted application subnet 2060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 2060 may be liaison-bound to a DB subnet 2030 and configured to perform CRUD operations in the DB subnet 2030. An untrusted application subnet 2062 may be liaison-bound to a DB subnet 2030, but in this embodiment, the untrusted application subnet may be configured to perform read operations in the DB subnet 2030. Containers 2071(1)-(N), which may be contained in each customer's VM2066(1)-(N) and may execute code from the customer, do not have to be liaison-bound to the DB subnet 2030. 【0281】 In other embodiments, the control plane VCN2016 and the data plane VCN2018 do not have to be directly connected by communication. In this embodiment, direct communication between the control plane VCN2016 and the data plane VCN2018 is not required. However, communication can be performed indirectly through at least one method. An LPG2010 may be established by the IaaS provider, which can facilitate communication between the control plane VCN2016 and the data plane VCN2018. In another example, the control plane VCN2016 or the data plane VCN2018 can make a call to the cloud service 2056 via the service gateway 2036. For example, a call from the control plane VCN2016 to the cloud service 2056 may include a request for a service that can communicate with the data plane VCN2018. 【0282】 Figure 21 is a block diagram 2100 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 2102 (e.g., service operator 1802 in Figure 18) can be connected by communication to a secure host tenancy 2104 (e.g., secure host tenancy 1804 in Figure 18) which can include a virtual cloud network (VCN) 2106 (e.g., VCN1806 in Figure 18) and a secure host subnet 2108 (e.g., secure host subnet 1808 in Figure 18). VCN2106 can include an LPG2110 (e.g., LPG1810 in Figure 18) which can be connected by communication to SSH VCN2112 (e.g., SSH VCN1812 in Figure 18) via an LPG2110 contained in SSH VCN2112. SSH VCN2112 may include SSH subnet 2114 (for example, SSH subnet 1814 in Figure 18), and SSH VCN2112 may be connected by communication to control plane VCN2116 (for example, control plane VCN1816 in Figure 18) via LPG2110 included in control plane VCN2116, and to data plane VCN2118 (for example, data plane VCN1818 in Figure 18) via LPG2110 included in data plane VCN2118. Control plane VCN2116 and data plane VCN2118 may be included in service tenancy 2119 (for example, service tenancy 1819 in Figure 18). 【0283】 The control plane VCN2116 may include a control plane DMZ tier 2120 (e.g., control plane DMZ tier 1820 in Figure 18) which may include an LB subnet 2122 (e.g., LB subnet 1822 in Figure 18), a control plane application tier 2124 (e.g., control plane application tier 1824 in Figure 18) which may include an application subnet 2126 (e.g., application subnet 1826 in Figure 18), and a control plane data tier 2128 (e.g., control plane data tier 1828 in Figure 18) which may include a DB subnet 2130 (e.g., DB subnet 2030 in Figure 20). The LB subnet 2122, included in the control plane DMZ tier 2120, can be communicated to the application subnet 2126, included in the control plane application tier 2124, and to the Internet gateway 2134 (e.g., Internet gateway 1834 in Figure 18), which may be included in the control plane VCN 2116. The application subnet 2126 can be communicated to the DB subnet 2130, the service gateway 2136 (e.g., the service gateway in Figure 18), and the network address translation (NAT) gateway 2138 (e.g., NAT gateway 1838 in Figure 18), included in the control plane data tier 2128. The control plane VCN 2116 may include the service gateway 2136 and the NAT gateway 2138. 【0284】 The data plane VCN2118 may include data plane application tier 2146 (e.g., data plane application tier 1846 in Figure 18), data plane DMZ tier 2148 (e.g., data plane DMZ tier 1848 in Figure 18), and data plane data tier 2150 (e.g., data plane data tier 1850 in Figure 18). The data plane DMZ tier 2148 may include trusted application subnet 2160 (e.g., trusted application subnet 2060 in Figure 20) and untrusted application subnet 2162 (e.g., untrusted application subnet 2062 in Figure 20) of data plane application tier 2146, as well as an LB subnet 2122 that can be connected by communication to the internet gateway 2134 included in the data plane VCN2118. Trusted application subnet 2160 can be connected via communication to service gateway 2136 included in data plane VCN2118, NAT gateway 2138 included in data plane VCN2118, and DB subnet 2130 included in data plane data tier 2150. Untrusted application subnet 2162 can be connected via communication to service gateway 2136 included in data plane VCN2118 and DB subnet 2130 included in data plane data tier 2150. Data plane data tier 2150 may include DB subnet 2130 that can be connected via communication to service gateway 2136 included in data plane VCN2118. 【0285】 An untrusted application subnet 2162 may include primary VNICs 2164(1)-(N) that can communicate with tenant virtual machines (VMs) 2166(1)-(N) residing within the untrusted application subnet 2162. Each tenant VM 2166(1)-(N) can execute code in its respective container 2167(1)-(N) and can communicate with application subnet 2126 that can be included in a dataplane application tier 2146 that can be included in a container egress VCN 2168. Each secondary VNIC 2172(1)-(N) can facilitate communication between the untrusted application subnet 2162 included in the dataplane VCN 2118 and the application subnet included in the container egress VCN 2168. The container egress VCN may include a NAT gateway 2138 that can communicate with the public internet 2154 (e.g., public internet 1854 in Figure 18). 【0286】 The Internet gateway 2134 included in the control plane VCN2116 and data plane VCN2118 can be connected via communication to a metadata management service 2152 (for example, metadata management service 1852 in Figure 18), which can be connected via communication to the public internet 2154. The public internet 2154 can be connected via communication to a NAT gateway 2138 included in the control plane VCN2116 and data plane VCN2118. The service gateway 2136 included in the control plane VCN2116 and data plane VCN2118 can be connected via communication to a cloud service 2156. 【0287】 In some examples, the pattern shown by the architecture of block diagram 2100 in Figure 21 may be considered an exception to the pattern shown by the architecture of block diagram 2000 in Figure 20, and may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customers (e.g., disconnected regions). Each container 2167(1)~(N) contained within VM2166(1)~(N) for each customer can be accessed by the customer in real time. Each container 2167(1)~(N) may be configured to make calls to each secondary VNIC 2172(1)~(N) contained within application subnet 2126 of data plane application tier 2146, which can be contained within container egress VCN2168. The secondary VNICs 2172(1)~(N) can make calls to a NAT gateway 2138 which may send calls to the public internet 2154. In this example, containers 2167(1)-(N), which can be accessed in real time by customers, can be isolated from the control plane VCN2116 and from other entities included in the data plane VCN2118. Containers 2167(1)-(N) may also be isolated from resources from other customers. 【0288】 In another example, the customer can use containers 2167(1)-(N) to call cloud service 2156. In this example, the customer may execute code in containers 2167(1)-(N) to request a service from cloud service 2156. Containers 2167(1)-(N) can send this request to secondary VNICs 2172(1)-(N), which can send the request to the NAT gateway, which can send the request to the public internet 2154. The public internet 2154 can send the request to LB subnet 2122, which is included in control plane VCN 2116, via internet gateway 2134. In response to the decision that the request is valid, the LB subnet can send the request to application subnet 2126, which can send the request to cloud service 2156 via service gateway 2136. 【0289】 It should be acknowledged that the illustrated IaaS architectures 1800, 1900, 2000, and 2100 may have components other than those shown. Furthermore, the illustrated embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of the disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown, may combine two or more components, or may have different configurations or arrangements of components. 【0290】 In one embodiment, the IaaS system described herein may include a suite of applications, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) provided by the Assignee. 【0291】 Figure 22 shows an exemplary computer system 2200 in which various embodiments may be implemented. System 2200 may be used to implement any of the computer systems described above. As shown, computer system 2200 includes a processing unit 2204 that communicates with a number of peripheral subsystems via a bus subsystem 2202. These peripheral subsystems may include a processing acceleration unit 2206, a processing acceleration unit 2208, a storage subsystem 2218, and a communication subsystem 2224. The storage subsystem 2218 includes a tangible computer-readable storage medium 2222 and system memory 2210. 【0292】 The bus subsystem 2202 provides a mechanism for various components and subsystems of the computer system 2200 to communicate with each other as intended. Although the bus subsystem 2202 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 2202 may be one of several types of bus structures, including a memory bus or memory controller, peripheral bus, and local bus, using any of the various bus architectures. For example, such architectures may include industry standard architecture (ISA) buses, microchannel architecture (MCA) buses, enhanced ISA (EISA) buses, video electronics standards association (VESA) local buses, and peripheral component interconnect (PCI) buses, which can be implemented as mezzanine buses manufactured in accordance with the IEEE P 1386.1 standard. 【0293】 A processing unit 2204, which can be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 2200. One or more processors may be included in the processing unit 2204. These processors may include single-core or multi-core processors. In one embodiment, the processing unit 2204 may be implemented as one or more independent processing units 2232 and / or 2234, each having a single-core or multi-core processor included in its respective processing unit. In other embodiments, the processing unit 2204 may be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip. 【0294】 In various embodiments, the processing unit 2204 can execute various programs in response to program code and can maintain a large number of programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in the processor 2204 and / or the memory subsystem 2218. With appropriate programming, the processor 2204 can provide the various functions described above. The computer system 2200 may also include a processing acceleration unit 2206 which may include a digital signal processor (DSP), a dedicated processor, and / or similar. 【0295】 The processing acceleration unit 2208 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors, which enable users to control and interact with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gestures and voice commands. User interface input devices may also include eye gesture recognition devices such as Google Glass® blink detectors, which detect eye movements from the user (e.g., blinks when taking photos and / or selecting menus) and translate eye gestures as input to an input device (e.g., Google Glass®). In addition, the user interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands. 【0296】 User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, and audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and gaze detection devices. In addition, user interface input devices may include, for example, medical image input devices such as computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound devices. User interface input devices may also include, for example, audio input devices such as MIDI keyboards and digital musical instruments. 【0297】 User interface output devices may include display subsystems, indicator lights, or non-visual displays, such as audio output devices. Display subsystems may include cathode ray tubes (CRTs), flat panel devices, such as flat panel devices using liquid crystal displays (LCDs) or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 2200 to a user or another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphic, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems. 【0298】 The computer system 2200 may include a memory subsystem 2218 that provides a tangible non-transitory computer-readable storage medium for storing software and data structures that provide the functionality of the embodiments described in this disclosure. The software can include programs, code modules, instructions, scripts, etc. that, when executed by one or more cores or processors of the processing unit 2204, provide the functionality described above. The memory subsystem 2218 may also provide a repository for storing data used in accordance with this disclosure. 【0299】 As shown in the example in FIG. 22, the memory subsystem 2218 can include various components including a system memory 2210, a computer-readable storage medium 2222, and a computer-readable storage medium reader 2220. The system memory 2210 may store program instructions loadable and executable by the processing unit 2204. The system memory 2210 may store data used during the execution of the instructions and / or data generated during the execution of the program instructions. Various different types of programs may be loaded into the system memory 2210 including, but not limited to, client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, etc. 【0300】 System memory 2210 may store an operating system 2216. Examples of operating systems 2216 may include various versions of the Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems, such as iOS®, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems. In one implementation in which the computer system 2200 runs one or more virtual machines, a virtual machine with a guest operating system (GOS) may be loaded into system memory 2210 and executed by one or more processors or cores of the processing unit 2204. 【0301】 The system memory 2210 may be provided in different configurations depending on the type of computer system 2200. For example, the system memory 2210 may be volatile memory (e.g., random access memory (RAM)) and / or non-volatile memory (e.g., read-only memory (ROM), flash memory, etc.). Different types of RAM configurations may be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), and others. In some implementations, the system memory 2210 may include a basic input / output system (BIOS) containing basic routines that help communicate information between elements within the computer system 2200, such as during startup. 【0302】 The computer-readable storage medium 2222 may represent remote, local, fixed, and / or removable storage devices and storage media for temporarily and / or more permanently storing computer-readable information for use by the computer system 2200, including instructions executable by the processing unit 2204 of the computer system 2200. 【0303】 The computer-readable storage medium 2222 may include any suitable medium known or used in the art, including, but not limited to, volatile and non-volatile, removable and non-removable storage and communication media, which are implemented in any way or technique for storing and / or transmitting information. This may include tangible computer-readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. 【0304】 For example, the computer-readable storage medium 2222 may include hard disk drives that read from or write to non-removable, non-volatile magnetic media; magnetic disk drives that read from or write to removable, non-volatile magnetic disks; and optical disk drives that read from or write to removable, non-volatile optical disks or other optical media, such as CD-ROMs, DVDs, and Blu-Ray® discs. The computer-readable storage medium 2222 may also include, but are not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital videotapes, and the like. The computer-readable storage medium 2222 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, and solid-state ROMs; SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, and magnetoresistive RAM (MRAM) SSDs; and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media may provide non-volatile storage for computer-readable instructions, data structures, program modules, and other data for the computer system 2200. 【0305】 Machine-readable instructions executable by one or more processors or cores of the processing unit 2204 may be stored in a non-temporary computer-readable storage medium. The non-temporary computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile storage devices. Examples of non-temporary computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard drives, floppy disk drives, removable memory drives (e.g., USB drives), or other types of storage devices. 【0306】 The communication subsystem 2224 provides interfaces to other computer systems and networks. It acts as an interface for receiving data from other systems and transmitting data from computer system 2200 to other systems. For example, the communication subsystem 2224 may enable computer system 2200 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 2224 may include radio frequency (RF) transceiver components for accessing radio voice and / or data networks (using, for example, cellular technology, 3G, 4G, or EDGE (Enhanced Data Rate for Global Evolution), advanced data network technologies, WiFi® (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), Global Positioning System (GPS) receiver components, and / or other components). In some embodiments, the communication subsystem 2224 may provide wired network connectivity (e.g., Ethernet®) in addition to or instead of the radio interface. 【0307】 In some embodiments, the communication subsystem 2224 may receive input communications on behalf of one or more users, who may use the computer system 2200, in the form of structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, and so on. 【0308】 For example, the communication subsystem 2224 may be configured to receive data feeds 2226 in real time from users of social networks and / or other communication services, such as web feeds including Twitter® feeds, Facebook® updates, rich site summary (RSS) feeds, and / or real-time updates from one or more third-party information sources. 【0309】 In addition, the communication subsystem 2224 may be configured to receive data in the form of a continuous data stream, which may include an event stream 2228 and / or event updates 2230 of real-time events, which may be continuous or inherently unlimited with no clear end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring. 【0310】 The communication subsystem 2224 may be configured to output structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, etc., to one or more databases which may communicate with one or more streaming data source computers coupled to the computer system 2200. 【0311】 The computer system 2200 can be one of a variety of types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems. 【0312】 Due to the constantly changing nature of computers and networks, the description of the illustrated computer system 2200 is intended only as a specific example. Many other configurations are possible, having more or fewer components than the illustrated system. For example, customized hardware may be used and / or certain elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosures and teachings provided herein, those skilled in the art will recognize other ways and / or methods for carrying out various embodiments. 【0313】 Embodiments may be implemented by using a computer program product that, when executed by a processor, includes a computer program / instruction that causes the processor to perform one of the methods described in the disclosure. 【0314】 While specific embodiments are described, various modifications, changes, alternative configurations, and equivalents are also included in the scope of the disclosure. The embodiments are not limited to operations within a particular data processing environment, but are freely operable within multiple data processing environments. While the embodiments are described using a specific sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of this disclosure is not limited to the described sequence of transactions and steps. The various features and aspects of the embodiments described above may be used individually or in combination. 【0315】 Furthermore, while embodiments are described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments may be implemented using hardware only, software only, or a combination thereof. Various processes described herein can be implemented on the same processor or on different processors in any combination. Thus, where a component or service is described as being configured to perform a certain operation, such configuration can be achieved, for example, by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as a microprocessor) to perform the operation, or by any combination thereof. Processes may communicate using a variety of techniques, including but not limited to prior art for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different points in time. 【0316】 Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will become clear that additions, reductions, deletions, and other modifications and changes can be made to them without departing from the broader intent and scope set forth in the claims. Thus, while certain disclosed embodiments are described, they are not intended to be restrictive. Various modifications and equivalents fall within the scope of the following claims. 【0317】 In the context describing the disclosed embodiments (in particular in the context of the following claims), the use of the terms “a,” “an,” and “the,” and similar referents, should be interpreted as covering both singular and plural forms unless otherwise indicated herein or unless clearly contradicted by the context. The terms “comprising,” “having,” “including,” and “containing” should be interpreted as unrestricted terms (i.e., “including, but not limited to”) unless otherwise noted. The term “connected” should be interpreted as being partially or entirely contained, attached, or joined within, even if something intervenes. The enumeration of value ranges herein is intended to serve merely as a concise way of referring to each distinct value contained within that range unless otherwise indicated herein, and each distinct value is incorporated into the specification as individually enumerated herein. All methods described herein can be performed in any appropriate order unless otherwise indicated herein or unless clearly contradicted by the context. The use of any and all examples or exemplary language (e.g., "etc.") provided herein is intended merely to further illustrate the embodiments and does not impose any limitation on the scope of the disclosure unless otherwise requested. The language in the specification should not be construed as indicating any unrequested element as essential for the performance of the disclosure. 【0318】 Disjunctive language, such as the expression "at least one of X, Y, or Z," is intended to be understood in context as commonly used to indicate that an item, term, etc., may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise stated. Therefore, such disjunctive language is generally not intended, nor should it be, to imply that a particular embodiment requires the presence of at least one of X, at least one of Y, or at least one of Z. 【0319】 Preferred embodiments of the Disclosure, including the best known mode for carrying out the Disclosure, are described herein. Variations of these preferred embodiments may become apparent to those skilled in the art by reading the foregoing description. Those skilled in the art should be able to adopt such variations as needed, and the Disclosure may be carried out in forms other than those specifically described herein. Accordingly, the Disclosure includes all modifications and equivalents of the subject matter enumerated in the attached claims, as permitted by applicable law. Furthermore, all combinations of the elements described above in all possible variations thereof are encompassed by the Disclosure unless otherwise indicated herein. 【0320】 Exemplary embodiments of the disclosure may be described in consideration of the following clauses: Article 1 A method by which a computer can perform actions ("Method") is disclosed. The Method may include obtaining a service plan by a cloud infrastructure orchestration system that defines a first sequence for executing one or more releases as part of a first process for bootstrapping services within a cloud computing environment. The Method may include obtaining a manifest by a cloud infrastructure orchestration service that identifies configuration files defining operations associated with executing one or more releases. The Method may include generating a directed acyclic graph by the cloud infrastructure orchestration service, at least in part, based on a plurality of service plans, including the service plan. In some embodiments, the directed acyclic graph defines a second sequence for executing a set of releases, including the release. The set of releases may be associated with a second process for bootstrapping a plurality of services within a cloud computing environment. The Method may include executing a subset of the releases of the set of releases associated with the second process for bootstrapping a plurality of services within a cloud computing environment by the cloud infrastructure orchestration service. The subset of releases may be executed in the second sequence, at least in part, based on traversing the directed acyclic graph. 【0321】 Article 2 The method performed by the computer described in Clause 1 further includes verifying the service plan based at least in part on the manifest by the Cloud Infrastructure Orchestration Service. 【0322】 Article 3 A method performed by a computer as described in Clause 1 or Clause 2 to validate a service plan based at least in part on a manifest further includes: 1) obtaining static flock analysis data by the Cloud Infrastructure Orchestration Service corresponding to the configuration files identified by the manifest, the static flock analysis indicating a first set of dependencies; 2) determining a second set of dependencies by the Cloud Infrastructure Orchestration Service based at least in part on the service plan; and 3) determining by the Cloud Infrastructure Orchestration Service that the first set of dependencies matches the second set of dependencies. 【0323】 Article 4 A method performed by the computer described in any of Clauses 1 to 3, further including determining that the service plan is consistent, at least in part, on the basis of determining that the Cloud Infrastructure Orchestration Service determines that the first data corresponding to the first component of the service plan matches the second data corresponding to the second component of the service plan. 【0324】 Article 5 A method performed by a computer as described in any of Clauses 1 to 4, further comprising: 1) by the Cloud Infrastructure Orchestration Service, determining that multiple service plans are compatible, i) generating a directed graph at least in part on multiple service plans and ii) determining that the directed graph lacks cycles at least in part on determining that multiple service plans are compatible; 2) by the Cloud Infrastructure Orchestration Service, adding a service plan to a set of service plans containing multiple service plans and the service plan containing that service plan; and 3) by the Cloud Infrastructure Orchestration Service, extracting a version set that identifies multiple configuration files in order to be in the middle of a second process for bootstrapping multiple services within a cloud computing environment. In some embodiments, the version set may be extracted at least in part on a set of service plans. 【0325】 Article 6 A method performed by a computer as described in any of Clauses 1 to 5, wherein a version set includes multiple version set items, the first of which is associated with a corresponding service plan, and the second of which is unrelated to any service plan. 【0326】 Article 7 A method performed by the computer described in any of Clauses 1 to 6, further comprising determining that multiple service plans are compatible based at least in part on the absence of replication capability publications between the multiple service plans by the Cloud Infrastructure Orchestration Service. 【0327】 Article 8 A cloud infrastructure orchestration system ("System") is disclosed. The System may include one or more processors and one or more memories that store computer executable instructions that, when executed by one or more processors, cause one or more processors to perform an operation. An operation may include obtaining a service plan that defines a first sequence for executing one or more releases as part of a first process for bootstrapping a service in a cloud computing environment. An operation may include obtaining a manifest that identifies a configuration file that defines an operation associated with executing one or more releases. An operation may include generating a directed acyclic graph at least in part on a plurality of service plans, including a service plan, the directed acyclic graph defining a second sequence for executing a set of releases, the set of releases, which is associated with a second process for bootstrapping a plurality of services in a cloud computing environment. An operation may include executing a subset of releases of the set of releases associated with the second process for bootstrapping a plurality of services in a cloud computing environment. In some embodiments, the subset of releases may be executed in a second sequence at least in part on traversing a directed acyclic graph. 【0328】 Article 9 The cloud infrastructure orchestration system described in Clause 8, which executes computer executable instructions, causes one or more processors to verify the service plan based at least in part on the manifest. 【0329】 Clause 10 A cloud infrastructure orchestration system as described in Clause 8 or Clause 9, which validates a service plan at least in part on a manifest, further includes: 1) the cloud infrastructure orchestration service obtaining static flock analysis data corresponding to configuration files identified by the manifest, the static flock analysis indicating a first set of dependencies; 2) the cloud infrastructure orchestration service determining a second set of dependencies at least in part on the service plan; and 3) the cloud infrastructure orchestration service determining that the first set of dependencies matches the second set of dependencies. 【0330】 Article 11 A cloud infrastructure orchestration system as described in any of Clauses 8 to 10, which executes computer executable instructions, further causes one or more processors to determine that a service plan is consistent, at least in part, on the basis of determining that first data corresponding to a first component of a service plan matches second data corresponding to a second component of a service plan. 【0331】 Article 12 A cloud infrastructure orchestration system as described in any of Clauses 8 to 11, wherein executing computer executable instructions further includes, to one or more processors, 1) i) generating a directed graph at least in part on a set of service plans and 2) determining that the directed graph lacks cycles, determining that the set of service plans are compatible, 2) adding a service plan to a set of service plans containing the set of service plans, at least in part on determining that the set of service plans are compatible, and 3) extracting a set of versions that identify a set of configuration files to be in the middle of a second process for bootstrapping a set of services within a cloud computing environment, the set of versions being extracted at least in part on a set of service plans. 【0332】 Article 13 A cloud infrastructure orchestration system as described in any of Clauses 8 to 12, wherein a version set includes multiple version set items, the first of which is associated with a corresponding service plan, and the second of which is unrelated to any service plan. 【0333】 Article 14 A cloud infrastructure orchestration system as described in any of Clauses 8 to 13, wherein executing computer executable instructions causes one or more processors to determine that multiple service plans are compatible, at least in part, on the basis of determining that no replication capability publications exist between the multiple service plans. 【0334】 Article 15 Non-temporary computer-readable media is disclosed. The non-temporary computer-readable media may store computer-executable instructions that, when executed by one or more processors of the cloud infrastructure orchestration system, cause one or more processors of the cloud infrastructure orchestration system to perform an operation. The operation may include obtaining a service plan that defines a first sequence for executing one or more releases as part of a first process for bootstrapping services within a cloud computing environment. The operation may include obtaining a manifest that identifies a configuration file that defines an operation associated with executing one or more releases. The operation may include generating a directed acyclic graph at least in part on a plurality of service plans, including the service plan, the directed acyclic graph defining a second sequence for executing a set of releases, including the release, the set of releases associated with a second process for bootstrapping multiple services within a cloud computing environment. The operation may include executing a subset of releases of the set of releases associated with the second process for bootstrapping multiple services within a cloud computing environment. In some embodiments, a subset of releases may be performed in a second order, at least partially based on traversing a directed acyclic graph. 【0335】 Article 16 The non-temporary computer-readable medium described in Clause 15, which includes computer-executable instructions, further causes one or more processors to verify a service plan based at least in part on the manifest. 【0336】 Article 17 Verifying a service plan based at least in part on a manifest using a non-temporary computer-readable medium as described in Clause 15 or Clause 16 further includes: 1) obtaining static flock analysis data by the Cloud Infrastructure Orchestration Service corresponding to configuration files identified by the manifest, the static flock analysis indicating a first set of dependencies; 2) determining a second set of dependencies by the Cloud Infrastructure Orchestration Service based at least in part on the service plan; and 3) determining that the first set of dependencies matches the second set of dependencies. 【0337】 Article 18 Executing a computer executable instruction in a non-temporary computer-readable medium as described in any of Clauses 15 to 17 further causes one or more processors to determine that the service plan is consistent, at least in part, on the basis of determining that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. 【0338】 Article 19 Executing a computer executable instruction in a non-temporary computer-readable medium as described in any of Clauses 8 to 11 further includes, to one or more processors, 1) i) generating a directed graph at least in part on a plurality of service plans and 2) determining that the directed graph lacks cycles, that the plurality of service plans are compatible, 2) adding a service plan to the plurality of service plans and a set of service plans containing that service plan, at least in part on determining that the plurality of service plans are compatible, and 3) extracting a version set that identifies a plurality of configuration files to be in the middle of a second process for bootstrapping a plurality of services within a cloud computing environment. In some embodiments, the version set may be extracted at least in part on a set of service plans, and the version set includes a plurality of version set items, the first version set item of the plurality of version set items being associated with a corresponding service plan, and the second version set item of the plurality of version set items being unrelated to any service plan. 【0339】 Article 20 A non-temporary computer-readable medium as described in any of Clauses 15 to 19, wherein executing a computer-executable instruction causes one or more processors to determine that multiple service plans are compatible, at least in part, based on determining that no replication capability publications exist between the multiple service plans. 【0340】 All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as each reference is individually and specifically indicated to be incorporated by reference and shown herein in whole. 【0341】 While the aspects of disclosure described in the above specification are described in relation to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the above disclosure may be used individually or in combination. Furthermore, the embodiments may be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be considered illustrative rather than restrictive.

Claims

[Claim 1] A method by which a computer performs an action. The cloud infrastructure orchestration system obtains a service plan that defines a first sequence for executing one or more releases as part of a first process for bootstrapping services within a cloud computing environment, The cloud infrastructure orchestration service obtains a manifest that identifies a configuration file that defines the operations associated with executing the release of one or more of the aforementioned releases, The cloud infrastructure orchestration service generates a directed acyclic graph based at least partially on multiple service plans, including the service plan, Includes, The directed acyclic graph defines a second sequence for executing a set of releases, including the release, and the set of releases is associated with a second process for bootstrapping the multiple services within the cloud computing environment. The method that the aforementioned computer will perform is: The cloud infrastructure orchestration service executes a subset of the set of releases associated with the second process of bootstrapping the multiple services within the cloud computing environment. It further includes, A computer method in which a subset of the releases is performed in the second order, at least in part, based on traversing the directed acyclic graph. [Claim 2] The method performed by a computer according to claim 1, further comprising verifying the service plan based at least in part on the manifest using the cloud infrastructure orchestration service. [Claim 3] Verifying the service plan based at least partially on the aforementioned manifest is, The cloud infrastructure orchestration service further includes obtaining static flock analysis data corresponding to the configuration file identified by the manifest, wherein the static flock analysis reveals a first set of dependencies. The cloud infrastructure orchestration service determines a second set of dependencies based at least partially on the service plan, The cloud infrastructure orchestration service determines that the first set of dependencies matches the second set of dependencies, A method performed by a computer according to claim 1 or claim 2, further comprising: [Claim 4] A computer method according to any one of claims 1 to 3, further comprising determining that the service plan is consistent, at least in part, on the basis that the cloud infrastructure orchestration service determines that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. [Claim 5] The cloud infrastructure orchestration service determines that the multiple service plans are compatible, based at least partially on 1) generating a directed graph based at least partially on 2) determining that the directed graph lacks cycles. Based at least in part on determining that the multiple service plans are compatible, the Cloud Infrastructure Orchestration Service adds the service plan to the multiple service plans and the set of service plans including the service plan, The cloud infrastructure orchestration service extracts a version set that identifies multiple configuration files in order to be in the second process of bootstrapping the multiple services within the cloud computing environment, It further includes, A method performed by a computer according to any one of claims 1 to 4, wherein the version set is derived at least in part from the set of service plans. [Claim 6] A method performed by a computer according to any one of claims 1 to 5, wherein the version set includes a plurality of version set items, the first version set item of the plurality of version set items is associated with a corresponding service plan, and the second version set item of the plurality of version set items lacks any service plan association. [Claim 7] A computer method according to any one of claims 1 to 6, further comprising determining that the plurality of service plans are compatible, at least in part on the determination by the cloud infrastructure orchestration service that no replication capability publications exist between the plurality of service plans. [Claim 8] A cloud infrastructure orchestration system, One or more processors, When executed by the one or more processors, the one or more processors will Obtain a service plan that defines a first sequence for executing one or more releases as part of the first process of bootstrapping a service within a cloud computing environment. Obtain a manifest that identifies a configuration file that defines the operations associated with performing the release of one or more of the aforementioned releases, A directed acyclic graph is generated based at least partially on multiple service plans, including the aforementioned service plan, the directed acyclic graph defines a second sequence for executing a set of releases, including the aforementioned release, and the set of releases is associated with a second process for bootstrapping multiple services within the cloud computing environment. The second process for bootstrapping the multiple services within the cloud computing environment is associated with executing a subset of the releases of the set of releases, the subset of releases being executed in the second order, at least in part on traversing the directed acyclic graph. One or more memory locations for storing computer executable instructions, A cloud infrastructure orchestration system, including [specific feature / feature]. [Claim 9] The cloud infrastructure orchestration system according to claim 8, wherein executing the computer executable instructions further causes one or more processors to verify the service plan based at least in part on the manifest. [Claim 10] Verifying the service plan based at least partially on the aforementioned manifest is, The cloud infrastructure orchestration service further includes obtaining static flock analysis data corresponding to the configuration file identified by the manifest, wherein the static flock analysis reveals a first set of dependencies. The cloud infrastructure orchestration service determines a second set of dependencies based at least partially on the service plan, The cloud infrastructure orchestration service determines that the first set of dependencies matches the second set of dependencies, A cloud infrastructure orchestration system according to claim 8 or 9, further comprising: [Claim 11] The cloud infrastructure orchestration system according to any one of claims 8 to 10, wherein executing the computer executable instructions further causes one or more processors to determine that the service plan is consistent, at least in part on determining that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. [Claim 12] Executing the aforementioned computer executable instruction further involves one or more processors: 1) generating a directed graph based at least partially on the multiple service plans, and 2) determining at least partially on determining that the directed graph lacks cycles, the multiple service plans are determined to be compatible. Based at least in part on determining that the multiple service plans are compatible, the service plan is added to the set of service plans that includes the multiple service plans and the service plan containing the service plan. A cloud infrastructure orchestration system according to any one of claims 8 to 11, wherein a version set identifying a plurality of configuration files is retrieved in the second process of bootstrapping the plurality of services within the cloud computing environment, the version set being retrieved at least in part on a set of service plans. [Claim 13] The cloud infrastructure orchestration system according to any one of claims 8 to 12, wherein the version set comprises a plurality of version set items, the first version set item of which is associated with a corresponding service plan, and the second version set item of which is unrelated to any service plan. [Claim 14] The cloud infrastructure orchestration system according to any one of claims 8 to 13, wherein executing the computer executable instructions further causes one or more processors to determine that the service plans are compatible, at least in part on determining that no replication capability publications exist between the service plans. [Claim 15] When executed by one or more processors of the cloud infrastructure orchestration system, the one or more processors of the cloud infrastructure orchestration system, Obtain a service plan that defines a first sequence for executing one or more releases as part of the first process of bootstrapping a service within a cloud computing environment. Obtain a manifest that identifies a configuration file that defines the operations associated with performing the release of one or more of the aforementioned releases, A directed acyclic graph is generated based at least partially on multiple service plans, including the aforementioned service plan, the directed acyclic graph defines a second sequence for executing a set of releases, including the aforementioned release, and the set of releases is associated with a second process for bootstrapping multiple services within the cloud computing environment. A non-temporary computer-readable medium storing computer-executable instructions, which causes a subset of releases of the set of releases to run, associated with the second process of bootstrapping the plurality of services within the cloud computing environment, the subset of releases being executed in the second order, at least in part on traversing the directed acyclic graph. [Claim 16] The non-temporary computer-readable medium according to claim 15, wherein executing the computer-executable instructions further causes one or more processors to verify the service plan based at least in part on the manifest. [Claim 17] Verifying the service plan based at least partially on the aforementioned manifest is, The cloud infrastructure orchestration service further includes obtaining static flock analysis data corresponding to the configuration file identified by the manifest, wherein the static flock analysis reveals a first set of dependencies. The cloud infrastructure orchestration service determines a second set of dependencies based at least partially on the service plan, The non-temporary computer-readable medium according to claim 15 or 16, further comprising determining, by the cloud infrastructure orchestration service, that the first set of dependencies matches the second set of dependencies. [Claim 18] The non-temporary computer-readable medium according to any one of claims 15 to 17, wherein executing the computer-executable instruction further causes one or more processors to determine that the service plan is consistent, at least in part, on the basis of determining that first data corresponding to a first component of the service plan matches second data corresponding to a second component of the service plan. [Claim 19] Executing the aforementioned computer executable instruction further involves one or more processors: 1) generating a directed graph based at least partially on the multiple service plans, and 2) determining at least partially on determining that the directed graph lacks cycles, the multiple service plans are determined to be compatible. Based at least in part on determining that the multiple service plans are compatible, the service plan is added to the set of service plans that includes the multiple service plans and the service plan containing the service plan. A non-temporary computer-readable medium according to any of claims 15 to 18, which is in the process of the second process of bootstrapping the plurality of services within the cloud computing environment, wherein the version set is derived at least in part on the set of service plans, the version set comprises a plurality of version set items, the first of the plurality of version set items being associated with a corresponding service plan, and the second of the plurality of version set items being unrelated to any service plan. [Claim 20] The non-temporary computer-readable medium according to any one of claims 15 to 19, wherein executing the computer-executable instruction further causes one or more processors to determine that the service plans are compatible, at least in part on determining that no replication capability publications exist between the service plans.

Images