doc/proposals: move proposals from openshift-* directories (#2412)

Author: Eric Stroczynski

doc/proposals/openshift-4.4/ansible-operator-devex.md renamed to doc/proposals/ansible-operator-devex.md

@@ -28,9 +28,9 @@ superseded-by: []
 ## Open Questions (optional)
 
 This is where to call out areas of the design that require closure before deciding
-to implement the design.  For instance, 
+to implement the design.  For instance,
  > 1. This requires exposing previously private resources which contain sensitive
-  information.  Can we do this? 
+  information.  Can we do this?
 
 ## Summary
 
@@ -58,7 +58,7 @@ Kubernetes/OpenShift API inconsistencies or operator-sdk bugs/behaviors.
 2. Update Ansible scaffolding, test scenarios, and examples to make use of newer
     Ansible features and best practices, including support for collections and
     simpler and more flexible test scenarios.
-3. Readable logs without additional dependencies, and ideally without a sidecar 
+3. Readable logs without additional dependencies, and ideally without a sidecar
     container.
 
 ### Non-Goals
@@ -80,7 +80,7 @@ This is where we get down to the nitty gritty of what the proposal actually is.
 #### Story 1 - Use operator-sdk up local to run the Ansible-based Operator
 
 As a user, I would like to be able to run `operator-sdk up local` to run my
-Ansible-based Operator without requiring additional work or options. Although 
+Ansible-based Operator without requiring additional work or options. Although
 it is currently possible to use `up local`, there are a variety of limitations
 that make the experience inferior to deploying the operator to a real cluster.
 
@@ -93,7 +93,7 @@ that make the experience inferior to deploying the operator to a real cluster.
 
 #### Story 2 - Use the molecule scenarios to test in a variety of environments
 
-As a user, I would like to be able to use the scaffolded molecule scenarios to 
+As a user, I would like to be able to use the scaffolded molecule scenarios to
 run the same set of tests against Kubernetes clusters in the following scenarios:
 
 1. An ephemeral cluster provisioned by molecule
@@ -109,7 +109,7 @@ As a user, if there are issues in the way the proxy/cache handles a certain reso
 I should be able to work around those issues without needing to wait for bugfixes or
 features in the operator-sdk, by preventing those resources from being passed through
 the cache at all. For example, if I need to access an OpenShift Project resource (which
-is not cacheable, because it is not watchable), I should be able to specify that the 
+is not cacheable, because it is not watchable), I should be able to specify that the
 Project resource skips the cache in my watches.yaml.
 
 
@@ -132,7 +132,7 @@ marginally higher maintenance burden when changing Ansible versions.
 
 ### Test Plan
 
-1. We will add at least one test for each molecule scenario (when possible). 
+1. We will add at least one test for each molecule scenario (when possible).
 1. We will add tests that make Ansible emit messages of each type that it supports,
     to help ensure that we can easily catch changes to the messag format.
 1. We will add a test scenario that uses `up local`.
@@ -162,4 +162,4 @@ None
 
 None
 
-[operator-sdk-doc]:  ../../../doc
+[operator-sdk-doc]:  ../../doc

doc/proposals/openshift-4.4/kubebuilder-integration.md renamed to doc/proposals/kubebuilder-integration.md

@@ -29,39 +29,39 @@ superseded-by: []
 
 ## Summary
 
-The Operator SDK should become compatible with Kubebuilder so that it has the 
-same project layout and CLI workflow for developing Go operators. 
-To achieve this goal without duplicating upstream code, the SDK should integrate 
-Kubebuilder’s CLI to reuse the scaffolding for project creation and lifecycle management. 
-At the same time the SDK should still be able to provide SDK specific features that work 
+The Operator SDK should become compatible with Kubebuilder so that it has the
+same project layout and CLI workflow for developing Go operators.
+To achieve this goal without duplicating upstream code, the SDK should integrate
+Kubebuilder’s CLI to reuse the scaffolding for project creation and lifecycle management.
+At the same time the SDK should still be able to provide SDK specific features that work
 with the new project layout.
 
-In order for the SDK to wrap and reuse Kubebuilder while still maintaining the 
-SDK binary as the entrypoint, Kubebuilder should be extended with a CLI interface 
-that supports registering plugins. This lets the SDK reuse Kubebuilder’s existing 
-scaffolding code for Go operators, while still being able to extend the CLI for SDK 
-specific features/sub-commands and provide custom plugins that will allow the SDK to 
+In order for the SDK to wrap and reuse Kubebuilder while still maintaining the
+SDK binary as the entrypoint, Kubebuilder should be extended with a CLI interface
+that supports registering plugins. This lets the SDK reuse Kubebuilder’s existing
+scaffolding code for Go operators, while still being able to extend the CLI for SDK
+specific features/sub-commands and provide custom plugins that will allow the SDK to
 scaffold different project types like Helm/Ansible in the future.
 
 
 ## Motivation
 
-The Operator SDK and Kubebuilder largely provide the same experience for developing 
+The Operator SDK and Kubebuilder largely provide the same experience for developing
 Go operators since both projects defer to APIs provided by the same upstream projects.
-The two projects differentiate in their CLI and UX of project setup, layout, and 
-lifecycle management. These differences are largely incidental of how the two 
-projects developed over time and not due to any use cases that are only addressed by either UX. 
-
-By adopting the same workflow and layout as Kubebuilder, the SDK gains better 
-alignment with the upstream community for writing Go operators. This allows the 
-SDK to be used interchangeably with Kubebuilder projects, which unifies the 
-experience of writing Go operators and resolves confusion on why the Operator SDK 
-and Kubebuilder differ in their UX to achieve the same goals. This lets the SDK 
-focus more on features that are outside the scope of Kubebuilder, such as 
+The two projects differentiate in their CLI and UX of project setup, layout, and
+lifecycle management. These differences are largely incidental of how the two
+projects developed over time and not due to any use cases that are only addressed by either UX.
+
+By adopting the same workflow and layout as Kubebuilder, the SDK gains better
+alignment with the upstream community for writing Go operators. This allows the
+SDK to be used interchangeably with Kubebuilder projects, which unifies the
+experience of writing Go operators and resolves confusion on why the Operator SDK
+and Kubebuilder differ in their UX to achieve the same goals. This lets the SDK
+focus more on features that are outside the scope of Kubebuilder, such as
 Operator Lifecycle Manager (OLM) integration and Scorecard.
 
-Reusing the project scaffolding from Kubebuilder also reduces duplication in 
-the SDK. This frees up Operator SDK maintainers to focus more on collaborating 
+Reusing the project scaffolding from Kubebuilder also reduces duplication in
+the SDK. This frees up Operator SDK maintainers to focus more on collaborating
 with the Kubebuilder maintainers on the upstream controller-runtime and controller-tools projects
 
 
@@ -87,20 +87,20 @@ with the Kubebuilder maintainers on the upstream controller-runtime and controll
 
 #### Story 1 - Design a Kubebuilder plugin interface that lets the SDK reuse and extend the CLI
 
-After upstream discussions with the Kubebuilder maintainers there is consensus 
-that Kubebuilder should support an interface to register plugins that would be 
-used to provide the implementation of CLI commands. This way Kubebuilder would 
-not have to directly expose its [cobra][cobra] CLI for the SDK’s consumption, and the SDK 
-could still reuse Kubebuilder’s plugins to scaffold new projects (init and create) 
-while also being able to register its own plugins to extend the CLI for SDK specific 
+After upstream discussions with the Kubebuilder maintainers there is consensus
+that Kubebuilder should support an interface to register plugins that would be
+used to provide the implementation of CLI commands. This way Kubebuilder would
+not have to directly expose its [cobra][cobra] CLI for the SDK’s consumption, and the SDK
+could still reuse Kubebuilder’s plugins to scaffold new projects (init and create)
+while also being able to register its own plugins to extend the CLI for SDK specific
 subcommands (csv-gen, scorecard).
 
-This plugin interface should also allow the SDK to provide custom plugin 
-implementations for the init and create subcommands so that it can customize the 
+This plugin interface should also allow the SDK to provide custom plugin
+implementations for the init and create subcommands so that it can customize the
 scaffolding of Helm and Ansible projects in the future.
 
-There is a [proposal][plugin-proposal] on Kubebuilder for the design of such a plugin interface. 
-The aim of this story is to address all reviewer comments to achieve consensus 
+There is a [proposal][plugin-proposal] on Kubebuilder for the design of such a plugin interface.
+The aim of this story is to address all reviewer comments to achieve consensus
 on the plugin architecture and merge the proposal.
 
 [plugin-proposal]: https://github.com/kubernetes-sigs/kubebuilder/pull/1250
@@ -109,27 +109,27 @@ on the plugin architecture and merge the proposal.
 
 #### Story 2 - Implement the Kubebuilder plugin interface and CLI pkg
 
-After the plugin interface proposal has been accepted, the implementations of 
+After the plugin interface proposal has been accepted, the implementations of
 the plugin interface and the CLI pkg should be added to Kubebuilder.
 
-This involves writing plugin implementations for the following scaffolding 
+This involves writing plugin implementations for the following scaffolding
 subcommands in Kubebuilder so that the SDK can register them for reuse in its own CLI:
 
 - `kubebuilder init`
 - `kubebuilder create api`
 - `kubebuilder create webhook`
 
-The goal of this story is to ensure a release of Kubebuilder that supports the 
+The goal of this story is to ensure a release of Kubebuilder that supports the
 new plugin interface that the SDK can integrate downstream into its own CLI.
 
 
 #### Story 3 - Integrate the Kubebuilder CLI into the SDK CLI to achieve the same workflow and project layout for Go operators
 
-Once Kubebuilder supports plugin registration, the SDK CLI should be modified 
-to reuse Kubebuilder’s CLI and plugins so that the SDK workflow for developing 
+Once Kubebuilder supports plugin registration, the SDK CLI should be modified
+to reuse Kubebuilder’s CLI and plugins so that the SDK workflow for developing
 Go operators is identical to Kubebuilder’s workflow.
 
-Project initialization and api/webhook scaffolding would be provided by the 
+Project initialization and api/webhook scaffolding would be provided by the
 upstream Kubebuilder CLI and plugins:  
 
 
@@ -144,42 +144,42 @@ Other SDK subcommands can be removed and replaced by their equivalent Makefile t
 - `operator-sdk build` ==> `make manager`, `make docker-build`
 - `operator-sdk up local` ==> `make run`
 
-If any of the old subcommands above are invoked for a Go operator project, the 
-output should be a deprecation error that highlights the equivalent replacement 
+If any of the old subcommands above are invoked for a Go operator project, the
+output should be a deprecation error that highlights the equivalent replacement
 for it in the new Kubebuilder workflow.
 
 
 #### Story 4 - Update the SDK specific features and subcommands to work with the new project layout
 
-Since features like the scorecard, CSV generation and test-framework have no 
+Since features like the scorecard, CSV generation and test-framework have no
 equivalent in the Kubebuilder workflow, those subcommands would be unchanged on the CLI.
 
 - `operator-sdk gen-csv`
 - `operator-sdk scorecard`
 - `operator-sdk test`
- 
-Where necessary the above commands should be adjusted to reflect the changes to 
+
+Where necessary the above commands should be adjusted to reflect the changes to
 their expected input and output manifest paths that is consistent with the new project layout.
 
 
 #### Story 5 - Update the Operator SDK e2e tests to work with the new project layout
 
-The existing e2e tests and CI scripts for testing Go operators would need to be 
+The existing e2e tests and CI scripts for testing Go operators would need to be
 updated to use the new layout so that CI passes for the new CLI workflow in the master branch.
 
 
 #### Story 6 - Update the Go operator related documentation per the Kubebuilder workflow and project layout
 
-The user documentation for Go operators such as the user-guide, CLI reference, 
+The user documentation for Go operators such as the user-guide, CLI reference,
 project layout, etc will need to be updated according to the new CLI and layout.
 
 
 ### Implementation Details/Notes/Constraints
-The integration work for the Go Operator CLI workflow can be done in the master 
+The integration work for the Go Operator CLI workflow can be done in the master
 branch to avoid issues with merge conflicts from rebasing a separate branch at a later time.
-The new CLI can be worked on behind a hidden subcommand, `operator-sdk alpha`, until it is ready to 
-replace the existing workflow. This would help avoid exposing it too early while 
-still providing the ability to test it on the master branch. 
+The new CLI can be worked on behind a hidden subcommand, `operator-sdk alpha`, until it is ready to
+replace the existing workflow. This would help avoid exposing it too early while
+still providing the ability to test it on the master branch.
 
 
 ### Risks and Mitigations
@@ -190,4 +190,4 @@ still providing the ability to test it on the master branch.
   - With the proposed plugin architecture it should be possible to update the workflow for Helm/Ansible operators to be the same as Kubebuilder. However that is not currently in scope for this proposal.
 
 
-[operator-sdk-doc]: ../../../doc
+[operator-sdk-doc]: ../../doc

doc/proposals/openshift-4.4/kubernetes-1.17.md renamed to doc/proposals/kubernetes-1.17.md

@@ -120,7 +120,7 @@ History`.
 
 The only drawback is the potential for breaking changes in client code due to breaking
 changes introduced by the Kubernetes 1.17 version update. However, this is unavoidable
-since Kubernetes minor versions almost always contain breaking changes that impact 
+since Kubernetes minor versions almost always contain breaking changes that impact
 controller-runtime and Operator SDK.
 
 ## Alternatives
@@ -131,6 +131,6 @@ None
 
 N/A
 
-[operator-sdk-doc]:  ../../../doc
+[operator-sdk-doc]:  ../../doc
 [controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
 [helm]: https://github.com/helm/helm

doc/proposals/openshift-4.3/operator-testing-tool.md renamed to doc/proposals/operator-testing-tool.md

@@ -80,7 +80,7 @@ be enabled in CI.
 
 #### Story 2 - Instrument unit tests with code coverage
 
-Test coverage will be tracked by running unit tests with code coverage enabled and 
+Test coverage will be tracked by running unit tests with code coverage enabled and
 submitting results to coveralls.io during CI. This integration will highlight code
 coverage improvements or regressions in each PR, which will incentivize contributors
 and reviewers to improve code coverage over time.
@@ -107,7 +107,7 @@ directly.
 ### Risks and Mitigations
 
 Only risk is that deprecation of `generate openapi` will break a small subset of SDK
-users. The mitigation is that the SDK will include instructions for running code 
+users. The mitigation is that the SDK will include instructions for running code
 generation tools directly, which will be a 1-to-1 replacement of the deprecated
 functionality in Operator SDK.
 
@@ -116,7 +116,7 @@ functionality in Operator SDK.
 ### Test Plan
 
 All unit tests will gain coverage metrics, which will increase visibility on the areas
-of the codebase that do not have adequete testing. 
+of the codebase that do not have adequete testing.
 
 The `generate` subcommand changes will also result in refactored unit and e2e tests,
 which will no longer need to check for the existence of generated Go OpenAPI code.
@@ -150,4 +150,4 @@ None
 
 None
 
-[operator-sdk-doc]:  ../../../doc
+[operator-sdk-doc]:  ../../doc