Remove install references to rukpak (#805)

Signed-off-by: Todd Short <[email protected]>

Author: tmshort

.github/workflows/tilt.yaml

@@ -22,10 +22,6 @@ jobs:
     - uses: actions/checkout@v4
       with:
         path: operator-controller
-    - uses: actions/checkout@v4
-      with:
-        repository: operator-framework/rukpak
-        path: rukpak
     - uses: actions/checkout@v4
       with:
         repository: operator-framework/catalogd

CONTRIBUTING.md

@@ -19,9 +19,8 @@ The user experience captured in the OLM V1 PRD introduces many requirements that
 - [The Operator-Controller project](https://github.com/operator-framework/operator-controller/), which is the top level component allowing users to specify operators they'd like to install.
 - [The Catalogd project](https://github.com/operator-framework/catalogd/), which hosts operator content and helps users discover installable content.
 - [The Deppy project](https://github.com/operator-framework/deppy/), which enables the operator-controller to identify valid installs and upgrades from the list of installable content provided via the Catalogd project.
-- [The RukPak project](https://github.com/operator-framework/rukpak/), which facilitates the installation of operators.
 
-Each of the projects listed above have their own governance, release milestones, and release cadence. However, from a technical perspective, the "OLM V1 experience" matches the experienced offered by the operator-controller project, the top level component which introduces dependencies on RukPak, Deppy, and the Catalogd projects.
+Each of the projects listed above have their own governance, release milestones, and release cadence. However, from a technical perspective, the "OLM V1 experience" matches the experienced offered by the operator-controller project, the top level component which introduces dependencies on Deppy and the Catalogd projects.
 
 ## How do we collaborate
 
@@ -62,7 +61,7 @@ Ongoing or previous Operator-Controller milestones can always be found in the [m
 
 ### How are Subproject Issues Tracked?
 
-As discussed earlier, the operator-controller adheres to a microservice architecture, where multiple projects contribute to the overall experience. As such, when designing an operator-controller milestone, the community may need to file an issue against RukPak, Deppy, or Catalogd. Unfortunately, the operator-controller milestone cannot contain issues from one of its subprojects. As such, we've introduced the concept of a "Dependency Issue", described below:
+As discussed earlier, the operator-controller adheres to a microservice architecture, where multiple projects contribute to the overall experience. As such, when designing an operator-controller milestone, the community may need to file an issue against Deppy or Catalogd. Unfortunately, the operator-controller milestone cannot contain issues from one of its subprojects. As such, we've introduced the concept of a "Dependency Issue", described below:
 
 > Dependency Issues: An issue tracked in a milestone that "points" to an issue in another project with a URL.
 
@@ -72,7 +71,6 @@ Unsure where to submit an issue?
 - [The Operator-Controller project](https://github.com/operator-framework/operator-controller/), which is the top level component allowing users to specify operators they'd like to install.
 - [The Catalogd project](https://github.com/operator-framework/catalogd/), which hosts operator content and helps users discover installable content.
 - [The Deppy project](https://github.com/operator-framework/deppy/), which enables the operator-controller to identify valid installs and upgrades from the list of installable content provided via the Catalogd project.
-- [The RukPak project](https://github.com/operator-framework/rukpak/), which facilitates the installation of operators.
 
 Don't worry if you accidentally submit an issue against the wrong project, if we notice that an issue would fit better with a separate project we'll move it to the correct repository and mention it in the #olm-dev slack channel.
 

Makefile

@@ -7,7 +7,6 @@ export IMAGE_TAG ?= devel
 export CERT_MGR_VERSION ?= v1.9.0
 export CATALOGD_VERSION ?= $(shell go list -mod=mod -m -f "{{.Version}}" github.com/operator-framework/catalogd)
 export KAPP_VERSION ?= $(shell go list -mod=mod -m -f "{{.Version}}" github.com/vmware-tanzu/carvel-kapp-controller)
-export RUKPAK_VERSION=$(shell go list -mod=mod -m -f "{{.Version}}" github.com/operator-framework/rukpak)
 export WAIT_TIMEOUT ?= 60s
 IMG?=$(IMAGE_REPO):$(IMAGE_TAG)
 TESTDATA_DIR := testdata
@@ -167,7 +166,7 @@ endif
 kind-deploy: export MANIFEST="./operator-controller.yaml"
 kind-deploy: manifests $(KUSTOMIZE) #EXHELP Install controller and dependencies onto the kind cluster.
 	$(KUSTOMIZE) build $(KUSTOMIZE_BUILD_DIR) > operator-controller.yaml
-	envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$KAPP_VERSION,$$RUKPAK_VERSION,$$MANIFEST' < scripts/install.tpl.sh | bash -s
+	envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$KAPP_VERSION,$$MANIFEST' < scripts/install.tpl.sh | bash -s
 
 .PHONY: kind-cluster
 kind-cluster: $(KIND) #EXHELP Standup a kind cluster.
@@ -241,7 +240,7 @@ release: $(GORELEASER) #EXHELP Runs goreleaser for the operator-controller. By d
 quickstart: export MANIFEST="https://github.com/operator-framework/operator-controller/releases/download/$(VERSION)/operator-controller.yaml"
 quickstart: $(KUSTOMIZE) manifests #EXHELP Generate the installation release manifests and scripts.
 	$(KUSTOMIZE) build $(KUSTOMIZE_BUILD_DIR) | sed "s/:devel/:$(VERSION)/g" > operator-controller.yaml
-	envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$KAPP_VERSION,$$RUKPAK_VERSION,$$MANIFEST' < scripts/install.tpl.sh > install.sh
+	envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$KAPP_VERSION,$$MANIFEST' < scripts/install.tpl.sh > install.sh
 
 ##@ Docs
 

README.md

@@ -17,7 +17,6 @@ OLM v1 is the follow-up to OLM v0, located [here](https://github.com/operator-fr
 OLM v1 consists of four different components:
 * operator-controller (this repository)
 * [deppy](https://github.com/operator-framework/deppy)
-* [rukpak](https://github.com/operator-framework/rukpak)
 * [catalogd](https://github.com/operator-framework/catalogd)
 
 For a more complete overview of OLM v1 and how it differs from OLM v0, see our [overview](./docs/olmv1_overview.md).
@@ -76,7 +75,7 @@ Install the CRDs and the operator-controller into a new [KIND cluster](https://k
 make run
 ```
 This will build a local container image of the operator-controller, create a new KIND cluster and then deploy onto that cluster.
-This will also deploy the catalogd, rukpak and cert-manager dependencies.
+This will also deploy the catalogd and cert-manager dependencies.
 
 ### Modifying the API definitions
 If you are editing the API definitions, generate the manifests such as CRs or CRDs using:

docs/components.md

@@ -2,11 +2,6 @@ OLM v1 is composed of various component projects:
 
 * [operator-controller](https://github.com/operator-framework/operator-controller): operator-controller is the central component of OLM v1, that consumes all of the components below to extend Kubernetes to allows users to install, and manage the lifecycle of other extensions
 
-* [rukpak](https://github.com/operator-framework/rukpak): RukPak is a pluggable solution for the packaging and distribution of cloud-native content and supports advanced strategies for installation, updates, and policy. The project provides a content ecosystem for installing a variety of artifacts, such as Git repositories, Helm charts, OLM bundles, and more onto a Kubernetes cluster. These artifacts can then be managed, scaled, and upgraded in a safe way to enable powerful cluster extensions.
-At its core, RukPak is a small set of APIs, packaged as Kubernetes CustomResourceDefinitions, and controllers that watch for those APIs. These APIs express what content is being installed on-cluster and how to create a running deployment of the content.
-
-
 * [deppy](https://github.com/operator-framework/deppy): Deppy is a Kubernetes API that runs on- or off-cluster for resolving constraints over catalogs of RukPak bundles. Deppy is part of the next iteration of OLM and was first introduced here. The initial goal of the project is to remove the dependency manager from the Operator Lifecycle Manager (OLM) and make it its own generic component.
 
-
 * [catalogD](https://github.com/operator-framework/catalogd): Catalogd is a Kubernetes extension that unpacks [file-based catalog (FBC)](https://olm.operatorframework.io/docs/reference/file-based-catalogs/#docs) content that is packaged and shipped in container images, for consumption by clients on-clusters (unpacking from other sources, like git repos, OCI artifacts etc, are in the roadmap for catalogD). As component of the Operator Lifecycle Manager (OLM) v1 microservices architecture, catalogD hosts metadata for Kubernetes extensions packaged by the authors of the extensions, as a result helping customers discover installable content.

scripts/install.tpl.sh

@@ -11,20 +11,16 @@ fi
 
 catalogd_version=$CATALOGD_VERSION
 cert_mgr_version=$CERT_MGR_VERSION
-rukpak_version=$RUKPAK_VERSION
 kapp_version=$KAPP_VERSION
 
-if [[ -z "$catalogd_version" || -z "$cert_mgr_version" || -z "$rukpak_version" || -z "$kapp_version" ]]; then
+if [[ -z "$catalogd_version" || -z "$cert_mgr_version" || -z "$kapp_version" ]]; then
     err="Error: Missing component version(s) for: "
     if [[ -z "$catalogd_version" ]]; then
         err+="catalogd "
     fi 
     if [[ -z "$cert_mgr_version" ]]; then
         err+="cert-manager "
     fi 
-    if [[ -z "$rukpak_version" ]]; then
-        err+="rukpak "
-    fi 
     if [[ -z "$kapp_version" ]]; then
         err+="kapp "
     fi 
@@ -46,11 +42,6 @@ kubectl_wait "cert-manager" "deployment/cert-manager-webhook" "60s"
 kubectl apply -f "https://github.com/carvel-dev/kapp-controller/releases/download/${kapp_version}/release.yml"
 kubectl_wait "kapp-controller" "deployment.apps/kapp-controller" 60s
 
-kubectl apply -f "https://github.com/operator-framework/rukpak/releases/download/${rukpak_version}/rukpak.yaml"
-kubectl_wait "rukpak-system" "deployment/core" "60s"
-kubectl_wait "rukpak-system" "deployment/helm-provisioner" "60s"
-kubectl_wait "rukpak-system" "deployment/rukpak-webhooks" "60s"
-
 kubectl apply -f "https://github.com/operator-framework/catalogd/releases/download/${catalogd_version}/catalogd.yaml"
 kubectl_wait "catalogd-system" "deployment/catalogd-controller-manager" "60s"