Accessing the UI

[mhoad]

Hi,

Sorry I know this is going to be an incredibly stupid question but I am much more marketer than I am developer so please stay with me here :)

I've gone ahead and run the appropriate install commands on a brand new Ubuntu 16.04 x64 VPS (with Google Cloud if that is of any relevance).

Everything seems to be working well so far and running curl -i http://localhost:8080/api/v1/ping in my SSH terminal works as expected. What I can't figure out however is how do I access the web based UI.

Going to http://$IP_OF_MY_VPS_BOX:8080 simply times out.

Assuming this is some kind of firewall issue? Any thoughts? What am I missing?

[mhoad]

Just wanted to post a quick update / feedback.

Updating the firewall rules to allow connections to port 8080 did indeed help. However it gets me this:

Still no UI unfortunately. Also just in terms of a possible update to the bootstrap script. Would it make sense to check if the appropriate ports are open and if not open them so that the web interface is available?

[longdogz]

I think you are on the right track, that it is access to the machine from outside the machine that is the problem. A couple things to try would be to curl against http://localhost:8080 from your ssh terminal, just to check if the UI is in the right place and being served. If that seems ok (you get back some HTML), I would try the same ping URL from the browser, replacing localhost with the ip you referenced earlier. If that is equally unsuccessful, maybe try a curl -i from a terminal window off the machine, like where you're running your browser. That might give you more info about the access problem.

[mhoad]

@longdogz Thanks for the reply. Can confirm that using curl http://localhost:8080 shows the same HTML as shown in the picture above (i.e. a directory containing swagger) but can't seem to find the actual UI at all unfortunately.

[longdogz]

Ok, I'll have to do some investigation to see why you might be getting that. What commands did you use for the install and were there any errors?

[mhoad]

Full extend of commands on a brand new Ubuntu 16.04 x64 VPS are as follows:

% sudo apt-get install git
% git clone https://github.com/intuit/wasabi.git
% cd wasabi
% ./bin/wasabi.sh bootstrap
% sudo reboot
% ./bin/wasabi.sh build start

Followed by testing that it was generally working using: % curl -i http://localhost:8080/api/v1/ping

Opened up the 8080 port on the machine and attempted to visit the URL in the browser on port 8080 when I just got the swagger directory

Once more attempted to reboot the VPS and then rerun % ./bin/wasabi.sh start

Same results unfortunately. No error messages shown but running commands such as % ./bin/wasabi.sh resource:ui do produce an error as shown below:

[longdogz]

So, you did the build on the Ubuntu machine. To build the UI, that would need to, at some point, do a command like this:

cd ./modules/ui && npm install && bower install && grunt build

Which is really four separate commands. So you cd to the modules/ui directory within your clone of the wasabi repo. In there you run the command npm install. That should use the package.json file (in that directory) to pull down a bunch of dependent JavaScript libraries, mainly for use in building the UI. The next command, bower install, pulls in some JavaScript that is used at runtime by the UI application and will be packaged up and served with the wasabi UI code. Finally, the grunt build will do that packaging (and a bunch of other stuff) and will produce a dist directory beneath the ui directory.

If you run into errors with any of that (it looks like you are getting npm errors from your screen shot), you would need to determine what the problems are and fix them. Unfortunately, I am not sure what the problem is, but perhaps someone in the community might be? @jwtodd ? 😄 It is possible, since it is complaining that you don't have "make", that you are missing some basic tools for software development (or that they are not on your "path") which maybe our scripts assume you would have? While npm mainly downloads JavaScript libraries, sometimes those are just wrappers around programs (like C programs) and if those aren't existing, it will try to build them. That might be what is failing. If you google the failures, you might get a clue as to what to do to fix your system so the build will work.

Sorry, but I don't have your system available and am not sure what might be going wrong with the npm install.

If you can get that fixed, though, you should be able to try running the other commands. When they complete, you will have several files and directories in the modules/ui/dist directory. Those basically get copied to the /usr/local/wasabi-main-1.0.20170113205431-SNAPSHOT-development/content/ui/dist directory on your server system (which is then served by the same Jetty server that serves the REST API, hence the :8080). If you can successfully build the UI dist directory and copy those files, the UI should run. I think if you can fix the problems with your UI build, you could also just run one of those wasabi.sh commands, too, like re-do ./bin/wasabi.sh build start ?

[AndreaSuckro]

Maybe this helps: sudo apt-get install build-essential. I found a stackoverflow question that at least looked kind of similar to your error and is also dealing with an ubuntu system: npm failed

[mhoad]

Just as another update. On a brand new box I made sure to run the following first

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential

This does get me a working login screen at http://$IP_OF_MY_VPS_BOX:8080/dist

However, attempting to sign in gets me this:

Despite having a functional server as far as I can tell:

[longdogz]

OK, I actually probably know this one. 😄

The UI is a JavaScript, single-page app written in Angular JS. It uses REST APIs in the Wasabi server to implement the UI, e.g., to retrieve a list of experiments, create experiments, etc. In order to do that, it needs to know the URL of the REST server. It determines that from a configuration file. That file is at (in the deployment) at /usr/local//content/ui/dist/scripts/config.js . It contains some JavaScript that sets a constant named "apiHostBaseUrlValue" to a value like "http://localhost:8080/api/v1". If you change that value to something like "http://$IP_OF_MY_VPS_BOX/api/v1", then the UI should work fine.

BTW, in order to see why the UI wasn't working, you could load it into Chrome (you shouldn't need the /dist, just http://$IP_OF_MY_VPS_BOX) and then right click on the window and choose "Inspect" to get the debugger. In the console, you should see errors about being unable to find the server http://localhost:8080.

[longdogz]

FYI, one of the engineers here reproduced part of your problem, that is, the /dist thing. Basically, you should get the UI when you go to http://localhost:8080 and not at http://localhost:8080/dist/ . We are investigating why that is happening. There would still need to be a change in the config.js file for the UI to work, but it still won't work even if you make that change because of the /dist thing. We'll let you know what we find out.

[Aelmgren]

Ran into the same issue, also using ubuntu 16.04 on google cloud, but was able to fix it with one file change and a rebuild.

You'll need to change the 'apiHostBaseUrlValue' in /modules/ui/constants.json to your server ip, since it's set as default to "http://localhost:8080/api/v1" which causes the angular app to send all requests to localhost rather that the public server ip. Then you can rebuild with the ./bin/wasabi.sh script with stop, remove, build, and start. This should probably be put into part of a dev/prod workflow, not sure if this is already being considered.

[longdogz]

Thank you for describing so clearly how to change the backend API setting for the UI, which is necessary when you are not accessing the server vial localhost:8080 , the default.

The main reason we use the constants.json and a build to configure the backend API is so that you have the flexibility to not be serving the UI from exactly the same location as the REST APIs. For example, you might want to hit the UI on port 80 and the API on port 8080. Or you might even want to serve the UI from a totally different server, e.g., during development, I use the "grunt serve" command, which serves the UI on localhost:9000 , but I want to hit the REST API server in docker at localhost:8080 .

It is for these reasons that we don't have a default, for example, of using the window.location to determine the URL from which the UI code was served and then assume that is the URL of the REST API. That would definitely solve this problem (running the Wasabi servers in a VM and then needing to load the UI and hit the API at some IP address URL), but we wouldn't want it to be the ONLY way to configure the backend API URL.

Maybe we could figure out a way to use the URL from which the UI code was served as the REST API URL, but then have a way to override that when necessary? I'll think about that, but would also accept any suggestions.

BTW, just for complete disclosure, changing the constants.json file and then doing a UI build is one way to change the backend URL used by the UI. What the grunt build does with that file is to actually produce a file at modules/ui/app/scripts/config.js that has that information in it and that is picked up when the UI loads in the browser. An alternative way to change the configuration, if, for example, you don't want to do the re-build to do it, is after you have deployed the UI, just find the config.js file and change it to have the correct value.

On Mon, Jan 23, 2017 at 2:41 PM Anders Elmgren notifications@github.com wrote:

Ran into the same issue, also using ubuntu 16.04 on google cloud, but was able to fix it with one file change and a rebuild.

You'll need to change the 'apiHostBaseUrlValue' in /modules/ui/constants.json to your server ip, since it's set as default to " http://localhost:8080/api/v1" which causes the angular app to send all requests to localhost rather that the public server ip. Then you can rebuild with the ./bin/wasabi.sh script with stop, remove, build, and start. This should probably be put into part of a dev/prod workflow, not sure if this is already being considered.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/intuit/wasabi/issues/163#issuecomment-274641272, or mute the thread https://github.com/notifications/unsubscribe-auth/AHXiAzw5KEFUnLx6fS0oVycwthETpxniks5rVSyAgaJpZM4Log2_ .

[esprush]

Ran into the issue where UI was appearing in http://localhost:8080/dist instead of http://localhost:8080.

following change will fix it.(https://github.com/intuit/wasabi/pull/194) "wasabi.sh build" must be run once after making this change.

[wukaiyuan]

I ran into this problem on my Mac and when doing the

cd ./modules/ui && npm install && bower install && grunt build

command recommended by @longdogz It would keep failing on grunt build due to some old libraries and the version of node used by brew (if you keep it updated) being incompatible.

I fixed this by going through every package in package.json and typing

npm install package name

It updated each package to the latest and then when I ran grunt build it worked.

Finally from the wasabi directory:

./bin/wasabi.sh build start

worked for me and the UI loaded. Hopefully that helps.

[longdogz]

I'm not sure if I mentioned this earlier, but the "npm install" and "bower install" install things locally that are not reinstalled when you do a grunt build, or even if you do another npm install or bower install (which are done by the wasabi.sh at times). There are possible problems, over time, where there are inconsistencies between what you installed before and new things added to package.json. If you are having problems with the installs or the grunt build, one thing to try is to do:

cd modules/ui
rm -rf node_modules
rm -rf app/bower_components

And then to try the grunt build again.

In case you're wondering, the grunt clean doesn't delete those directories, partly because grunt needs what is in node_modules and partly because usually you don't need/want to re-do them every time you build.

[ctrlaltdylan]

I've pinpointed what the problem seems to be, the bower install is not actually creating the app/bower_components directory and dependencies. I think it's related to https://github.com/bower/bower/issues/50

I'm trying to run through the bower dependencies and find which one is causing the the entire bower_components not to be created. Because there are no bower_components created, when you run grunt build the task fails and doesn't actually create the dist.

[smn]

@ctrlaltdylan @longdogz I'm having the same issue. Any known work arounds yet?

[kushaljshah]

Adding to @wukaiyuan's response, similar problem for me was related to bower.

bower ESUDO         Cannot be run with sudo
Additional error details:
Since bower is a user command, there is no need to execute it with superuser permissions.
If you're having permission errors when using bower without sudo, please spend a few minutes learning more about how your system should work and make any necessary repairs.

http://www.joyent.com/blog/installing-node-and-npm
https://gist.github.com/isaacs/579814

You can however run a command with sudo using "--allow-root" option

Running the following commands in sequence solved the issue

npm install
bower install --allow-root
grunt build
./bin/wasabi.sh build stop
./bin/wasabi.sh start

[ahmettahasakar]

Hello,

I had the initial "only swagger" problem. Now I got it to working. Thank you. However, when packing, it doesn't pack the ui. I get "only swagger" again. How do I make it package the ui as well?

Thank you

[shahbazahmad4467]

grunt build ERROR Running "concurrent:dist" (concurrent) task Warning: (node:21734) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead. Use --force to continue.

Aborted due to warnings.

Worked fine with grunt build --force

But abort when wasabi.sh changed to grunt build --force not sure why?

Thanks