nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcgilman <>
Subject [GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...
Date Thu, 19 May 2016 12:17:50 GMT
Github user mcgilman commented on the pull request:
    @alopresto Thanks for the very thorough review! This API is designed strictly for handling
the persistence of access policies which would also include Users and Groups. These objects
are designed as simple data objects or POJOs. While the MutableAuthorizer can load these records,
it must be told when to save. It wouldn't know a given User/Group/Policy has been modified.
This is part of the motivation to have the objects be immutable. The intent is very clear
to an implementor of MutableAuthorizer that the objects won't be modified outside of their
knowing. I believe that @bbende recommendation of introducing a Builder for creating new versions
of a given User/Group/Policy is a great way to handle the cloning.
    The end goal here was to design the API such that the implementation only needed to be
concerned with persistence.
    **uniqueness constraint** - How we address this would ultimately be based on whether we
support reloading the Users/Groups/Policies while the application is running. We decided against
this as the motivation for the MutableAuthorizer API was to support an Authorizer that was
managed by NiFi. With this approach we would be enforcing uniqueness at startup and when new
records were added outside of the MutableAuthorizer.
    **ID mutability** - The identifier of a record is not mutable. The identity of a user
and name of a group are (using the clone/builder approach described). This is to more easily
support name chanes or typos without having to re-create all the policies for that entity
as well.
    **locks & merge conflicts** - Thread locking is handled by the web tier using the
same mechanism as the other Resources. For 1.0.0 we are introducing fine grain locking through
a RevisionManager. Obtaining a write lock for a given record would require a client to include
a Revision. The RevisionManager manager would validate the Revision and lock the Revision
to prevent other clients from modifying the same record.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message