[
https://issues.apache.org/jira/browse/RANGER-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyom Mani Tiwari updated RANGER-5851:
-------------------------------------
Description:
RANGER-5838 added {{constraintDefs}} to {{{}RangerServiceDef{}}}. Ranger Admin
doesn’t store them yet, so they’re dropped when a service def is created or
updated. This sub-task adds that storage.
_Scope_
* Store {{constraintDefs}} on service def create and update, and return them
on get, through REST and {{ServiceDBStore}} /
{{{}RangerServiceDefServiceBase{}}}.
* Validate constraintDefs in {{{}RangerServiceDefValidator{}}}:
** names and itemIds are unique and not empty;
** {{resources}} and {{accessTypes}} refer to resources and access types that
exist in the service def;
** each {{resources}} list forms a valid chain that includes its ancestors;
** parameter names are unique, and parameter {{type}} values are supported.
* Include constraintDefs in service-def export/import and in the service def
sent to plugins.
* Updates: decide what happens to constraint policies that reference a
constraintDef that is removed or renamed. Proposal: reject the update while
policies reference it, as is done for access types in use.
_Storage: new table {{x_constraint_def}}_
* Columns:
** standard: {{{}id{}}}, {{{}guid{}}}, {{{}create_time{}}},
{{{}update_time{}}}, {{{}added_by_id{}}}, {{{}upd_by_id{}}};
** {{def_id}} (FK to {{{}x_service_def{}}}) and {{{}item_id{}}};
** {{{}name{}}}, {{{}label{}}}, {{{}description{}}}, {{{}rb_key_label{}}},
{{{}rb_key_description{}}};
** {{{}resources{}}}, {{{}access_types{}}}, {{{}parameters{}}}, {{options}} as
JSON text;
** {{{}sort_order{}}}.
* Parameters ({{{}RangerConstraintParamDef{}}}) are stored as JSON on the
constraint row. They’re always read with their constraint, so there’s no
separate table.
* Schema changes:
** the table in the current schema for MySQL, Postgres, Oracle, SQL Server and
SQL Anywhere;
** an upgrade patch for each flavor;
** the drop scripts updated.
_Code_
* {{XXConstraintDef}} entity and {{{}XXConstraintDefDao{}}}, registered in
{{{}RangerDaoManager{}}}, with find-by-def-id and find-by-def-id-and-name
queries.
* {{{}RangerServiceDefServiceBase{}}}: map constraintDefs both ways, as for
{{{}policyConditions{}}}.
* {{{}ServiceDBStore{}}}:
** create, update and delete constraintDefs with the service def, removing
those dropped on update;
** delete them when the service def is deleted.
* Include constraintDefs in service-def export/import and in the service def
sent to plugins.
_Validation ({{{}RangerServiceDefValidator{}}})_
* Names and itemIds are unique and not empty.
* {{resources}} and {{accessTypes}} refer to resources and access types that
exist in the service def.
* {{resources}} covers whole hierarchy chains, including ancestors, so
{{getResourceHierarchiesForConstraint()}} returns at least one hierarchy.
* Parameter names are unique and parameter {{type}} values are supported.
* A constraintDef can’t be removed or renamed while policies reference it. The
check uses the policy-ref data added in B2; until B2 lands, it’s a TODO.
_Testing_
* Validator unit tests.
* {{ServiceDBStore}} / {{RangerServiceDefServiceBase}} round-trip tests:
create, update (add, change and remove a constraintDef), get and delete.
* The upgrade patch applied on each DB flavor.
was:
RANGER-5838 added {{constraintDefs}} to {{{}RangerServiceDef{}}}. Ranger Admin
doesn’t store them yet, so they’re dropped when a service def is created or
updated. This sub-task adds that storage.
_Scope_
* Store {{constraintDefs}} on service def create and update, and return them
on get, through REST and {{ServiceDBStore}} /
{{{}RangerServiceDefServiceBase{}}}.
* Validate constraintDefs in {{{}RangerServiceDefValidator{}}}:
** names and itemIds are unique and not empty;
** {{resources}} and {{accessTypes}} refer to resources and access types that
exist in the service def;
** each {{resources}} list forms a valid chain that includes its ancestors;
** parameter names are unique, and parameter {{type}} values are supported.
* Include constraintDefs in service-def export/import and in the service def
sent to plugins.
* Updates: decide what happens to constraint policies that reference a
constraintDef that is removed or renamed. Proposal: reject the update while
policies reference it, as is done for access types in use.
_Storage (decision needed)_
Today each service-def section has its own tables: {{{}x_access_type_def{}}},
{{{}x_resource_def{}}}, {{{}x_datamask_type_def{}}}, …. Options:
# A new table, {{x_constraint_def}} (name, label, description, resources,
accessTypes, parameters as JSON, rb keys, item_id, def_id), with DB patches for
MySQL, Postgres, Oracle and SQL Server. This is consistent with the other
sections.
# A JSON column on {{x_service_def}} holding the whole {{constraintDefs}}
list. This needs a smaller schema change.
Proposal: option 1 for the table, with {{parameters}} stored as JSON inside it,
to avoid a second child table.
_Testing:_ unit tests for validation; service-store tests for create, update,
get and delete round-trips; and an upgrade-patch test on each DB flavor.
> Admin: persist constraintDefs of service definitions
> ----------------------------------------------------
>
> Key: RANGER-5851
> URL: https://issues.apache.org/jira/browse/RANGER-5851
> Project: Ranger
> Issue Type: New Feature
> Components: admin
> Reporter: Vyom Mani Tiwari
> Assignee: Vyom Mani Tiwari
> Priority: Major
>
> RANGER-5838 added {{constraintDefs}} to {{{}RangerServiceDef{}}}. Ranger
> Admin doesn’t store them yet, so they’re dropped when a service def is
> created or updated. This sub-task adds that storage.
> _Scope_
> * Store {{constraintDefs}} on service def create and update, and return them
> on get, through REST and {{ServiceDBStore}} /
> {{{}RangerServiceDefServiceBase{}}}.
> * Validate constraintDefs in {{{}RangerServiceDefValidator{}}}:
> ** names and itemIds are unique and not empty;
> ** {{resources}} and {{accessTypes}} refer to resources and access types
> that exist in the service def;
> ** each {{resources}} list forms a valid chain that includes its ancestors;
> ** parameter names are unique, and parameter {{type}} values are supported.
> * Include constraintDefs in service-def export/import and in the service def
> sent to plugins.
> * Updates: decide what happens to constraint policies that reference a
> constraintDef that is removed or renamed. Proposal: reject the update while
> policies reference it, as is done for access types in use.
> _Storage: new table {{x_constraint_def}}_
> * Columns:
> ** standard: {{{}id{}}}, {{{}guid{}}}, {{{}create_time{}}},
> {{{}update_time{}}}, {{{}added_by_id{}}}, {{{}upd_by_id{}}};
> ** {{def_id}} (FK to {{{}x_service_def{}}}) and {{{}item_id{}}};
> ** {{{}name{}}}, {{{}label{}}}, {{{}description{}}}, {{{}rb_key_label{}}},
> {{{}rb_key_description{}}};
> ** {{{}resources{}}}, {{{}access_types{}}}, {{{}parameters{}}}, {{options}}
> as JSON text;
> ** {{{}sort_order{}}}.
> * Parameters ({{{}RangerConstraintParamDef{}}}) are stored as JSON on the
> constraint row. They’re always read with their constraint, so there’s no
> separate table.
> * Schema changes:
> ** the table in the current schema for MySQL, Postgres, Oracle, SQL Server
> and SQL Anywhere;
> ** an upgrade patch for each flavor;
> ** the drop scripts updated.
> _Code_
> * {{XXConstraintDef}} entity and {{{}XXConstraintDefDao{}}}, registered in
> {{{}RangerDaoManager{}}}, with find-by-def-id and find-by-def-id-and-name
> queries.
> * {{{}RangerServiceDefServiceBase{}}}: map constraintDefs both ways, as for
> {{{}policyConditions{}}}.
> * {{{}ServiceDBStore{}}}:
> ** create, update and delete constraintDefs with the service def, removing
> those dropped on update;
> ** delete them when the service def is deleted.
> * Include constraintDefs in service-def export/import and in the service def
> sent to plugins.
> _Validation ({{{}RangerServiceDefValidator{}}})_
> * Names and itemIds are unique and not empty.
> * {{resources}} and {{accessTypes}} refer to resources and access types that
> exist in the service def.
> * {{resources}} covers whole hierarchy chains, including ancestors, so
> {{getResourceHierarchiesForConstraint()}} returns at least one hierarchy.
> * Parameter names are unique and parameter {{type}} values are supported.
> * A constraintDef can’t be removed or renamed while policies reference it.
> The check uses the policy-ref data added in B2; until B2 lands, it’s a TODO.
> _Testing_
> * Validator unit tests.
> * {{ServiceDBStore}} / {{RangerServiceDefServiceBase}} round-trip tests:
> create, update (add, change and remove a constraintDef), get and delete.
> * The upgrade patch applied on each DB flavor.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
