Uploaded image for project: 'Samza'
  1. Samza
  2. SAMZA-1788

Introduce LocationIdProvider abstraction

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Currently in standalone, hostName of the standalone processor is used as LocationId. However, for containerized environments like azure cloud, kubernetes this defaulting does  not work. Standalone processors can be launched from different kubernetes container on a physical machine(where each docker container has different locatliyID than other docker container within same machine). 

      To solve this problem, we introduce locationID abstraction to support plugging in uniqueId identifying the execution environment of the processor. In case of containerized environments, LocationId is a combination of multiple fields (sliceId, containerId, hostname) instead of simple physical hostname. By default hostname will be used as LocationId(if not configured by the user).

      A new abstraction LocationIdProvider will be introduced to generate locationId for a physical execution environment. All the processors of an application registered from an locationID should be able to share(read/write) their local state stores. Any custom LocationIdProvider is expected to honor this contract when generating the locationID.

        Attachments

        Issue Links

          Activity

            People

            • Assignee:
              spvenkat Shanthoosh Venkataraman
              Reporter:
              spvenkat Shanthoosh Venkataraman

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment