Info |
---|
This capability is currently under development. |
Get List of Views
Gets the list of all available Views
Code Block GET /api/v1/views 200 - OK
Once you have a list of views, you can drill-into a view and see the available versions.
Code Block GET /api/v1/views/FILES 200 - OK
You can go a level deeper and see more information about that specific version for the view, such as the parameters and the archive name, and a list of all instances of the view.
Code Block GET /api/v1/views/FILES/versions/0.1.0 200 - OK
Creating a View Instance
The following example shows creating an instance of the FILES view, version 1.0.0 view called "MyFiles".
...
Create the view instance.
Code Block |
---|
POST /api/v1/views/FILES/versions/1.0.0/instances/MyFiles
201 - CREATED |
...
Set view properties.
Code Block |
---|
PUT /api/v1/views/FILES/versions/1.0.0/instances/MyFiles
[ {
"ViewInstanceInfo" : {
"properties" : {
"dataworker.defaultFs" : "webhdfs://your.namenode.host:50070"
}
}
} ]
200 - OK |
...
Restart Ambari Server to pick-up the view instance and UI resources.
Code Block |
---|
ambari-server restart |
...
Confirm the newly created view instance is available.
Code Block |
---|
GET /api/v1/views/FILES/
{
"href" : "http://127.0.0.1:8080/api/v1/views/FILES/versions/1.0.0",
"ViewInfo" : {
"archive" : "/var/lib/ambari-server/resources/views/files-0.0.1-SNAPSHOT-jar-with-dependencies.jar",
"label" : "Files",
"parameters" : [
{
"name" : "dataworker.defaultFs",
"description" : "FileSystem URI",
"required" : true
}
],
"version" : "1.0.0",
"view_name" : "FILES"
},
"instances" : [
{
"href" : "http://127.0.0.1:8080/api/v1/views/FILES/versions/1.0.0/instances/MyFiles",
"ViewInstanceInfo" : {
"instance_name" : "MyFiles",
"view_name" : "FILES"
}
}
]
} |
Ambari Views offer a systematic way to plug-in UI capabilities to surface custom visualization, management and monitoring features in Ambari Web. A "view" is a way of extending Ambari that allows 3rd parties to plug in new resource types along with the APIs, providers and UI to support them. In other words, a view is an application that is deployed into the Ambari container.
Table of Contents |
---|
Useful Resources
Resource | Link |
---|---|
Views Overview | http://www.slideshare.net/hortonworks/ambari-views-overview |
Views Framework API Docs | https://github.com/apache/ambari/blob/trunk/ambari-views/docs/index.md |
Views Framework Examples | https://github.com/apache/ambari/tree/trunk/ambari-views/examples |
Terminology
The following section describes the basic terminology associated with views.
Term | Description |
---|---|
View Name | The name of the view. The view name identifies the view to Ambari. |
View Version | The version of the view. A unique view name can have multiple versions deployed in Ambari. |
View Package | This is the JAR package that contains the view definition and all view resources (server-side resources and client-side assets) for a given view version. See View Package for more information on the contents and structure of the package. |
View Definition | This defines the view name, version, resources and required/optional configuration parameters for a view. The view definition file is included in the view package. See View Definition for more information on the view definition file syntax and features. |
View Instance | An unique instance of a view, that is based on a view definition and specific version that is configured. See Versions and Instances for more information. |
View API | The REST API for viewing the list of deployed views and creating view instances. See View API for more information. |
Framework Services | The server-side of the view framework exposes certain services for use with your views. This includes persistence of view instance data and view eventing. See Framework Services for more information. |
Components of a View
A view can consist of client-side assets (i.e. the UI that is exposed in Ambari Web) and server-side resources (i.e. the classes that expose REST end points). When the view loads into Ambari Web, the view UI can use the view server-side resources as necessary to deliver the view functionality.
Client-side Assets
The view does not limit or restrict what client-side technologies a view uses. You can package client-side dependencies (such as JavaScript and CSS frameworks) with your view.
Server-side Resources
A view can expose resources as REST end points to be used in conjunction with the client-side to deliver the functionality of your view application. Thees resources are written in Java and can be anything from a servlet to a regular REST service to an Ambari ResourceProvider (i.e. a special type of REST service that handles some REST capabilities such as partial response and pagination – if you adhere to the Ambari ResourceProvider interface). See Framework Services for more information on capabilities that the framework exposes on the server-side for views.
Info |
---|
Checkout the Weather View as an example of a view that exposes servlet and REST endpoints. https://github.com/apache/ambari/tree/trunk/ambari-views/examples/weather-view |
Anchor | ||||
---|---|---|---|---|
|
The assets associated with a view are delivered as a JAR package. The view definition file must be at the root of the package. UI assets and server-side classes are served from the root. Dependent Java libraries are placed in the WEB-INF/lib
directory.
Code Block |
---|
view.jar
|
|- view.xml
|
|- <server packages + classes>
|
|- index.html
| |
| |_ <supporting UI assets>
|
|_ WEB-INF
|
|_ lib/*.jar
|
Anchor | ||||
---|---|---|---|---|
|
Multiple versions of a given view can be deployed into Ambari and multiple instances of each view can be created for each version. For example, I can have a view named FILES and deploy versions 0.1.0 and 0.2.0. I can then create instances of each version FILES{0.1.0} and FILES{0.2.0} allowing some Ambari users to have an older version of FILES (0.1.0), and other users to have the newer FILES version (0.2.0). I can also create multiple instances for each version, configuring each differently.
Instance Configuration Parameters
As part of a view definition, the instance configuration parameters are specified (i.e. "these parameters are needed to configure an instance of this view"). When you create a view instance, you specify the configuration parameters specific to that instance. Since parameters are scoped to a particular view instance, you can have multiple instances of a view, each instance configured differently.
Using the example above, I can create two instances of the FILES{0.2.0} version, one instance that is configured a certain way and the second that is configured differently. This allows some Ambari users to use FILES one way, and other users a different way.
See Framework Services for more information on instance configuration properties.
View Lifecycle
The lifecycle of a view is shown below. As you deploy a view and create instances of a view, server-side framework events are invoked. See Framework Services for more information on capabilities that the framework exposes on the server-side for views.
Browse to the view instance.
...