KEP-0012 Framework Extensions (#351)

* Initial KEP * more questions
kudobuilder · Jun 25, 2019 · b9b6c52 · b9b6c52
1 parent a221ac3
commit b9b6c52
Show file tree

Hide file tree

Showing 2 changed files with 319 additions and 102 deletions.
diff --git a/keps/0009-operator-toolkit.md b/keps/0009-operator-toolkit.md
@@ -271,108 +271,6 @@ Parameters are intentionally open for extension for adding fields in the future
 
 A template is a standard Kubernetes manifest which **MAY** have additional Go Templating. These Go Templates include [Sprig](https://github.com/masterminds/sprig) to provide a standard library of functions familiar to Helm users. Additional values are available and are described in [Execution State](#execution-state).
 
-## Extensions and Bases
-
-Extensions and bases describe a mechanism for building frameworks or extensions to frameworks from a given base. As an example, a base can be a framework, a Helm chart, a CNAB bundle, or any future format that describes the deployment of a set of resources.
-
-In this document, an **extension** is any KUDO framework that extends from some base. A **base** is the complete set of manifests, metadata, and other files provided by that base's type. A base should provide complete information that users of that base tool are expected to have. The base types and what they expose to charts that extend from them are described in their respective sub-sections.
-
-To support extending from a base, `framework.yaml` is extended to support the `extends` keyword:
-
-```yaml
-extends:
-  kudo:
-    framework: "mysql"
-    version: "5.7"
-```
-
-After extending, the base resources are inherited by the extending framework. The behavior of extensions and values available from the base are described in their corresponding sub-section.
-
-When a task is defined in an extended framework, it **replaces** the task from the base. The tasks available are dependent on the base type and are described more in detail in their corresponding sub-section.
-
-When a plan is defined in an extended framework, it **replaces** the plan from the base. The plans available are dependent on the base type and are described more in detail in their corresponding sub-section.
-
-### Task Extensions
-
-- `task.from`: The `from` directive inside of a named task copies over all resources and patches from the base task of the same name. Resources and patches that overlap with base resource and patch names replace resource and patches already defined by the base. If the base task doesn't exist, an error event will be added to the Instance that is attempting to use this FrameworkVersion.
-- `base/`: The `base/` directive in a template reference resolves to the named template within the extended base. For example, `base/deployment.yaml` corresponds to `deployment.yaml` file located within the base referenced by `extends`. This enables base templates to be used directly in new plans defined by the extending framework.
-
-### Plan Extensions
-
-- `plan.from`: The `from` directive inside of a named plan copies over the steps for that plan. Any additional steps defined are **appended** to the base plan.
-- `base/`: The `base/` directive in a task reference resolves to the named task within the extended base. For example, `base/deploy` corresponds to the `deploy` task in the base. This enables fine grained control over replacing steps in a base plan.
-
-### Example Framework Extension
-
-This framework is built from the MySQL framework defined above, but adds custom plans that allow for the loading and clearing of data that is required for a particular business application
-
-```shell
-.
-├── framework.yaml
-├── params.yaml
-└── templates
-    ├── clear-data.yaml
-    ├── load-data.yaml
-```
-
-Since this framework extends `mysql/5.7`, it inherits the plans defined in the base framework, so `backup` and `restore` plans can be run without any configuration in this extension framework.
-
-#### framework.yaml
-
-`framework.yaml` is the base definition of a framework. It follows the following format, extracted from the MySQL example:
-
-```yaml
-extends:
-  kudo:
-    framework: "mysql"
-    version: "5.7"
-version: "5.7"
-tasks:
-  load-data:
-    resources:
-      - base/init.yaml
-    patches:
-      - load-data.yaml
-  clear-data:
-    from: base/init
-    patches:
-      - clear-data.yaml
-plans:
-  load:
-    steps:
-      - name: load
-        tasks:
-          - load-data
-      - name: cleanup
-        tasks:
-          - load-data
-        delete: true
-  clear:
-    steps:
-      - name: clear
-        tasks:
-          - clear-data
-      - name: cleanup
-        tasks:
-          - clear-data
-        delete: true
-```
-
-Tasks `load-data` and `clear-data` essentially look the same, but `load-data` is built fresh, and references the base template object, whereas the `clear-data` task extends the `base/init` task with an additional patch.
-
-#### params.yaml
-
-This framework also provides a new parameter that can be used to specify unique datasources to load
-
-```yaml
-data-location:
-  default: https://s3.aws.com/bucket/data.sql
-  description: "Location of data to load into database"
-  trigger: load
-```
-
-And can be used in `templates/clear-data.yaml` and `templates/load-data.yaml`
-
 ## Future Work
 
 ### Allow for other templating engines