Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Checklist

  •  User Stories Documented
  •  User Stories Reviewed
  •  Design Reviewed
  •  APIs reviewed
  •  Release priorities assigned
  •  Test cases reviewed
  •  Blog post

Introduction 

Briefly write the need for this feature

Goals

Clearly state the design goals/requirements for this feature 

User Stories 

  • Breakdown of User-Stories 
  • User Story #1
  • User Story #2
  • User Story #3

    There are a few use cases that we want to support with this feature. The first is to support a use case where the pipeline is a geofencing use case, where the pipeline is processing user locations, and wants to send notifications when a user enters or leaves a geo fence. Similar use cases include pipelines that are reading user biometric data that need to send notifications if user heart rate exceeds a certain value, or pipelines that read machine cpu usage that need to send notification if cpu usage exceeds a certain value. In these use cases, some uncommon event occurs that must be acted on by a separate system. The events that trigger these notifications still need to be processed by the rest of the pipeline, there is just some side effect that is triggered once they are observed.

    Goals

    The goal is to allow stages in a pipeline to emit notifications, which can be configured to be published to TMS or to Kafka.

    User Stories 

    • As a pipeline developer, I want to be able to create a pipeline where notifications are published to Kafka or TMS when some condition is met
    • As a pipeline developer, I want to be able to create some pipelines that publish notifications and some that do not, even when the conditions are met
    • As a pipeline developer, I want to be able to configure which topic notifications are published to
    • As a pipeline developer, I want to be able to tell which plugins can emit notifications and which plugins cannot
    • As a cluster administrator, I want to be able to see how many notifications were published for a pipeline run
    • As a plugin developer, I want to be able to write arbitrary logic to control when to publish notifications
    • As a plugin developer, I want to be able to indicate which plugins can emit notifications

    Design

    Cover details on assumptions made, design alternatives considered, high level design

    Approach

    Approach #1

    Approach #2

    API changes

    New Programmatic APIs

    New Java APIs introduced (both user facing and internal)

    Deprecated Programmatic APIs

     

    New REST APIs

    PathMethodDescriptionResponse CodeResponse
    /v3/apps/<app-id>GETReturns the application spec for a given application

    200 - On success

    404 - When application is not available

    500 - Any internal errors

     

         

    Deprecated REST API

    PathMethodDescription
    /v3/apps/<app-id>GETReturns the application spec for a given application

    None

    CLI Impact or Changes

    • Impact #1
    • Impact #2
    • Impact #3
    • None

    UI Impact or Changes

    • Impact #1
    • Impact #2
    • Impact #3

    Security Impact 

    What's the impact on Authorization and how does the design take care of this aspect
    • UI must be able to detect which plugins can emit notifications, and display a corresponding port
    • UI must display metrics for notifications emitted

    Security Impact 

    This feature will use TMS, so any authorization added to TMS will affect this feature.

    Impact on Infrastructure Outages 

    System behavior (if applicable - document impact on downstream [ YARN, HBase etc ] component failures) and how does the design take care of these aspectNone

    Test Scenarios

    Test IDTest DescriptionExpected Results
       
       
       
       

    Releases

    Release X.Y.Z

    Release X.Y.Z

    Related Work

    • Work #1
    • Work #2
    • Work #3

     

    Future work