knative
Platform specific configuration for operator
Each platform has some amount of customization required with their installation. It is unclear what approach is ideal to support these types of customization.
@houshengbo kindly documented some of the thoughts on this topic in this doc.
https://docs.google.com/document/d/1OtlkJ8whTgHYTz5rz0lq5mNdDGK_pakG/edit
To add to this, we have 4 additional customizations that we'd need (I can open separate issues for each if needed):
1 - static data update of Kn config maps. We modify the Kn configuration configMaps with static values - meaning we know them in advance of even starting the install process
2 - dynamic data update of Kn config maps. We modify the Kn configuaration configMaps with data that is specific to the cluster but can be retrieved via a normal kubectl get operation. So the data is within the cluster itself. The concrete example for this is we query another configMap to get the domain name.
3 - additional resource processing. We install some other resources as part of the Kn install. Abstractly, this can be thought of as just doing kubectl apply with a custom yaml file. In our case, we are creating an additional istio ingress.
4 - operator dependencies. We have the need to install/process other operators that our Kn one will need. For example, we require istio. So it would be good if there was a way to manage these dependencies - perhaps via OLM
5 - need to be able to have all of the images (operators too) get pulled from private registries