Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Story Points:7
-
Epic Link:
-
Team:SQuaRE
Description
This story captures the current issues deploying squash with minikube.
Things that must be revisited:
- The mechanism to add new entries in /etc/hosts. Currently this is being done in the Dockerfile which is not ideal. We should configure the pod using hostAliases, after tests kubernetes deployment does not accept this configuration.
- nodePort is being assigned dynamically when the service is created. However, the squash-bokeh service needs the squash-dash host and port for the --allow-websocket-origin option when running the bokeh serve while the squas-dash service needs the squash-bokeh URL to embed the bokeh scripts. This causes a "chicken and egg" problem when initializing the services. A solution for that is to make the nodePort static when the service is created.
For the moment we deciced to drop minikube support and carry on with development and production deployments on GKE.
Attachments
Issue Links
- relates to
-
- Done
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link |
|
| Description |
This story captures the current issues deploying squash with minikube.
Things that must be revisited: - The mechanism to add new entries in /etc/hosts. Currently this is being done in the {{Dockerfile}} which is not ideal. We should configure the pod using {{hostAliases}}, not clear if the kubernetes deployment configuration. https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/ - {{nodePort}} is being aessigned dynamically when the service is created. However, the {{squash-bokeh}} service needs the {{squash-dash}} host and port for the {{--allow-websocket-origin}} option when running the {{bokeh serve}} while the {{squas-dash}} service needs the {{squash-bokeh}} URL to embed the bokeh scripts. This causes a "chicken and egg" problem when initializing the services. A solution for that is to make the {{nodePort}} static when the service is created. For the moment we deciced to drop minikube support and carry on with {{development}} and {{production}} deployments on GKE. |
This story captures the current issues deploying squash with minikube.
Things that must be revisited: - The mechanism to add new entries in /etc/hosts. Currently this is being done in the {{Dockerfile}} which is not ideal. We should configure the pod using {{hostAliases}}, after tests kubernetes deployment does not accept this configuration. https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/ - {{nodePort}} is being assigned dynamically when the service is created. However, the {{squash-bokeh}} service needs the {{squash-dash}} host and port for the {{--allow-websocket-origin}} option when running the {{bokeh serve}} while the {{squas-dash}} service needs the {{squash-bokeh}} URL to embed the bokeh scripts. This causes a "chicken and egg" problem when initializing the services. A solution for that is to make the {{nodePort}} static when the service is created. For the moment we deciced to drop minikube support and carry on with {{development}} and {{production}} deployments on GKE. |
| Resolution | Done [ 10000 ] | |
| Status | To Do [ 10001 ] | Won't Fix [ 10405 ] |
| Story Points | 7 |
The main limitation of a local deployment with minikube is to manage multiple services running on different ports.
TLS termination and cross domain configuration require actual names for the services and it is not possible to map names to <minikube ip>:<port> in /etc/hosts
I've tried things like configure a local proxy and use a tool called ergo(https://github.com/cristianoliveira/ergo) that allows you to map names to <ip address>:<port> but
one has to do that inside the containers too thus this approach didn't work.