Principle
- Minimize user operations for managing and monitoring topologies
- REST Service centralized metadata management
- Consistent UI experience
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)
Architecture
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 Execution Service
- Service name: ApplicationExecutionService
- Table name: eagle_metadata
- Prefix: application_execution
Attribute | Type | Description | |
---|---|---|---|
tags | site | String | site name |
application | String | application physical topology = ${site}_${application} | |
fields | mainClass | String | application main class |
statusUrl | String | application tracking url | |
status | String | {SUCCESS, FAILURE} | |
statusDescription | String | application description |
Environment Definition
Service name: ApplicationEnvironmentServiceTable name: eagle_metadataPrefix: application_environment
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