doc: update places to direct the users to check the samples in /testd…

…ata/ (#3995)

website/content/en/docs/building-operators/ansible/reference/retroactively-owned-resources.md

@@ -64,9 +64,9 @@ resource is a cluster level resource.
   * operator-sdk/primary-resource: {metadata.namespace}/{metadata.name}
   * operator-sdk/primary-resource-type: {kind}.{group}
 
-**NOTE**: The {group} can be found by splitting the `apiVersion`
+**NOTE**: The `{group}` can be found by splitting the `apiVersion`
 metadata of the CR, into `group` and `version`. As an example, 
-[this apiVersion field](https://github.com/operator-framework/operator-sdk-samples/blob/938fd148ba106ca9811925e4956d6bb70c36b29d/ansible/memcached-operator/config/samples/cache_v1alpha1_memcached.yaml#L1)
+`apiVersion: cache.example.com/v1alpha1` in the `config/samples` directory
 gives us the group `cache.example.com`.
 
 **Example Annotation:**

website/content/en/docs/contribution-guidelines/releasing.md

@@ -362,34 +362,7 @@ See [this section](#locking-down-branches) for steps to do so.
 
 ---
 
-You've now fully released a new version of the Operator SDK. Good work! Make sure to follow the post-release steps below.
-
-### (Post-release) Updating the operator-sdk-samples repo
-
-Many releases change SDK API's and conventions, which are not reflected in the [operator-sdk-samples repo][sdk-samples-repo]. The samples repo should be updated and versioned after each SDK major/minor release with the same tag, ex. `v1.3.0`, so users can refer to the correct operator code for that release.
-
-The release process for the samples repo is simple:
-
-1. Make changes to all relevant operators (at least those referenced by SDK docs) based on API changes for the new SDK release.
-1. Ensure the operators build and run as expected (see each operator's docs).
-1. Once all API changes are in `master`, create a release tag locally:
-    ```sh
-    $ git checkout master && git pull
-    $ export VER="v1.3.0"
-    $ git tag --sign --message "Operator SDK Samples $VER" "$VER"
-    ```
-1. Push the tag to the remote, assuming `upstream` is the name of the upstream remote:
-    ```sh
-    $ git push upstream $VER
-    ```
-
-### (Post-release) Updating the release notes
-
-Add the following line to the top of the GitHub release notes for `v1.3.0`:
-
-```md
-**NOTE:** ensure the `v1.3.0` tag is referenced when referring to sample code in the [SDK Operator samples repo](https://github.com/operator-framework/operator-sdk-samples/tree/v1.3.0) for this release. Links in SDK documentation are currently set to the samples repo `master` branch.
-```
+You've now fully released a new version of the Operator SDK. Good work! 
 
 [install-guide]: /docs/installation/install-operator-sdk
 [doc-maintainers]: https://github.com/operator-framework/operator-sdk/blob/master/MAINTAINERS

website/content/en/docs/overview/_overview.md

@@ -58,7 +58,7 @@ Find more details about the various levels and the feature requirements for them
 
 ## Samples
 
-To explore any operator samples built using the operator-sdk, see the [operator-sdk-samples][samples].
+To explore any operator samples built using the operator-sdk, see the samples in [operator-sdk/testdata/][testdata_samples].
 
 ## FAQ
 
@@ -93,5 +93,5 @@ Operator SDK is under Apache 2.0 license. See the [LICENSE][license_file] file f
 [of-home]: https://github.com/operator-framework
 [operator_link]: https://coreos.com/operators/
 [proposals_docs]: https://github.com/operator-framework/operator-sdk/tree/master/proposals
-[samples]: https://github.com/operator-framework/operator-sdk-samples
+[testdata_samples]: https://github.com/operator-framework/operator-sdk/tree/master/testdata
 [sdk_cli_ref]: /docs/cli/