-
Notifications
You must be signed in to change notification settings - Fork 332
Add Events for PolarisServiceImpl APIs #2482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Events for PolarisServiceImpl APIs #2482
Conversation
|
|
||
| @Override | ||
| public Response createCatalog( | ||
| CreateCatalogRequest request, RealmContext realmContext, SecurityContext securityContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove instrumentation from #1844 for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in next revision.
| public Response listCatalogRoles( | ||
| String catalogName, RealmContext realmContext, SecurityContext securityContext) { | ||
| return delegate.listCatalogRoles(catalogName, realmContext, securityContext); | ||
| polarisEventListener.onBeforeCatalogList(new CatalogsServiceEvents.BeforeCatalogListEvent()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the right event? We are listing catalog roles, not catalogs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
| catalogName, catalogRoleName, grantRequest, realmContext, securityContext); | ||
| PolarisServiceImpl.AddGrantToCatalogRoleEntityWrapper entityWrapper = | ||
| (PolarisServiceImpl.AddGrantToCatalogRoleEntityWrapper) resp.getEntity(); | ||
| if (resp.getStatus() != Response.Status.BAD_REQUEST.getStatusCode()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| if (resp.getStatus() != Response.Status.BAD_REQUEST.getStatusCode()) { | |
| if (resp.getStatus() == Response.Status.CREATED.getStatusCode()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed per comment below.
| return Response.ok(catalogRoles).build(); | ||
| } | ||
|
|
||
| record AddGrantToCatalogRoleEntityWrapper( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These records have to be public, as they are potentially escaping the package (IOW, a decorator sitting outside this package would be unable to process the response returned by addGrantToCatalogRole).
These records are OK for now, but we need to include these structures in the OpenAPI spec for this service. Could you please add a TODO for that, or better yet, file an issue? WIthout proper inclusion in the OpenAPI spec, these structures become a form of "undocumented" API.
It seems the problematic endpoints are:
createCatalogcreatePrincipalRolecreateCatalogRoleaddGrantToCatalogRolerevokeGrantFromCatalogRole
All of them would need to have their response schema updated in the OpenAPI spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, this topic imo deserves a discussion thread in the ML.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense, I will start a new ML discussion regarding this. In the meantime, let me add TODOs for this and remove it for now from this PR to unblock the rest of the events.
| entityWrapper.polarisPrivilege(), | ||
| entityWrapper.grantResource(), | ||
| entityWrapper.cascade())); | ||
| return resp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, let's not include the entity in the response, since that would be a violation of the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, removing as per above comment.
| new PrincipalRoleEntity(adminService.createPrincipalRole(entity)).asPrincipalRole(); | ||
| LOGGER.info("Created new principalRole {}", newPrincipalRole); | ||
| return Response.status(Response.Status.CREATED).build(); | ||
| return Response.status(Response.Status.CREATED).entity(newPrincipalRole).build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we could standardize the usage of toResponse for all endpoints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not opposed to this, but let's do this in a different PR :)
| import org.apache.polaris.core.entity.PolarisPrivilege; | ||
|
|
||
| public class CatalogsServiceEvents { | ||
| public record BeforeCatalogCreatedEvent(String catalogName) implements PolarisEvent {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: still some naming inconsistencies: most events use a verb in the infinitive form (BeforeCatalogListEvent) but some use the past participle (BeforeCatalogCreatedEvent).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed!
| * @param privilege the privilege granted | ||
| * @param grantResource the grant resource | ||
| */ | ||
| public record AfterAddGrantToCatalogRoleEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, if we eventually modify the OpenAPI spec, I think each "after" event should take a response object that mirrors the "before" event and its request object. E.g.:
record BeforeAddGrantToCatalogRoleEvent(String, String, AddGrantRequest)
record AfterAddGrantToCatalogRoleEvent(String, String, AddGrantResponse)| { | ||
| PolarisPrivilege privilege = | ||
| PolarisPrivilege.valueOf(viewGrant.getPrivilege().toString()); | ||
| privilege = PolarisPrivilege.valueOf(viewGrant.getPrivilege().toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a requirement, but is a helpful refactor that will help in the future if/when we change the public API.
flyrain
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @adnanhemani for the PR. LGTM overall. Do we have tests for added events(catalog, principal, principal role)?
| return Response.status(successStatus).build(); | ||
| Response.ResponseBuilder responseBuilder = Response.status(successStatus); | ||
| return responseBuilder.build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change seems unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, this is a hangover from some other code I removed. Reverted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't look reverted yet 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, I don't know what happened and why it didn't pick up. Thanks for rechecking!
Made the changes now (and have verified)!
|
@flyrain - I haven't added the tests yet, but will add it in a follow up PR. I didn't want to saddle this PR with the extra LOCs for something that's quite straightforward and requires much closer attention to the details of the events themselves. |
…gs_principals_principal_roles
flyrain
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 Thanks @adnanhemani !
This PR adds the Events instrumentation for all APIs listed in the PolarisServiceImpl.java file, surrounding the default delegated call to the business logic APIs.