openshift-knative/knative-serving-operator

OBSOLETE: moved to https://github.com/knative/serving-operator

knative-serving-operator's Issues

Existing Knative Serving instanaces should configure logUrl template automatically

Since #44, Knative Serving Operator is able to automatically configure RevisionlogURL template in config-observability. However, if openshift-logging/ClusterLogging is started after Knative Serving, Knative Serving Operator does not get notification about the deployment of ClusterLogging. As a result, logUrl is not configured until global resync which can take hours. Existing Knative Serving instanaces should configure logUrl template automatically when openshift-logging is deployed.
https://jira.coreos.com/browse/SRVKS-219

RBAC issue on OpenShift (cannot list resource "routes")

I realise this is an obsolete repo now but I'm looking to test 0.8.1 of Knative serving installed through an operator on OpenShift 4.2 - and I think this is the best place to get started as the 1.0.0 serverless operator is pulling in 0.7.1.

So I checked out the latest tag here (see my notes at https://github.com/a-roberts/openshift42/blob/master/README.md) and see

adams-mbp:knative-serving-operator aroberts$ kgp
NAME                                           READY     STATUS             RESTARTS   AGE
knative-serving-operator-d5dd55cf8-s2zfg       0/1       CrashLoopBackOff   5          5m57s

Logs show

{"level":"error","ts":1571330062.425114,"logger":"cmd","msg":"","error":"routes.route.openshift.io is forbidden: User \"system:serviceaccount:openshift-pipelines:knative-serving-operator\" cannot list resource \"routes\"

This is even with a modification to include

- apiGroups: ["route.openshift.io"]
  resources: ["routes"]
  verbs:  ["get", "list", "update", "delete", "create", "patch"]

for the clusterrole knative-serving-operator. Any ideas please? I'm confident my RBAC addition's pretty good but it can't be - or something else is stopping this?

Could go.mod and go.sum be committed?

It seems that "go.mod" and "go.sum" are not committed.
When building operator with operator-sdk build each time, the two files are generated and updated.

In my opinion, they should be committed as they're important for version selection.

Automatically set logUrl template when openshfit-logging is installed.

Serving API exposes logUrl in Revision's Status. logUrl can launch visualization app to render logs specific to a Revision. However, logging.revision-url-template must be updated in config-observability (kubectl edit cm config-observability -n knative-serving) before the URL is usable An un-usable URL is shown below.

`host serving-operator]$ k get revision helloworld-8xpcn -n default -o jsonpath='{.status.logUrl}'

http://localhost:8001/api/v1/namespaces/knative-monitoring/services/kibana-logging/proxy/app/kibana#/discover?_a=(query:(match:(kubernetes.labels.knative-dev%2FrevisionUID:(query:'8e104620-b6b6-11e9-bf4f-0aae0e47085c',ty`

When openshift-logging is installed. Kibana hostname is available in openshift route. We should use the host info available and update logURL automatically to improve user experience.

Consider renaming CR kind to "KnativeServing"

I believe, "Install" as a name for the CR is too generic. Currently, its also used by eventing (and Tekton pipeline install operator).

I suggest to rename it to "KnativeServing" and "KnativeEventing" for the corresponding eventing operator.

Why ?

• kubectl get install would need to be always fully qualified with the API group if more than one "install" CR is present (kubectl get installs.serving.knative.de)
• "install" is too generic and is more a verb than a noun like CRs typically are (therefore that singular/plural thing in the CRD definition)
• Other products install operators like for Prometheus or Etcd also call their CR after the product (i.e. "Prometheus" and "Etcd", respectively)
• Its easier to understand a kind: KnativeServing alone then checking the apiVersion: serving.knative.dev/v1alpha1 always together with the kind.

If we want to change that name, we should do it ASAP, i.e. before going to upstream with it.