There have been concerns from other teams about the sentry-provider-db as well. I think it makes sense to split it to avoid these dependencies issues.
Go head, create some jiras to split them. I will recommend creating one jira per module just to keep the patch simple and easy to review. On Wed, Apr 18, 2018 at 12:24 PM, Anthony Young-Garner < anthony.young-gar...@cloudera.com> wrote: > I agree that it would be useful to break up the sentry-provider-db module > in order to allow dependency chains to be more easily expressed and to > decouple the SentryService entry point from the database model. Are there > any concerns with the approach Steve suggested? > > On Wed, Apr 18, 2018 at 11:07 AM, Stephen Moist <mo...@cloudera.com> > wrote: > > > So looking at sentry-provider-db, it looks like it’s pretty much the main > > module of Sentry. It has the thrift apis, db, cli and Sentry Service. > I’m > > running into issues with developing ABAC as we have it be it’s own > module. > > It depends on sentry-provider-db, and then for me to add it in so that > > SentryService can take advantage of it, sentry-provider-db depends on > > sentry-abac so we end up with a circular dependency. Rather than just > > shove abac into sentry-provider-db, I’m proposing we split > > sentry-provider-db into sentry-provider-db (the existing db layer), > > sentry-main/sentry-service, sentry-main/sentry-cli and > > sentry-main/sentry-api. Thus the dependency chain would be > > sentry-provider-db -> sentry-service -> sentry-api->sentry-cli and > > sentry-abac depends on sentry-service, sentry-cli, sentry-api. Thoughts > on > > this? >
