(docs) Remove KCP reference

Signed-off-by: Anik <[email protected]>

Author: anik120

docs/index.md

@@ -16,13 +16,10 @@ OLM also prevents conflicting extensions from running on the cluster, either wit
 
 During their lifecycle on the cluster, OLM also manages the permissions and capabilities extensions have on the cluster as well as the permission and access tenants on the cluster have to the extensions. This is done using the Kubernetes RBAC system, in combination with tenant isolation using Kubernetes namespaces. While the interaction surface of the extensions is solely composed of Kubernetes APIs the extensions define, there is an acute need to rethink the way tenant(i.e consumers of extensions) isolation is achieved. The ask from OLM, is to provide tenant isolation in a more intuitive way than [is implemented in OLM v0](https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/#docs)
 
-OLM also defines a packaging model in which catalogs of extensions, usually containing the entire version history of each extension, are made available to clusters for cluster users to browse and select from. While these catalogs have so far been packaged and shipped as container images, there is a growing appetite to allow more ways of packaging and shipping these catalogs, besides also simplifying the building process of these catalogs, which so far have been very costly. The effort to bring down the cost was kicked off in OLM v0 with conversion of the underlying datastore for catalog metadata to [File-based Catalogs](https://olm.operatorframework.io/docs/reference/file-based-catalogs/), with more effort being invested to slim down the process in v1. Via new versions of extensions delivered with this packaging system, OLM is able to apply updates to existing running extensions on the cluster in a way where the integrity of the cluster is maintained and constraints and dependencies are kept satisfied.
+OLM also defines a packaging model in which catalogs of extensions, usually containing the entire version history of each extension, are made available to clusters for cluster users to browse and select from. While these catalogs have so far been packaged and shipped as container images, there is a growing appetite to allow more ways of packaging and shipping these catalogs, besides also simplifying the building process of these catalogs, which so far have been very costly. The effort to bring down the cost was kicked off in OLM v0 with conversion of the underlying datastore for catalog metadata to [File-based Catalogs](https://olm.operatorframework.io/docs/reference/file-based-catalogs/), with more effort being invested to slim down the process in v1. Via new versions of extensions delivered with this new packaging system, OLM will be able to apply updates to existing running extensions on the cluster in a way where the integrity of the cluster is maintained and constraints and dependencies are kept satisfied.
 
-The scope of OLM's area of operation in v0 is the one cluster it is running on, with namespace-based handling of catalog access and extension API accessibility and discoverability.
-Expansion of this scope is indirectly expected through the work of the [Kubernetes Control Plane (kcp) project](https://github.com/kcp-dev/kcp), which in its first incarnation will likely use its own synchronization mechanism to get OLM-managed extensions deployed eventually on one or more physical clusters from a shared, virtual control plane called a “workspace”. While this is an area under active development and subject to change, OLM will most likely need to become aware of kcp in a future state. In v1 of OLM, the scope of OLM will increase to span multiple clusters following the kcp model, though likely many aspects of this will become transparent to OLM itself through the workspace abstraction that kcp provides. So in other words, what needs to change in OLM 1.0 is how all of the tasks mentioned above are carried out from the user perspective, and how much control users have in the process, and which persona is involved.
 
-
-For a detailed writeup of OLM v1 requirements, please read the [Product Requiment Documentation](/docs/olmv1_roadmap.md)
+For a detailed writeup of OLM v1 requirements, please read the [Product Requiment Documentation](github.com/operator-framework/operator-controller/olmv1_roadmap.md)
 
 # The OLM community