fix(olm): fix profile name: Openshift -> OpenShift

Also fixes every occurrence of "Openshift" to "OpenShift" in the docs.

config/crd/bases/camel.apache.org_integrationplatforms.yaml

@@ -310,7 +310,7 @@ spec:
                 type: object
               cluster:
                 description: what kind of cluster you're running (ie, plain Kubernetes
-                  or Openshift)
+                  or OpenShift)
                 type: string
               configuration:
                 description: list of configuration properties to be attached to all
@@ -1868,7 +1868,7 @@ spec:
                 type: object
               cluster:
                 description: what kind of cluster you're running (ie, plain Kubernetes
-                  or Openshift)
+                  or OpenShift)
                 type: string
               conditions:
                 description: which are the conditions met (particularly useful when

config/samples/patch-integration-platform.yaml

@@ -24,7 +24,7 @@ spec:
   # The profile to be implemented by default
   # ie. OpenShift, Kubernetes, Knative
   #
-  profile: Openshift
+  profile: OpenShift
   #
   #
   # Options propagated to integrations

docs/modules/ROOT/pages/architecture/traits.adoc

@@ -19,10 +19,10 @@ Traits are typically used to tune several aspects of an `Integration`. However,
 Another important concept related to the trait lifecycle is the **trait profile**. At this time, Camel K is supporting the following profiles:
 
 * Kubernetes
-* Openshift
+* OpenShift
 * Knative
 
-A profile is useful to identify on which kind of cluster a trait has to run: vanilla `Kubernetes`, `Openshift` or OpenShift/Kubernetes clusters powered by `Knative`. The default is to allow a trait on any profile; each trait can specify a different behavior (ie, running a trait only for a profile as it happens with `Knative`).
+A profile is useful to identify on which kind of cluster a trait has to run: vanilla `Kubernetes`, `OpenShift` or OpenShift/Kubernetes clusters powered by `Knative`. The default is to allow a trait on any profile; each trait can specify a different behavior (ie, running a trait only for a profile as it happens with `Knative`).
 
 [[traits-configuration]]
 === Trait configuration

docs/modules/ROOT/pages/contributing/local-deployment-olm.adoc

@@ -6,7 +6,7 @@ The following steps assume that
 - you've already built the camel-k image using `make images` and made it available in the cluster as an imagestream
 - you've already built the bundle image using `make bundle` and have pushed it to some registry
 
-To perform OLM (Operator Lifecycle Manager) based deployment of camel-k, built from source locally on an Openshift cluster, you can follow the steps below.
+To perform OLM (Operator Lifecycle Manager) based deployment of camel-k, built from source locally on an OpenShift cluster, you can follow the steps below.
 
 Login to the cluster using the standard "oc" tool, create new project, complete the basic setup process. Reference commands below
 

docs/modules/ROOT/partials/apis/camel-k-crds.adoc

@@ -1885,7 +1885,7 @@ IntegrationPlatformSpec defines the desired state of IntegrationPlatform
 |
 
 
-what kind of cluster you're running (ie, plain Kubernetes or Openshift)
+what kind of cluster you're running (ie, plain Kubernetes or OpenShift)
 
 |`profile` +
 *xref:#_camel_apache_org_v1_TraitProfile[TraitProfile]*
@@ -5487,7 +5487,7 @@ as a Maven repository.
 
 The Route trait can be used to configure the creation of OpenShift routes for the integration.
 
-The certificate and key contents may be sourced either from the local filesystem or in a Openshift `secret` object.
+The certificate and key contents may be sourced either from the local filesystem or in a OpenShift `secret` object.
 The user may use the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference a certificate stored in a `secret`.
 Parameters ending in `-secret` have higher priorities and in case the same route parameter is set, for example: `tls-key-secret` and `tls-key`,
 then `tls-key-secret` is used.

docs/modules/traits/pages/route.adoc

@@ -3,7 +3,7 @@
 // Start of autogenerated code - DO NOT EDIT! (description)
 The Route trait can be used to configure the creation of OpenShift routes for the integration.
 
-The certificate and key contents may be sourced either from the local filesystem or in a Openshift `secret` object.
+The certificate and key contents may be sourced either from the local filesystem or in a OpenShift `secret` object.
 The user may use the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference a certificate stored in a `secret`.
 Parameters ending in `-secret` have higher priorities and in case the same route parameter is set, for example: `tls-key-secret` and `tls-key`,
 then `tls-key-secret` is used.
@@ -107,7 +107,7 @@ Refer to the OpenShift route documentation for additional information.
 
 == Examples
 
-These examples uses *secrets* to store the certificates and keys to be referenced in the integrations. Read Openshift route documentation for detailed information about routes. The https://github.com/apache/camel-k/blob/main/examples/http/PlatformHttpServer.java[PlatformHttpServer.java] is the integration example. 
+These examples uses *secrets* to store the certificates and keys to be referenced in the integrations. Read OpenShift route documentation for detailed information about routes. The https://github.com/apache/camel-k/blob/main/examples/http/PlatformHttpServer.java[PlatformHttpServer.java] is the integration example. 
 
 As a requirement to run these examples, you should have a `secret` with a key and certificate.
 
@@ -141,12 +141,12 @@ kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc
 [source,console]
 kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc/ssl/my-combined-certs  -p quarkus.http.ssl.certificate.file=/etc/ssl/my-combined-certs/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/my-combined-certs/tls.key -t route.tls-termination=reencrypt -t route.tls-destination-ca-certificate-secret=my-combined-certs/tls.crt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
 
-* To add a *reencrypt* route using a specific certificate from a secret for the route and https://docs.openshift.com/container-platform/4.8/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate[Openshift service serving certificates] for the integration endpoint. This way the Openshift service serving certificates is set up only in the integration pod. The keys and certificates should be visible in the running integration pod, to achieve this we are using the `--resource` kamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with `-p quarkus.http.ssl.certificate`. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
+* To add a *reencrypt* route using a specific certificate from a secret for the route and https://docs.openshift.com/container-platform/4.8/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate[OpenShift service serving certificates] for the integration endpoint. This way the OpenShift service serving certificates is set up only in the integration pod. The keys and certificates should be visible in the running integration pod, to achieve this we are using the `--resource` kamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with `-p quarkus.http.ssl.certificate`. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
 +
 [source,console]
 kamel run --dev PlatformHttpServer.java --resource secret:cert-from-openshift@/etc/ssl/cert-from-openshift  -p quarkus.http.ssl.certificate.file=/etc/ssl/cert-from-openshift/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/cert-from-openshift/tls.key -t route.tls-termination=reencrypt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
 +
-Then you should annotate the integration service to inject the Openshift service serving certificates
+Then you should annotate the integration service to inject the OpenShift service serving certificates
 +
 [source,console]
 oc annotate service platform-http-server service.beta.openshift.io/serving-cert-secret-name=cert-from-openshift

e2e/yaks/openshift/monitoring/alerting.feature

@@ -1,4 +1,4 @@
-Feature: Alerts from Camel K are propagated to Openshift Prometheus
+Feature: Alerts from Camel K are propagated to OpenShift Prometheus
 
   Background: Prepare Thanos-ruler URL
     Given URL: https://thanos-ruler.openshift-user-workload-monitoring:9091

helm/camel-k/crds/crd-integration-platform.yaml

@@ -310,7 +310,7 @@ spec:
                 type: object
               cluster:
                 description: what kind of cluster you're running (ie, plain Kubernetes
-                  or Openshift)
+                  or OpenShift)
                 type: string
               configuration:
                 description: list of configuration properties to be attached to all
@@ -1868,7 +1868,7 @@ spec:
                 type: object
               cluster:
                 description: what kind of cluster you're running (ie, plain Kubernetes
-                  or Openshift)
+                  or OpenShift)
                 type: string
               conditions:
                 description: which are the conditions met (particularly useful when

install/Makefile

@@ -335,7 +335,7 @@ endif
 # Customizes the samples patches for openshift
 #
 .platform-openshift-patch:
-	@sed -i 's/.*profile:.*/  profile: Openshift/' $(SAMPLES)/$(INT_PLATFORM_PATCH).$(YAML)
+	@sed -i 's/.*profile:.*/  profile: OpenShift/' $(SAMPLES)/$(INT_PLATFORM_PATCH).$(YAML)
 
 #
 # Install the integration platform

pkg/apis/camel/v1/integrationplatform_types.go

@@ -27,7 +27,7 @@ import (
 
 // IntegrationPlatformSpec defines the desired state of IntegrationPlatform
 type IntegrationPlatformSpec struct {
-	// what kind of cluster you're running (ie, plain Kubernetes or Openshift)
+	// what kind of cluster you're running (ie, plain Kubernetes or OpenShift)
 	Cluster IntegrationPlatformCluster `json:"cluster,omitempty"`
 	// the profile you wish to use. It will apply certain traits which are required by the specific profile chosen.
 	// It usually relates the Cluster with the optional definition of special profiles (ie, Knative)
@@ -177,7 +177,7 @@ const (
 	IntegrationPlatformBuildPublishStrategyKaniko IntegrationPlatformBuildPublishStrategy = "Kaniko"
 	// IntegrationPlatformBuildPublishStrategyS2I uses the Source to Images (S2I) feature
 	// (https://docs.openshift.com/container-platform/4.9/openshift_images/create-images.html#images-create-s2i_create-images)
-	// provided by an Openshift cluster in order to create and push the images to the registry. It is the default choice on Openshift cluster
+	// provided by an OpenShift cluster in order to create and push the images to the registry. It is the default choice on OpenShift cluster
 	IntegrationPlatformBuildPublishStrategyS2I IntegrationPlatformBuildPublishStrategy = "S2I"
 	// IntegrationPlatformBuildPublishStrategySpectrum uses Spectrum project (https://github.com/container-tools/spectrum)
 	// in order to push the incremental images to the image repository. It is the default choice on vanilla Kubernetes cluster

pkg/apis/camel/v1/trait/route.go

@@ -19,7 +19,7 @@ package trait
 
 // The Route trait can be used to configure the creation of OpenShift routes for the integration.
 //
-// The certificate and key contents may be sourced either from the local filesystem or in a Openshift `secret` object.
+// The certificate and key contents may be sourced either from the local filesystem or in a OpenShift `secret` object.
 // The user may use the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference a certificate stored in a `secret`.
 // Parameters ending in `-secret` have higher priorities and in case the same route parameter is set, for example: `tls-key-secret` and `tls-key`,
 // then `tls-key-secret` is used.

pkg/trait/pull_secret.go

@@ -70,17 +70,17 @@ func (t *pullSecretTrait) Configure(e *Environment) (bool, error) {
 			}
 		}
 		if t.ImagePullerDelegation == nil {
-			var isOpenshift bool
+			var isOpenShift bool
 			if t.Client != nil {
 				var err error
-				isOpenshift, err = openshift.IsOpenShift(t.Client)
+				isOpenShift, err = openshift.IsOpenShift(t.Client)
 				if err != nil {
 					return false, err
 				}
 			}
 			isOperatorGlobal := platform.IsCurrentOperatorGlobal()
 			isKitExternal := e.Integration.GetIntegrationKitNamespace(e.Platform) != e.Integration.Namespace
-			needsDelegation := isOpenshift && isOperatorGlobal && isKitExternal
+			needsDelegation := isOpenShift && isOperatorGlobal && isKitExternal
 			t.ImagePullerDelegation = &needsDelegation
 		}
 	}

release.adoc

@@ -245,7 +245,7 @@ The https://github.com/k8s-operatorhub/community-operators/[OperatorHub] downstr
 of Camel K, so that it can be easily installed on platforms that support Operator Hub.
 
 The https://github.com/redhat-openshift-ecosystem/community-operators-prod/[Embedded OperatorHub in OpenShift and OKD] downstream channel should be synced to publish the latest version
-of Camel K, so that it can be easily installed on Openshift and OKD.
+of Camel K, so that it can be easily installed on OpenShift and OKD.
 
 You can create the bundle using the `make bundle` command.
 

resources/traits.yaml

@@ -1067,7 +1067,7 @@ traits:
   - OpenShift
   description: 'The Route trait can be used to configure the creation of OpenShift
     routes for the integration. The certificate and key contents may be sourced either
-    from the local filesystem or in a Openshift `secret` object. The user may use
+    from the local filesystem or in a OpenShift `secret` object. The user may use
     the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference
     a certificate stored in a `secret`. Parameters ending in `-secret` have higher
     priorities and in case the same route parameter is set, for example: `tls-key-secret`