Objective
- Make sure consistent semantics between the term application (user space) and topology (physical space only)
- Topology should read configuration from SiteApplicationEntity#config instead of configuration file
- Use REST Service as only entry to manage application (START/STOP/HEALTH CHECKING) and ApplicationManager to schedule the task execution and update the execution information
- Eagle UI should support to manage/monitor the application on site/application page
- Single site/application may have more than one topologies (for example hdfsAuditLogMonitoring and userProfileMonitoring should have topologies running separately)
To have a better user experience with EAGLE ui, we could provide an interface to manage a certain topology via the ui page, such as submit a topology
Schema
Application Definition
- Service name: ApplicationManagementService
- Table name: eagle_metadata
- Prefix: application_management
Attribute | Type | Description | |
---|---|---|---|
tags | site | String | site name |
application | String | application physical topology = ${site}_${application} | |
fields | mainClass | String | application main class |
environment | String | environment name | |
url | String | application tracking url | |
status | String | {SUCCESS, FAILURE} | |
description | String | application description |
Environment Definition
- Service name: ApplicationEnvironmentService
- Table name: eagle_metadata
- Prefix: application_environment
Attribute | Type | Description | |
---|---|---|---|
tags | name | String | environment name |
fields | type | String | e.g., storm, spark |
config | String | cluster config |
Use cases
- NEW
- create a topology definition entity
- START
- click START button
- check the topology's current status on the nimbus host
- a new thread is created to execute the submitting topology task
- update status
- STOP
- click STOP button
- check the topology's current status on nimbus host
- a new thread is created to stop the topology
- update status