[
https://issues.apache.org/jira/browse/ATLAS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163181#comment-15163181
]
Tom Beerbower commented on ATLAS-512:
-------------------------------------
[~bergenholtz], Yeah I guess I sort of missed the main point of the Jira. I
was thinking about it from the standpoint of removing as many dependencies as
possible and not a total decoupling. However I don't think that it is correct
to say that option 1 addresses the issue of needing Atlas server to be up and
running at the time of model registration. It just moves the registration out
to a separate tool (which still need Atlas server to be running).
> Decouple currently integrating components from availability of Atlas service
> for raising metadata events
> ---------------------------------------------------------------------------------------------------------
>
> Key: ATLAS-512
> URL: https://issues.apache.org/jira/browse/ATLAS-512
> Project: Atlas
> Issue Type: Sub-task
> Reporter: Hemanth Yamijala
> Assignee: Hemanth Yamijala
>
> The components that currently integrate with Atlas (Hive, Sqoop, Falcon,
> Storm) all communicate their metadata events using Kafka as a messaging
> layer. This effectively decouples these components from the Atlas server.
> However, all of these components have some initialization that checks if
> their respective models are registered with Atlas. For components that
> integrate on the server, like HiveServer2 and Falcon, this initialization is
> a one time check and hence, is manageable. Others like Sqoop, Storm and the
> Hive CLI are client side components and hence the initialization happens for
> every run or session of these components. Invoking the initialization (and
> the one time check) every time like this effectively means that the Atlas
> server should be always available.
> This JIRA is to try and remove this dependency and thus truly decouple these
> components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
