rename operational configuration to application configuration

1.purpose_and_goals.md

@@ -11,7 +11,7 @@ This open specification defines:
 - __Component schematics__, where developers declare the operational characteristics of the code they deliver _in infrastructure neutral terms_.
 - __Application scopes__, a way to group components into loosely coupled applications with common characteristics.
 - __Traits__ for assigning operational features to instances of components.
-- __Operational configuration__, defines a deployment of components, their traits, and application scopes.
+- __Application configuration__, defines a deployment of components, their traits, and application scopes.
 - __Workload types and configurations__, which describe the underlying runtime for a particular workload, as well as exposing per-application configuration.
 
 Additional goals of the specification are to:

2.overview_and_terminology.md

@@ -26,7 +26,7 @@ The application model defines the following:
  - _Workload types_ identify the different workloads that a component can execute.
  - _Traits_ are overlays that augment a component with additional operations-specific features. Traits represent operator concerns, not developer concerns.
  - _Application scopes_ represent application boundaries by grouping components with common properties or dependencies.
- - An _operational configuration_ describes a set of component instances, their traits, and the application scopes in which they are placed, combined with configuration parameters and metadata.
+ - An _application configuration_ describes a set of component instances, their traits, and the application scopes in which they are placed, combined with configuration parameters and metadata.
 
 Thus, an _application_ is a collection of _components_ with a set of operational traits and scoped together into one or more application boundaries. 
 
@@ -139,15 +139,15 @@ A trait is described as:
 
 - Metadata: Information about the trait
 - Applies-to list: Enumeration of which workload types this trait applies to
-- Parameters: Configuration that may be specified in an operational configuration
+- Parameters: Configuration that may be specified in an application configuration
 
-### Operational Configuration
+### Application Configuration
 
-An operational configuration is a resource that declares how an application (described as an application schematic and component schematics) can be instantiated and configured, including which parameter overrides and add-on traits.
+An application configuration is a resource that declares how an application (described as an application schematic and component schematics) can be instantiated and configured, including which parameter overrides and add-on traits.
 
-An operational configuration has the following parts:
+An application configuration has the following parts:
 
-- Metadata: Information about the application instance
+- Metadata: Information about the installed application configuration
 - Parameter Overrides: Values to supply to named parameters in the application or components
 - Trait configuration: A list of traits to enable, together with parameter overrides for each trait
 - Workload type settings: Overrides to workload type settings

3.component_model.md

@@ -2,7 +2,7 @@
 
 This section defines the component model.
 
-Components describe functional units that may be instantiated as part of a larger distributed application. For example, each microservice in an application is described as a component. The description itself is not an instance of that microservice, but a declaration of the operational capabilities of that microservice. [Section 6, Operational Configuration](6.operational_configuration.md) describes how components are grouped together and how instances of those components are then configured.
+Components describe functional units that may be instantiated as part of a larger distributed application. For example, each microservice in an application is described as a component. The description itself is not an instance of that microservice, but a declaration of the operational capabilities of that microservice. [Section 6, Application Configuration](6.application_configuration.md) describes how components are grouped together and how instances of those components are then configured.
 
 ## Component Schematics
 

4.application_scopes.md

@@ -30,7 +30,7 @@ Core application scope types define grouping constructs for basic runtime behavi
  - Core application scope types MUST all be supported by any implementation of the specification. They may be implemented by any available feature in the platform, but they MUST be implemented according to the specification of each core application scope type.
  - Instances of core *workload* types MUST be deployed into an instance of each core application scope type. 
  - Runtimes MUST provide a default "root" application scope instance for each core application scope type.
- - Runtimes MUST deploy each component instances into default "root" application scope instances when an operational configuration does not otherwise specify an application scope for a component instance.
+ - Runtimes MUST deploy each component instances into default "root" application scope instances when an application configuration does not otherwise specify an application scope for a component instance.
 
  The following core application scope types are defined by this specification:
 
@@ -88,7 +88,7 @@ The parameters that a scope exposes to operators.
 | `default` | type indicated by `type` field | N | | The parameter's default value. |
 
 ## Deployment
-Application scope instances are defined and deployed in an operational configuration. See [Operational Configuration](6.operational_configuration.md) for more information on deploying scopes.
+Application scope instances are defined and deployed in an application configuration. See [Application Configuration](6.application_configuration.md) for more information on deploying scopes.
 
 ## Core scope type definitions
 The following core scope types are available:

5.traits.md

@@ -1,14 +1,14 @@
 # 5. Traits
 
-A _trait_ is a discretionary runtime overlay that augments a component workload type (`workloadType`) with additional features. It is an opportunity for those in the _application operator_ role to make specific decisions about the configuration of components, but without involving the developer. A trait can be any operational configuration of a distributed application that applies to an individual component, such as traffic routing rules (e.g., load balancing policy, network ingress routing, circuit breaking, rate limiting), auto-scaling policies, upgrade strategies, and more.
+A _trait_ is a discretionary runtime overlay that augments a component workload type (`workloadType`) with additional features. It is an opportunity for those in the _application operator_ role to make specific decisions about the configuration of components, but without involving the developer. A trait can be any configuration of a distributed application that applies to an individual component, such as traffic routing rules (e.g., load balancing policy, network ingress routing, circuit breaking, rate limiting), auto-scaling policies, upgrade strategies, and more.
 
 The _traits system_ is defined in this specification as the way a runtime applies and manages operational behaviors to instances of components through traits.
 
 Runtime implementations of the specification MUST provide the traits system for attaching operational behaviors to instances of components. 
 
 ## Traits system rules and characteristics 
 
-Traits are applied to component instances in the [operational configuration](6.operational_configuration.md). 
+Traits are applied to component instances in the [application configuration](6.application_configuration.md). 
 
 Traits should be applied into the runtime at installation/upgrade time. Traits should not be checked "lazily", but should be checked when the trait-holding components are created.
 
@@ -134,11 +134,11 @@ spec:
 
 #### Usage examples
 
-The following snippet from an operational configuration shows how the manual scaler trait is applied and configured for a component. In this example, it is assumed component `frontend` has a workload type of `core.hydra.io/v1alpha1.Service`.
+The following snippet from an application configuration shows how the manual scaler trait is applied and configured for a component. In this example, it is assumed component `frontend` has a workload type of `core.hydra.io/v1alpha1.Service`.
 
 ```yaml
 apiVersion: core.hydra.io/v1alpha1
-kind: OperationalConfiguration
+kind: ApplicationConfiguration
 metadata:
   name: custom-single-app
   annotations:
@@ -156,9 +156,9 @@ spec:
             replicaCount: 5
 ```
 
-This example illustrates using the manual scaler trait to manually scale a component by specifying the number of replicas the runtime should create. This trait has only one attribute in its properties: `replicaCount`. This takes an integer, and a value is required for this trait to be successfully applied. If, for example, an operational configuration used this trait but did not provide the `replicaCount`, the system would reject the operational configuration.
+This example illustrates using the manual scaler trait to manually scale a component by specifying the number of replicas the runtime should create. This trait has only one attribute in its properties: `replicaCount`. This takes an integer, and a value is required for this trait to be successfully applied. If, for example, an application configuration used this trait but did not provide the `replicaCount`, the system would reject the application configuration.
 
 
 | Previous Part        | Next Part           | 
 | ------------- |-------------|
-| [4. Application Scopes](4.application_scopes.md) | [6. Operational Configuration](6.operational_configuration.md) |
+| [4. Application Scopes](4.application_scopes.md) | [6. Application Configuration](6.application_configuration.md) |