tendrl / ui

A repository for the front-end artifacts of Tendrl UI

Tendrl API

Table of Contents

• Build Status
• Installation from Source on CentOS 7
  • Deployment Requirements
  • System Setup
  • Install tendrl-api
  • Configuration
• Development Environment
• Test Environment
• Running on Port 80

Build Status

• Unit tests:

• Functional tests:

Installation from Source on CentOS 7

Note	All the commands are run as a regular user that has sudo privileges. The commands are all assumed to be run from a single directory, which by default could be the user’s home directory. If different, the required current directory is indicated in [] before the shell prompt $.

Deployment Requirements

Ensure that etcd is running on a node in the network and is reachable from the node you’re about to install tendrl-api on. Note it’s address and port. In most development setups, both etcd and tendrl-api would reside on the same host.

System Setup

1. Install the build toolchain.

   $ sudo yum groupinstall 'Development Tools'

2. Install Ruby 2.0.0p598.

   $ sudo yum install ruby ruby-devel rubygem-bundler

Install tendrl-api

1. Clone tendrl-api.

   $ git clone https://github.com/Tendrl/tendrl-api.git

2. Install the gem dependencies, either..

   $ cd tendrl-api

   1. everything,

      [tendrl-api] $ bundle install --path vendor/bundle --binstubs vendor/bin

   2. OR development setup only,

      [tendrl-api] $ bundle install --path vendor/bundle --binstubs vendor/bin \
                     --without production

   3. OR production setup only.

      [tendrl-api] $ bundle install --path vendor/bundle --binstubs vendor/bin \
                     --without development test documentation

Note	Using binstubs allows any of the executables to be executed directly from vendor/bin, instead of via bundle exec.

Configuration

To configure the etcd connection information, copy the sample configuration file to the appropriate location and make the necessary changes based on your etcd configuration, as discussed in the Deployment Requirements section.

[tendrl-api] $ cp config/etcd.sample.yml config/etcd.yml

Development Environment

Note	All the commands below are assumed to be run from inside the git checkout directory.

1. Tendrl Definitions:

   The API needs the proper Tendrl definitions yaml file to generate the attributes and actions. You can either download it or use the one from the fixtures to explore the API.

   [tendrl-api] $ cp spec/fixtures/sds/tendrl_definitions_gluster-3.8.3.yaml \
                  config/sds/tendrl_definitions_gluster-3.8.3.yaml

2. Seed the etcd instance (optional):

   The script will seed the etcd instance with mock cluster data and print a cluster uuid which can be used to make API requests.

   [tendrl-api] $ vendor/bin/rake etcd:seed # Seed the local store with cluster

3. Start the development server:

   This server will reload itself when any of the source files are updated.

   [tendrl-api] $ vendor/bin/shotgun

   Note	This makes the development server to be queryable on localhost:9393 by default. Check vendor/bin/shotgun --help to change the ip:port binding.

Test Environment

The test environment does not need the local etcd instance to run the tests.

[tendrl-api] $ vendor/bin/rspec

Running on Port 80

Binding to port 80 requires root permissions. However, tendrl-api runs as a normal user. In order to make the application available on port 80, apache needs to be installed and configured.

1. Install apache

   $ sudo yum install httpd

2. Copy over the sample configuration file and validate it’s syntax.

   Important

   Update the file for your specific host details. The file is commented to point out the suggested changes. The file is configured to connect to the tendrl-api application server on port 9292.

   Important

   Running behind apache makes the API available at http://<hostname>:80/api/. Client applications' (including tendrl frontend’s) configuration needs to be updated to make all API queries behind this endpoint.

   [tendrl-api] $ sudo cp config/apache.vhost.sample \
                  /etc/httpd/conf.d/tendrl.conf
   $ sudo apachectl configtest

3. Update the SELinux configuration to allow apache to make connections.

   $ sudo setsebool -P httpd_can_network_connect 1

4. Run the application via the production server puma, daemonised, listening on port 9292.

   [tendrl-api] $ vendor/bin/puma -e development -d

   Note	It is possible to run both the development and the production servers at the same time, with the production server behind apache. While the production server puma runs, by default, on port 9292; the development server shotgun listens on port 9393.

5. Start apache.

   $ sudo systemctl start httpd.service

ui's Issues

lack of flexible list views on patternfly

Patternfly is provides us with good grid system which is good and suitable in dashboards and other form pages. but, when it comes to our listing pages we faced good number of alignment issues. it should be improved to accomdate our requirement. patternfly can add few more examples that exactly suits our requirements.

[Tracker] selected tool stack

This is the tracker issue for most of the key choices made for the frontend repository, primarily to decide best tools and strategy/tactics to achieve best results.

• App server type: Static #7
• App server platform: None #9
• Language abstraction: Vanilla JS #8
• Application framework: angularJS #4
• UI framework: PatternFly #6

Not documented dependency

When running gulp command there is an error during PhantomJS installation: "error while loading shared libraries: libfontconfig.so.1: cannot open shared object file: No such file or directory." This can be resolved on Centos by:
sudo yum install fontconfig
This step should be documented.

Platform and runtime for the web application server

This issue is a follow up of #7.

If we are to use a dynamic web server, we will have to choose a runtime environment on which the server will run.

There are several platform/framework options off the shelf which are popular, shiny and feature rich (whether based on php, ruby, python or js, or some other language); each one having their own ugh & aha factors and fan-base. And for that reason, trying to discuss which one would be best suited for the purpose generally results in a crusade - the same way "which superhero is the best?" if has ever been asked in a comic book store.

The Frontend team most feels comfortable using Node.js for our purpose, for following reasons:

• Familiarity of language, and not having to learn a new language
• Homogeneity of the tool stack, using single scripting language
• Node.js has a huge community & growing faster than others
• Node.js is a platform, whereas alternatives are frameworks
• Asynchronous streaming I/O, real-time features are easy
• Graceful to system resources, close to static web server
• npm makes using, updating, publishing modules easy
• Can be deployed in wide(st) arrays of environments
• No lack of key features, offered by the alternatives

To propose alternatives, please use comments with relevant data that out-weighs the overall usefulness of Node.js, in favor of the alternative.

Pool list unit testing

Updating unit tests for cluster import flow

Import cluster view and the controller's logic has been modified. Hence updating the unit tests for the same.

Modify makefile to build rpm successfully through 'make --all' command

Can be more modular

• the pages can be more modular, (if possible download only requires js/css)
• all pages should be written as directive which accept default set of arguments.
  for ex : host list should accept parameter like - clusterId, state (error/warning)

Secondary navigation should be improved

• Secondary navigation is still not stable and we can notice problems on hover highlightings.
• the back icon in secondary menu seems confusing.

Nested left navigation for tasks menu.

Need to create a nested navigation for the Admin as per the UX design.

https://redhat.invisionapp.com/share/6T900V2ZX#/screens/198651332

Task Progress page for Import cluster functionality.

UX - https://redhat.invisionapp.com/share/6T900V2ZX#/screens/198651332

Lack of components should be identified

What ever components that are in UXD should be available in patternfly's release.
We were delayed by Datetime component, which is released very late. so, when ever a feature(page) is started, we should make sure that existing components are already there. we faced same issue with vertical navigation also.

Host, Cluster, File shares, Pools and RBDs List view

• Make changes to host and cluster list view to match with UX design.
• Create view for File share, Pool List and RBDs List.
• Confirm the data to be shown for these list views from API team.

Create a Repository for the Behavior Driven Development Code

Compile to JS or Vanilla JS

Compiling to JS means: writing JS in another scripting language (for higher development flexibility and efficiency), then compile them into JavaScript for serving the application.

Compile to JS	Vanilla JS
Higher learning curve, added overhead	No extra learning curve or overhead
More readable code, easy to debug	Less readable code, harder to debug
Generally produces less LoC	Generally produces more LoC
Easier ECMAScript version migration	Harder ECMAScript version migration
Easier discovery of possible errors during compile time	No compilation, hence no preemptive discovery of errors

TypeScript and LiveScript are the two most popular and feature rich superset of JavaScript(i.e. compile to JS). Spared CoffeeScript, as LiveScript does everything CoffeeScript does, but better.

TypeScript	LiveScript
Primarily OO programming style	Primarily functional programming style
Allows static typing (lost on compile)	Dynamic typing, same as JS
Needs TSD to work with JS code	Allows even in-line JS (with <code>)
More lines of codes, in general	Less lines of codes, in general
Imposes conventions	Allows flexibility
Loses information after compiling	Doesn’t lose information after compiling

Provide a way to allow plugins

Adding provision to installing plugins would be a great value addition for users

Each row of List View has some extra space

If you hover over the list item in the List view. The color changes to light gray(as you can see in a picture below) but below that there is some extra white space, which I think is not required.

In code there is list-group class with bottom margin 20px, which can be set to 0px and the white space can be removed.

Problem:
.list-group {
margin-bottom: 20px;
padding-left: 0;
}

Fix:
.list-group {
margin-bottom: 0;
padding-left: 0;
}

left navigation slide issue

Ideally left navigation bar should hide automatically when screen size is small .
and also it should be shrinkable in big screen when user click on hamburger icon at the top.

Provision for Localization

we should be able to provide provision for I18n support.

install instructions documentation

There should be document which describes:

what software should be installed and how should be configured before installing Tendrl
Tendrl installation process
Tendrl post installation steps like configuration, service starting and so on

[was originally at https://tendrl.atlassian.net/browse/TEN-36]

Elements in the list and the buttons are not given unique name and id's.

Every element in the page should be given a unique name or an id, So it can be easily identified.
Also, it will help in writing the behave driven tests.

Note: It should be followed as a best practice to provide unique id's and names to each element in the page.

Loading Icon & Page Load

• Every dashboard card and every page should have an loading icon to be loaded until the whole Dom is loaded
• Page load and page refresh should be intutive (for ex youtube like loading status can be added)

User Management should be improved

• Domain selection should be available on login screen.
• the overall usermanagement should be improved with roles.
• If roles are added, the routing mechanism should handle which pages are accessible to particular user

Donut and Sparkline Chart Component

create package for Centos 7

For CI and integration testing it is important to install all Tendrl components from packages.

Move codes from @skyrings/kitoon

We need the code to be moved from @skyrings/kitoon to this repository to continue working on it, as the previous location will be deprecated.

Steps required:

• Make master branch unprotected: @r0h4n
• Force push the latest HEAD from @skyrings/kitoon: @debloper
• Revert master branch back to protected mode: @r0h4n

To verify existing functionality of Tendrl 1.0 should work in Tendrl 2.0 release.

To verify the existing functionality of "Cluster Detail page" in Tendrl App.

Testing framework

• Unit testing libraries should be used

Using flexbox instead of floating grid

Reasons -

• Flexbox is content driven model. It does not need to know the content upfront.
• Contents can be redistributed.
• Allow boxes to wrap which is really handy for responsive design.

Host list unit testing

Login page should be seperated

• It is of no use downloading the whole application even before the user logs in. should be downloaded only after authentication.
• this prevent unwanted event calls until the user is authenticated.

Tendrl Logo in not aligned to stack Icon in the Header

We need to add extra padding to logo so it can be aligned.

Fix:
.navbar-pf-vertical .navbar-brand {
color: #fff;
height: auto;
margin: 0 0 0 25px;
min-height: 35px;
padding: 1.2em 0 12px;
}
I have changed the value of padding and it looks good to me after this change.

Improve toast notification

• the notification plugin should align with patternfly.
• User should be notified when ever a change is made through UI
  (ex: while import user, the app doesn't notify about the import success/failure)
• incase of events, event link should be available in notification.

cluster import flow should match with UX design

We are going with dynamic generation and we have common form generator.
we are using this form generator for generate the form but in the import cluster case , we have different ux design , not common select box or textbox as we have in form generator.
so finally for import cluster we are not going ahead with dynamic generation for now. it will be static but we will use directive for table view.

Errors in package

I've found this errors in last package from https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/build/481995/
All errors should be fixed and it will be great to fix also one warning.

tendrl-frontend.noarch: W: incoherent-version-in-changelog 0.0.1-1 ['1.1-1.el7.centos', '1.1-1.centos']
tendrl-frontend.noarch: E: script-without-shebang /var/www/tendrl/commons/scss/main.css
tendrl-frontend.noarch: E: script-without-shebang /var/www/tendrl/index.html
tendrl-frontend.noarch: E: unknown-key RSA#e879b811 (MD5
1 packages and 0 specfiles checked; 3 errors, 1 warnings.

Travis job should check git commit message for github bug id and an optional tendrl spec name

In accordance with Tendrl/commons#66 all tendrl repos need a travis integration to check commit message for certain mandatory fields as described below:
"
Moving on, all git commits should contain mandatory mention on newline of
"tendrl-bug-id: <tendrl_repo>/" and optional mention of "tendrl-spec: <tendrl_spec_name>" in the commit msg.

eg:
"""
Packaging python-etcd

Added Makefile and spec file to create python-etcd package
Now one can use "make rpm" to pull the latest source from github
and build the source rpm
and using the Makefile one can also build rpm using "make rpm"
which will use mock to build the rpm using srpm.

tendrl-bug-id: Tendrl/commons#18

tendrl-spec: refactor_gluster_integration_get_state_dump
"

Repository name changes

Repository names need to be updated to follow lowercase, hyphenated convention. In this case need to drop the tendrl prefix and change the name to dashboard

Detach API server from frontend server by design

Make frontend talk to API server over REST calls, without them needing to be on the same host.

This allows separate/parallel development of API without impacting frontend much, and vice versa. This also allows feeding in mock API responses to a demo frontend server, until API is ready with a particular implementation.

cluster import flow should match with UX design

cluster import flow should match with UX design

Implement API endpoint as a config parameter for the frontend instance

For the moment, the API endpoint is hard coded (even though DRY, through #26). It has to be changed to be a configuration option for it to be consumed as an enterprise product.

Proper validations in all the forms

Every single form should be properly validated before making a submit.

File share list unit testing

Cluster list unit testing

Comparison of full fleshed framework (AngularJS) features with individual feature libraries

We've previously used AngularJS as the webapp framework mainly for following purposes:

1. Routing
2. Templating
3. Data Binding
4. Lazy Loading

To go ahead with the new stack, it is essential to evaluate whether the same would continue to work for us, or choosing individual tools for those purposes (as long as they are feature rich and inter-operable).

Benefits of using individual components, in general, are:

1. Flexibility: - we are free to choose our own structure instead of forcing us to follow the syntax or structure defined by the framework.
2. No lock-ins: - we will not be impose to choose any technology just because of the fact it supported by framework.
3. Replaceability - we can replace that particular library with any other in future(if that fits a better choice for our application).
4. Modularity - the overall structure will be more modular in the sense that it will not combine the view along with the business logic.

Cons of using individual components is that it will comes along with the learning curve.

There should be a version number in api url call when called from Tendrl_frontend

As is mentioned in Tendrl/api#51, api query URL should be in format: http://<hostname>/api/1.0/query with specified version. When tendrl_frontend is installed from source then expected api calls are in format http://<hostname>/api/query.json. Tendrl_frontend is making calls in format http://<hostname>/api/1.0/query when installed from packages. Calls made by Tendrl_frontend installed from source should be corrected.

Repository access rights

The frontend engineering team has agreed to have shared r/w access to the repository, to ensure redundancy of available human resources for the necessary operations (primarily merging).

This does not mean, the team would directly commit/push to the upstream repo. It just merely means, a merge isn't blocked on a certain person's availability, among other things.

I'm requesting to add Karnan, Neha & me to have the R/W privileges on this repo.

GitHub allows pretty fine grained access control. We can achieve this by:

• Invite the users as org members
• Create a team "frontend"
• Add the frontend specific repos (this repo, website repo etc)
• Add the invited members as the members of the team
• Give the team Read and Write privileges (which will be applied on the added repos).

Table component creation

Create a generic table component which should accept the parameters for column name and data from controller.

Landing Page Text Change

For the landing page, @[email protected] suggests that we re-word the text, i.e. remove “please” and instead saying: “Create or import a cluster to get started.”

@mcarrano This was listed in https://redhat.invisionapp.com/share/6T900V2ZX#/screens/198042644/comments/76877561 -- noting this as an issue so it can be changed.

on repository name

I was wondering whether the project would consider non-generic names for components. By which I mean that UI is a component and it is likely to be a service available through a combination of packages and such. Thus, tendrl-ui or, such with a description in the README that the repository is all of the elements required to build and deploy the user interface, is an approach to be considered.

Type of web application server

Static Web App	Dynamic Web App
Cheaper to develop, host, manage	Costlier to develop, host, manage
Low floor, low ceiling of features	Low floor, high ceiling of features
Resistant to evolution	Receptive to evolution
Limited by Auth, CORS, Data options*	Flexible to Auth, CORS, Data options*

* Expansion on the topic of limited by Auth, CORS, Data options

• A dynamic web app will help up abstract sensitive backend URLs from the client side code, running in the browser.
• A dynamic webapp alllows implementing user login mechanisms securely, regardless of the authentication strategy.
• Gives us the flexibility of mocking the API to continue with the UI development (if API is not ready)

---

However, due to the packaging restrictions, implementing the webapp on dynamic runtime doesn't comply with the limitation in distribution/installation (can be overcome with private module registry - in future). Which means, for the time being we have to stick with static web applications.

This comes at a cost of the application being limited to all the feature restrictions that applies to a static web app; as well as heightened complexity of implementation of some features, which can be rather easily implemented in a dynamic app.