Skip to content
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

[#3346] feat(core,server): Supports to list roles operations #4894

Merged
merged 22 commits into from
Sep 26, 2024

Conversation

jerqi
Copy link
Contributor

@jerqi jerqi commented Sep 9, 2024

What changes were proposed in this pull request?

Supports to list roles operations

Why are the changes needed?

Fix: #3346

Does this PR introduce any user-facing change?

Yes, will add the document later.

How was this patch tested?

Add UTs.

@jerqi jerqi marked this pull request as draft September 9, 2024 09:28
@jerqi jerqi force-pushed the ISSUE-3346 branch 3 times, most recently from 1981826 to 558ebba Compare September 9, 2024 11:15
@jerqi jerqi marked this pull request as ready for review September 14, 2024 06:35
@jerqi jerqi force-pushed the ISSUE-3346 branch 2 times, most recently from 944f676 to 3f2ee03 Compare September 19, 2024 10:05
@jerqi jerqi closed this Sep 19, 2024
@jerqi jerqi reopened this Sep 19, 2024
@jerqi jerqi changed the title [#2246] feat(core,server): Supports to list roles operations [#3346] feat(core,server): Supports to list roles operations Sep 23, 2024
@jerqi jerqi force-pushed the ISSUE-3346 branch 2 times, most recently from a6f60dd to 8fa67f4 Compare September 24, 2024 03:13
@jerqi jerqi force-pushed the ISSUE-3346 branch 3 times, most recently from 792e078 to d1fcbb5 Compare September 24, 2024 09:05
@jerqi jerqi self-assigned this Sep 24, 2024
*
* @return The scecurable objects count of the role.
*/
default int securableObjectsCount() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better rename to count(), what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we add more fields, it may be confusing for users. For example, if we add child role in the role in the future. If I use count, I don't know it's the child role count or objects count.

this.roleDTO = roleDTO;
this.securableObjectsSupplier =
new Supplier<List<SecurableObject>>() {
private boolean waitToRequest = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waitForRequset.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

if (waitToRequest) {
securableObjects = gravitinoMetalake.getRole(roleDTO.name()).securableObjects();
waitToRequest = false;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a lock here to avoid concurrency issue here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I can add the lock later.

@JsonProperty("securableObjects")
private SecurableObjectDTO[] securableObjects;

@JsonProperty("securableObjectsCount")
private int securableObjectsCount;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can also change to count here? Also, what is the serialization result of this field, "0" or "null'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name has similar reason above. This field is 0 if we don't have any objects in the role.

@Override
public List<SecurableObject> get() {
if (waitToRequest) {
securableObjects = gravitinoMetalake.getRole(roleDTO.name()).securableObjects();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can have a new API to get securable objects, rather than using get role API, you can follow what Tag did.

Copy link
Contributor Author

@jerqi jerqi Sep 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ever thought. But from my view, our role API can already get the objects. It's a little weird to add a new API to fetch partial data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's weird to get a role in a role from client side.

Copy link
Member

@xunliu xunliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problems that can be solved with an enumeration operation type. Get the 4 difficult concepts of SupportsDesiredFieldsHandlers.java, SupportsDesiredFields, skippingFields, and desiredFields.
I don't think it's a good design.

In particular, desiredFields and execute() in SupportsDesiredFields don't have a strong logical relationship

interface SupportsDesiredFields<R> {

  /**
   * The fields which could be desired.
   *
   * @return The fields which are desired.
   */
  Set<Field> desiredFields();

  /**
   * The return value of the handler.
   *
   * @return The return value of the handler.
   */
  R execute();
}

@jerqi
Copy link
Contributor Author

jerqi commented Sep 25, 2024

@xunliu @jerqi List role operation only supports to list role names. Otherwise, it will have poor performance if we fetch objects, or it will be inconsistent with other interfaces if we don't fetch objects.

@jerqi jerqi requested review from xunliu and jerryshao September 25, 2024 10:57
@@ -93,6 +95,10 @@ public Map<String, String> properties() {
*/
@Override
public List<SecurableObject> securableObjects() {
if (securableObjects == null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which case will it return null here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't be null. I modified.

@@ -186,9 +192,6 @@ public S withAudit(AuditDTO audit) {
public RoleDTO build() {
Preconditions.checkArgument(StringUtils.isNotBlank(name), "name cannot be null or empty");
Preconditions.checkArgument(audit != null, "audit cannot be null");
Preconditions.checkArgument(
securableObjects != null && securableObjects.length != 0,
"securable objects can't null or empty");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it still removable, or should be checked?

Copy link
Contributor Author

@jerqi jerqi Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add check this field isn't null. If the securable objects are deleted, the collection may be empty. So I remove the check whether it is empty.

@@ -64,8 +64,5 @@ public void validate() throws IllegalArgumentException {
Preconditions.checkArgument(
StringUtils.isNotBlank(role.name()), "role 'name' must not be null and empty");
Preconditions.checkArgument(role.auditInfo() != null, "role 'auditInfo' must not be null");
Preconditions.checkArgument(
role.securableObjects() != null && !role.securableObjects().isEmpty(),
"role 'securableObjects' can't null or empty");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it still removable, or should be checked?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto. Modified, too.

AuthorizationUtils.checkMetalakeExists(metalake);
Namespace namespace = AuthorizationUtils.ofRoleNamespace(metalake);
return store.list(namespace, RoleEntity.class, Entity.EntityType.ROLE, false).stream()
.map(entity -> (Role) entity)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

Comment on lines 136 to 140
String[] listRoleNames(String metalake) {
return Arrays.stream(listRolesInternal(metalake)).map(Role::name).toArray(String[]::new);
}

private Role[] listRolesInternal(String metalake) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can combine this two methods together, it is not necessary to separate for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

try {
AuthorizationUtils.checkMetalakeExists(metalake);
Namespace namespace = AuthorizationUtils.ofRoleNamespace(metalake);
return store.list(namespace, RoleEntity.class, Entity.EntityType.ROLE, false).stream()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like for role listing, we don't support allFields, only user interface supports this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean that for role, you don't even support this allFields field, so it is meaningless to set false here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this parameter.

@jerryshao jerryshao merged commit 912a424 into apache:main Sep 26, 2024
26 checks passed
github-actions bot pushed a commit that referenced this pull request Sep 26, 2024
### What changes were proposed in this pull request?
Supports to list roles operations

### Why are the changes needed?

Fix: #3346

### Does this PR introduce _any_ user-facing change?
Yes, will add the document later.

### How was this patch tested?
Add UTs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Need REST API to list all existing roles in a metalake
3 participants