[ 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)