UI support changes

[lavalamp]

These items block further progress on the UI. I'm merging #7056 so we can make progress, but it is in general not yet safe to accept UI changes because we are missing various supporting functionality: we don't have enough automated checks in place. Please copy me (@lavalamp) on all UI changes.

P0 items: (I'm unlikely to accept UI changes that aren't working towards fixing one of these issues)

• Travis/shippable to run the karma tests.
• Travis/shippable to run the protractor tests.
• Test to verify that go bin data matches the files output by npm install; npm start (i.e., hack/build-ui.sh has been run)
• Test to verify that npm install; npm start has been correctly run (the packaged js/css/html files have been assembled from source)
• www/README.md needs major changes:
  • Make it clear how to build files for inclusion in apiserver binary.
  • Make it clear how to run in standalone mode.
  • Make it clear that these are two distinct modes.
  • Either remove all mention of kubectl, or make it clear that there's a third operational mode, where kubectl proxies your cluster's master, and you run the UI locally pointed at that proxy.
  • work item: make development.json auto-generated from your .kube/config file; actually provide a separate command for generating the files for inclusion in apiserver that doesn't use development.json.
  • Provide more detailed installation instructions.

P1 items:

• UI to be served from a pod, not from apiserver.

[jackgr]

Likewise please copy @jackgr.

[yllierop]

I've made a partial pass at updating the README it still needs a bit more work.

[djvirgen]

I'll be taking a look at some of the P0's (I'm a friend of @preillyme)

[yllierop]

Thanks @djvirgen

[yllierop]

@lavalamp I'm not sure what the best way to handle the shippable configuration will be. Based on what I was reading last night it didn't look like you can nest configurations? But we need something like: https://github.com/lucassus/angular-seed/blob/master/shippable.yml for the Web UI. I'm curious what are your thoughts? Also @djvirgen do you have any experience with this?

[lavalamp]

@preillyme I'm not sure, but you can try to modify our existing .yml file to install both go and ui stuff, and send a (WIP) PR to see what shippable does with it.

[yllierop]

Okay @lavalamp seems like a plan. Maybe @avinci could give some process guidance as well?

[avinci]

@preillyme what configurations would you like to nest? xvfb?

[yllierop]

@avinci yeah basically need to be able to test the Web UI https://github.com/GoogleCloudPlatform/kubernetes/tree/master/www and the main Go based Kubernetes code separately. We currently use xvfb with the chrome driver for various tests.

[yllierop]

I've been working on getting everything working in a Docker container for testing the WebUI.

Just wanted to share my Docker container and share some notes on using it.

wget https://kismatic.io/kubernetes_webui.tar.gz
    SHA1(kubernetes_webui.tar.gz)= 47018c936ee69b9d4636df2b272ceee7f05b8c2c
gunzip kubernetes_webui.tar.gz
docker load < kubernetes_webui.tar
docker run -t -i kubernetes:webui /bin/bash
# Xvfb :99 -screen 0 1024x768x16 &> xvfb.log &
# export DISPLAY=:99.0
# google-chrome
# ^Z
# bg
# su -l kubernetes
$ cd kubernetes/www/master/
$ npm start
^C
$ karma start karma.conf.js

[avinci]

@preillyme, you can do this by starting a kube service inside the container on a port and then starting your protractor service to test it on an another.

We have a sample project that does this using node and selenium. server.js starts up a web server, in this case can be a kube master and then its using nightwatch to run tests on it.

https://github.com/shippableSamples/sample_node_selenium

does this help?

We are also working on a kube based build clusters which will allow doing this cross containers in the next 3-4 weeks which should make it even easier.

I am traveling and might be delayed in responding. Can we do a quick 10 minute hangout so that I understand this better if I am off base here.

[bgrant0607]

Additional issues:

• overall unintuitive and mostly broken behavior
• focus doesn't change with mouse movement in menu
• option dots don't do anything
• clicking dashboard title doesn't do anything, either
• clicking on Kubernetes produces 404

[bgrant0607]

And the starting URL isn't discoverable.

[bcbroussard]

@bgrant0607 I'm working on cleaning up these issues and updating documentation.

• overall unintuitive and mostly broken behavior

I'll add back breadcrumb functionality which was in an earlier version to help with navigation

• option dots don't do anything

These were a placeholder included for future functionality and to serve as an example for other component developers. We aren't using them right now so I'll be disabling them.

• focus doesn't change with mouse movement in menu
• clicking dashboard title doesn't do anything, either
• clicking on Kubernetes produces 404

The last 3 are all straightforward html/css changes which I will get to today/tomorrow.

[jackgr]

These issues impact the Graph tab, which was developed concurrently with the chrome and Dashboard tab, and will be submitted shortly. It follows the model that the UI can be extended by adding tabs. However, this model only works well if the chrome is stable, usable and discoverable.

[bgrant0607]

@bcbroussard Thanks. In what timeframe? We're pushing hard towards our 1.0 release candidate.

[yllierop]

@bgrant0607: You can get to the WebUI at the following url: /static/app/#/

I typically test locally with the following flow:

git clone git@github.com:GoogleCloudPlatform/kubernetes.git
cd kubernetes
hack/local-up-cluster.sh
then navigating to: http://127.0.0.1:8080/static/app/#/

[jackgr]

After discussion with @preillyme, it turns out that most, if not all, of these issues were created by a late commit (https://github.com/kubernetes-ui/kubernetes-ui-private/commit/3b46bc4cd74b9088c08e7c102abcd658edd2d597) from one of our team members, which did a large refactoring and removed some key pieces that should not have been removed. All of the functionality was working when we demo'ed at Galvanize on 2/25. @preillyme is working on restoring the broken functionality.

[bgrant0607]

/static/app/#/ is not very obvious nor intuitive, and listing the top-level path, /static, in the list of supported paths isn't sufficient to find it. We need a simple, intuitive top-level path, such as /www and/or /ui, to at least redirect to the GUI location. A redirect could also work in the case that the UI ran as a separate pod.

[yllierop]

@bgrant0607 I agree with you completely that the top level path is not obvious nor intuitive. I'm happy to have it changed to something a bit more discoverable. It's mostly an artifact of the original Web UI and the fact that it's using AngularJS for the routing.

[bcbroussard]

@lavalamp, @jackgr Travis was updated to support Karma in #7880. PTAL

[yllierop]

@jackgr I've addressed the breadcrumbs issue in #8332

[abonas]

These issues impact the Graph tab, which was developed concurrently with the chrome and Dashboard tab, and will be submitted shortly. It follows the model that the UI can be extended by adding tabs. However, this model only works well if the chrome is stable, usable and discoverable.

Is the graph component going to be merged into this repo?
I had several attempts to add the graph and see its visualizatoins by following the several readme files in this repo (like the one under www, for example), but no luck so far.

[jackgr]

@lavalamp : Looking at the original list above, there are two items that might want to be done differently...

• Test to verify that go bin data matches the files output by npm install; npm start (i.e., hack/build-ui.sh has been run)
• Test to verify that npm install; npm start has been correctly run (the packaged js/css/html files have been assembled from source)

The concern is totally legitimate - i.e., make sure we have current ui bits. However, writing those tests would be hard because neither of the assertions is easy to prove.

Another way to address the concern is to generate the ui bits during a build-cross.sh, instead of checking them into the repository.

So, that begs the question of how to generate the ui bits. The approach i'm considering is to:

• Provide a container with npm, bower, gulp and friends installed (thanks, @preillyme for that suggestion).
• Make build-ui.sh run npm install and gulp in the container with a gulp task that doesn't watch, since that would hang the build, with the environment flag set to production to cause minification, obfuscation, etc., so that running build-ui.sh generates the gulp output and then runs the go binary data file compiler.
• Make build-cross.sh call build-ui.sh.
• Remove the build output from git and add the app directory to .gitignore.

Would you consider that a reasonable replacement for the two tests in question?

[lavalamp]

@jackgr Yes, that's fine, as long as hack/build-go.sh continues to work (i.e., you can build the repo outside of the container, too-- this is important for tools that need to build); in practice this may mean that you keep a dummy UI go file checked in which is replaced by the real UI when you do the "real" release-building process.

[jackgr]

@abonas Yes, the Graph tab will be merged into this repo. Goal is to have it in by 0.18.

[jackgr]

@abonas PR #8716 has been submitted for the graph tab.

[abonas]

Thanks for letting me know
On May 23, 2015 2:01 AM, "Jack Greenfield" notifications@github.com wrote:

@abonas https://github.com/abonas PR #8716
#8716 has been
submitted for the graph tab.

—
Reply to this email directly or view it on GitHub
#7122 (comment)
.

[mikedanese]

UI is gone.