Replies: 2 comments
-
@erictg @nikitawootten Would love to get both of your opinions on this. Currently, the Knative components are deployed onto the cluster independently of megamind. I'm personally leaning towards including the Knative components in megamind so megamind is an "all batteries included" system. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Personally I believe for an MVP we should keep deployment as simple as possible, once we break the deployment into helm charts we can separate the dependencies off. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Synopsis
Currently, the Knative eventing and serving components which act as the backbone for megamind are deployed in their own namespaces. My proposal is to deploy all Knative dependencies under the megamind namespace with the megamind helm chart/terraform module.
Reason for separate namespace
By keeping the Knative dependencies out of megamind, it allows for better resource sharing of clusters with Knative already installed on them. It also allows users to customize Knative to broader use cases.
Reason for including in megamind namespace
By bundling the Knative dependencies into megamind, it gives us better control of tweaking Knative to optimize the performance of megamind. It also greatly simplifies the deployment of megamind for users since they won't have to config Knative themselves.
Beta Was this translation helpful? Give feedback.
All reactions