Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
The latest commit switches the persistence for storing user settings to
HBase rather than a RDBMS as discussed on the dev list. Instead of fields
being stored in RDBMS columns, the user settings object is now serialized with
Jackson and stored in HBase as a byte[]. This required several changes
including:
- Added code to setup HBase in the MPack, following the update table
pattern in the indexing MPack scripts as an example
- Added default table/cf values to REST properties
- Added a Config class to the REST app to setup an HBase client
- Added a Service class to the REST app that manages user settings in HBase
- Added tests for all new classes and updated existing tests
- Updated the REST README
I also refactored some areas to make things clearer and easier to
understand:
- Renamed AlertProfile to UserSettings and moved the endpoints to the
UserController. The thinking is that we may not want this to be limited to
just the Alerts UI.
- Refactored the REST MPack scripts to more closely align with other
components in regards to setting up Kafka, HBase, etc.
- Removed the Optional fields from a couple model classes. This was
causing issues with Jackson and I don't believe it benefits us enough to have
to deal with that complexity.
There are a couple of design issues to consider when reviewing this. The
implementation in the REST app is specific to this use case. I considered
trying to make it more generic for future HBase use cases but decided to keep
it simple for now. Instead of trying to predict what those use cases look
like and choose a pattern that works, I decided to leave that to whoever
implements a new use case in the future. I also considered making this generic
to all of Metron but again, decided to keep it simple. Should these settings
be limited to just REST/UIs? Any thoughts on this?
This has been tested in full dev and all tests are passing. In full dev,
navigate to the UserController and use the various endpoints to save and
retrieve settings for the currently logged in user. You should also be able to
log in as the admin user and see all user settings and delete an individual
user's settings. I also tested evolving the user settings model by adding new
fields and it worked without issue. Users with existing settings just return
null for new fields.
---
