You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 75 Next »

Contribution

Welcome to contribute improvement proposal by sending discussion to dev@eagle.incubator.apache.org !

EIP-1: UI Improvements

OwnerJilin, Jiang

Improvements

  • EIP-1.1 Support eagle application status auo-sync (reported by Hao Chen)

  • EIP-1.2 Add app configuration view page (reported by qingwzhao)

  • EIP-1.3 Policy creation failed and show 'Policy 'test_delete' not found!' (reported by Hao Chen)

  • EIP-1.4 [API Require] Support policy validation function when submitting policy in advanced mode. (reported by Hao Chen)

  • EIP-1.5 Hide "start/stop" button for un-executable application (reported by Hao Chen)

  • EIP-1.6 Add dedup fields in policy definition page (reported by qingwzhao)

  • EIP-1.7 Enrich application status with colorful icon label  (reported by Hao Chen)

  • EIP-1.8 Refactor view policy page (basic, definition, execution) (reported by Hao Chen)

  • EIP-1.9 Add installed application view page (Desc, Status, Execution) (reported by Hao Chen)

  • EIP-1.10 [API Require] Integrate install/uninstall docs to cooresponding process instead of on ApplicationDesc. (reported by Hao Chen)

  • EIP-1.11 Add "Guide" tab aside "Environment" and "Configuration" during Installation/Uninstallation accordingly, contains Installation/Uninstallation guide and dependency status. (reported by Hao Chen)

  • EIP-1.12 View Installed Application Page (reported by Hao Chen)

    • EIP-1.12.1 Add installed application view page
    • EIP-1.12.2 [API Require] Policy deployed assignments and execution metrics
    • EIP-1.12.3 [API Require] Application running  status, metrics and physical information (storm info/tracking url/metric)
    • EIP-1.12.4 [API Require] Alert Engine backend visibility (Topology/Policy distribution/Worker load visualization)
  • EIP-1.13 Move Streams (Installed Streams) to Alert (reported by Hao Chen

  • EIP-1.14 App installation settings enhance (reported by Hao Chen)

    • EIP-1.14.1 Rename "Configuration" as "Settings" (So only keep two tabs: Installation and Settings)
    • EIP-1.14.2 Separate settings items to different section: General Settings (required = true), Advanced (fold by default): Optional Settings (required = false), Environment Settings, and  Additional Settings (key=value) }
    • EIP-1.14.3 Show  setting name as "displayName" and (?) which show configuration name and description as tips.
    • EIP-1.14.4 Add additional configuration with two-inputs form: Name + Value
  • EIP-1.15 Refactor Policy Editor

    • EIP-1.15.1 Support select output stream according to Siddhi query instead of forcing user to input, by default OUTPUT_STREAM_LIST = ALL_STREAM_LIST - INPUT_STREAM_LIST

    • EIP-1.15.2 Refactor layout as: Basic (Name, Desc) -> Policy Definition (Siddhi)  ->  Connect From (Automatically generate according to query and support edit partition per stream)  -> Alert On (select from output stream) -> Publish To (Select Publisher)

    • EIP-1.15.3 Create Publisher in Popup Dialog and Add Publisher list page

    • EIP-1.15.4 Add SQL-Syntax highlight editor and automatically for SQ (Hao Chen will provide query explain API)
    • EIP-1.15.5 Support Add Customized Stream on UI, currently only support Kafka
    • EIP-1.15.6 Support ElasticsSearch/Eagle Publisher and Do visualization with Kibana/Eagle Dashboard? Which is another typical use case.

JIRAS

T Key Summary Assignee Reporter P Status Resolution Created Updated Due
Loading...
Refresh

EIP-2: Refactor Alert WebService API

OwnerHao Chen

The alert web service API has some problems like:

  • Unmanaged (raw status/message) response structure, which cause inconsistent behaviors for client side and UI side
  • All alert metadata are coupled in "IMetadataDao" interface and provide only RAW rest API but not business-logic oriented API.

EIP-3: Use consistent namespace concept for eagle and alert engine

OwnerHao Chen

Problem

"site" in eagle means an isolated monitored namespace for certain tenant, like a monitored cluster or service.
In most cases, we could simply make sure a policy/application is owned by certain site, for example, alert policies are often bound with certain site which will be much easier for user to organize them, as well as applications, but there are also some special cases where polices/applications may also cross different sites, for example alert engine app in fact is shared by all sites, as well as some global overview dashboards.

Proposal

Keep a reserved "default" site, which means "a globally shared namespace", so that we could simply use consistent metadata structure for site-based / non-site / cross-site cases cases.

EIP-4: Alert engine cannot detect policy change

Reporterqingwzhao

Problem

"site" in eagle means an isolated monitored namespace for certain tenant, like a monitored cluster or service.
After policy changes, alert engine cannot detect the it, and no new schedulestate is generated. Currently, i use a workaround way. Once i change the policy, i will post the rest request 'coordinator/build', and it works. 

 

Links

 

  • No labels