gulp serve is wiring incorrect route to bower_components....missing '/app' in serve.js

[schugh]

I did a simple clone, npm install and gulp serve but I get a blank screen when I launch localhost:9090.

Dev tools shows that my served app can't find any resources in bower_components.

I changed line 75 from: '/bower_components': conf.paths.bowerComponents to: '/app/bower_components': conf.paths.bowerComponents

...and things started working. Is this the intended place to specify the missing path-part?

[bryk]

Sadly, I cannot reproduce this. Things work on my workstation.

What's your setup? OS? Browser? Can you give stacktraces?

[cheld]

I cannot reproduce it also. Are you sure a Kubernetes cluster is running on port 8080? You can create one with gulp local-up-cluster in a separate terminal. Please follow the README.md

[schugh]

OS: OSX 10.11.2 Browser: Chrome 47.0.2526.80 (64-bit) NPM: 3.3.12 Node: 5.1.1 Gulp: 3.9.0

I didn't end up using the locally packaged cluster. I'm new to docker and started by following another procedure to standup a local cluster.

To start off, I got the project with a git clone.

Outside of the dashboard directory, I created a docker-compose.yml with the following:

etcd: image: gcr.io/google_containers/etcd:2.0.9 net: host command: ['/usr/local/bin/etcd', '--bind-addr=0.0.0.0:4001', '--data-dir=/var/etcd/data']

apiserver: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "apiserver", "--service-cluster-ip-range=172.17.17.1/24", "--address=127.0.0.1", "--etcd_servers=http://127.0.0.1:4001", "--cluster_name=kubernetes", "--v=2"]

controller: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "controller-manager", "--master=127.0.0.1:8080", "--v=2"]

scheduler: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "scheduler", "--master=127.0.0.1:8080", "--v=2"]

kubelet: image: geku/hyperkube:v1.0.1 net: host command: ['/hyperkube', 'kubelet', '--api_servers=http://127.0.0.1:8080', '--v=2', '--address=0.0.0.0', '--enable_server'] volumes:

• /var/run/docker.sock:/var/run/docker.sock

proxy: image: geku/hyperkube:v1.0.1 net: host command: ['/hyperkube', 'proxy', '--master=http://127.0.0.1:8080', '--v=2'] privileged: true

I use the Docker Quickstart Terminal to start all my terminal instances from this point.

I run:

$> docker-compose up

Things fire up and start getting a steady stream of output.

In a separate window, I create an SSH tunnel to allow access to the cluster/API with command:

$> docker-machine ssh default -L 8080:localhost:8080

In a third window, navigate to the dashboard directory and I run gulp serve.

There aren't any error in the console and the browser window does NOT pop up automatically is it seems to be the default configuration. I fire up chrome and navigate to localhost:9090. I get the "Connected to BrowserSync" message in the top right corner and then nothing...the screen is blank. If I launch chrome dev tools, I notice that all the angular js/css resources GETs are throwing 404s.

I then went to inspect the index.html generated by gulp for serve in the .tmp directly. I noticed that all the references are to /app/bower_components. I then checked line 75 of serve.js and saw that all route requests to /bower_components are being mapped, and not /app/bower_components. I changed the line and the console loads.

There still seems to be some other stuff that's not right though: If i I click on Dashboard Tour on the home page, I get the Error: Could not resolve '#' from state 'zero' in chrome dev tools. If I do click on Deploy an App, it does load the new app form as expected.

Just for fun, I ran gulp local-up-cluster and it hangs for me on 'waiting for kubernetes cluster on localhost:8080' [10:15:07] Requiring external module babel-core/register [10:15:08] Using gulpfile ~/Projects/pongoose-ops/kubernetes/dashboard/gulpfile.babel.js [10:15:08] Starting 'clone-kubernetes'... [10:15:08] Starting 'download-kubectl'... [10:15:08] Starting 'kill-cluster'... [10:15:08] Finished 'kill-cluster' after 82 μs [10:15:08] Starting 'wait-for-cluster'... [10:15:09] Waiting for a Kubernetes cluster on localhost:8080... [10:15:19] Waiting for a Kubernetes cluster on localhost:8080... [10:15:29] Waiting for a Kubernetes cluster on localhost:8080... [10:15:39] Waiting for a Kubernetes cluster on localhost:8080... [10:15:49] Waiting for a Kubernetes cluster on localhost:8080... [10:16:00] Waiting for a Kubernetes cluster on localhost:8080... [10:16:10] Waiting for a Kubernetes cluster on localhost:8080... [10:16:20] Waiting for a Kubernetes cluster on localhost:8080... [10:16:30] Waiting for a Kubernetes cluster on localhost:8080... [10:16:40] Waiting for a Kubernetes cluster on localhost:8080... [10:16:50] Waiting for a Kubernetes cluster on localhost:8080... [10:17:00] Waiting for a Kubernetes cluster on localhost:8080... [10:17:10] Waiting for a Kubernetes cluster on localhost:8080... [10:17:20] Waiting for a Kubernetes cluster on localhost:8080... [10:17:30] Waiting for a Kubernetes cluster on localhost:8080... [10:17:40] Waiting for a Kubernetes cluster on localhost:8080... [10:17:50] Waiting for a Kubernetes cluster on localhost:8080... [10:18:00] Waiting for a Kubernetes cluster on localhost:8080... [10:18:10] Waiting for a Kubernetes cluster on localhost:8080... [10:18:20] Waiting for a Kubernetes cluster on localhost:8080... [10:18:30] Waiting for a Kubernetes cluster on localhost:8080...

I hope this helps some. I'm not ready with my infrastructure to really start playing with Kubernetes yet but I'm looking forward to ironing out a couple of these issues and playing around with it.

Thanks for all the help in advance -Samir

On Wed, Dec 9, 2015 at 3:50 AM, Christoph Held notifications@github.com wrote:

I cannot reproduce it also. Are you sure a Kubernetes cluster is running on port 8080? You can create one with gulp local-up-cluster in a separate terminal. Please follow the README.md

— Reply to this email directly or view it on GitHub https://github.com/kubernetes/dashboard/issues/144#issuecomment-163199604 .

[schugh]

Oh, and by the way, i accidentally swapped the order of two of the step. I create the SSH tunnel first and then run docker-compose up....

On Wed, Dec 9, 2015 at 10:27 AM, Samir Chugh samir.chugh@gmail.com wrote:

OS: OSX 10.11.2 Browser: Chrome 47.0.2526.80 (64-bit) NPM: 3.3.12 Node: 5.1.1 Gulp: 3.9.0

I didn't end up using the locally packaged cluster. I'm new to docker and started by following another procedure to standup a local cluster.

To start off, I got the project with a git clone.

Outside of the dashboard directory, I created a docker-compose.yml with the following:

etcd: image: gcr.io/google_containers/etcd:2.0.9 net: host command: ['/usr/local/bin/etcd', '--bind-addr=0.0.0.0:4001', '--data-dir=/var/etcd/data']

apiserver: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "apiserver", "--service-cluster-ip-range=172.17.17.1/24", "--address=127.0.0.1", "--etcd_servers=http://127.0.0.1:4001", "--cluster_name=kubernetes", "--v=2"]

controller: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "controller-manager", "--master=127.0.0.1:8080", "--v=2"]

scheduler: image: geku/hyperkube:v1.0.1 net: host command: ["/hyperkube", "scheduler", "--master=127.0.0.1:8080", "--v=2"]

kubelet: image: geku/hyperkube:v1.0.1 net: host command: ['/hyperkube', 'kubelet', '--api_servers=http://127.0.0.1:8080', '--v=2', '--address=0.0.0.0', '--enable_server'] volumes:

• /var/run/docker.sock:/var/run/docker.sock

proxy: image: geku/hyperkube:v1.0.1 net: host command: ['/hyperkube', 'proxy', '--master=http://127.0.0.1:8080', '--v=2'] privileged: true

I use the Docker Quickstart Terminal to start all my terminal instances from this point.

I run:

$> docker-compose up

Things fire up and start getting a steady stream of output.

In a separate window, I create an SSH tunnel to allow access to the cluster/API with command:

$> docker-machine ssh default -L 8080:localhost:8080

In a third window, navigate to the dashboard directory and I run gulp serve.

There aren't any error in the console and the browser window does NOT pop up automatically is it seems to be the default configuration. I fire up chrome and navigate to localhost:9090. I get the "Connected to BrowserSync" message in the top right corner and then nothing...the screen is blank. If I launch chrome dev tools, I notice that all the angular js/css resources GETs are throwing 404s.

I then went to inspect the index.html generated by gulp for serve in the .tmp directly. I noticed that all the references are to /app/bower_components. I then checked line 75 of serve.js and saw that all route requests to /bower_components are being mapped, and not /app/bower_components. I changed the line and the console loads.

There still seems to be some other stuff that's not right though: If i I click on Dashboard Tour on the home page, I get the Error: Could not resolve '#' from state 'zero' in chrome dev tools. If I do click on Deploy an App, it does load the new app form as expected.

Just for fun, I ran gulp local-up-cluster and it hangs for me on 'waiting for kubernetes cluster on localhost:8080' [10:15:07] Requiring external module babel-core/register [10:15:08] Using gulpfile ~/Projects/pongoose-ops/kubernetes/dashboard/gulpfile.babel.js [10:15:08] Starting 'clone-kubernetes'... [10:15:08] Starting 'download-kubectl'... [10:15:08] Starting 'kill-cluster'... [10:15:08] Finished 'kill-cluster' after 82 μs [10:15:08] Starting 'wait-for-cluster'... [10:15:09] Waiting for a Kubernetes cluster on localhost:8080... [10:15:19] Waiting for a Kubernetes cluster on localhost:8080... [10:15:29] Waiting for a Kubernetes cluster on localhost:8080... [10:15:39] Waiting for a Kubernetes cluster on localhost:8080... [10:15:49] Waiting for a Kubernetes cluster on localhost:8080... [10:16:00] Waiting for a Kubernetes cluster on localhost:8080... [10:16:10] Waiting for a Kubernetes cluster on localhost:8080... [10:16:20] Waiting for a Kubernetes cluster on localhost:8080... [10:16:30] Waiting for a Kubernetes cluster on localhost:8080... [10:16:40] Waiting for a Kubernetes cluster on localhost:8080... [10:16:50] Waiting for a Kubernetes cluster on localhost:8080... [10:17:00] Waiting for a Kubernetes cluster on localhost:8080... [10:17:10] Waiting for a Kubernetes cluster on localhost:8080... [10:17:20] Waiting for a Kubernetes cluster on localhost:8080... [10:17:30] Waiting for a Kubernetes cluster on localhost:8080... [10:17:40] Waiting for a Kubernetes cluster on localhost:8080... [10:17:50] Waiting for a Kubernetes cluster on localhost:8080... [10:18:00] Waiting for a Kubernetes cluster on localhost:8080... [10:18:10] Waiting for a Kubernetes cluster on localhost:8080... [10:18:20] Waiting for a Kubernetes cluster on localhost:8080... [10:18:30] Waiting for a Kubernetes cluster on localhost:8080...

I hope this helps some. I'm not ready with my infrastructure to really start playing with Kubernetes yet but I'm looking forward to ironing out a couple of these issues and playing around with it.

Thanks for all the help in advance -Samir

On Wed, Dec 9, 2015 at 3:50 AM, Christoph Held notifications@github.com wrote:

I cannot reproduce it also. Are you sure a Kubernetes cluster is running on port 8080? You can create one with gulp local-up-cluster in a separate terminal. Please follow the README.md

— Reply to this email directly or view it on GitHub https://github.com/kubernetes/dashboard/issues/144#issuecomment-163199604 .

[cheld]

It is a frequent mistake to forget to setup a cluster on localhost:8080, so I asked. 'gulp local-up-cluster' hangs the first time for 5-50min (depending on network & hardware) to clone and build the binaries. You probably killed it before clone was finished. The other problem we must analyse.

[bryk]

It should not be a problem with the cluster. Can you give stacktraces from your browser and output of the command find <your-repository-root>/.tmp and find <your-repository-root>/dist?

[tdeheurles]

I'm not sure where you are running these things.

I understand that you have installed npm locally (on your mac) and run kubernetes on docker (in the linux VM as it's the only way) ? Seems that it's not talking of the same localhost.

Try to change to 192.168.99.100 (or the result of docker-machine url default). That where you're cluster is.

[bryk]

Closing as stale.