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

Starred requests persistence #1219

Merged
merged 55 commits into from
Nov 22, 2016
Merged

Starred requests persistence #1219

merged 55 commits into from
Nov 22, 2016

Conversation

MattCCS
Copy link
Contributor

@MattCCS MattCCS commented Aug 15, 2016

This PR enables "starred" Singularity requests to persist in Zookeeper, rather than be stored client-side, so clearing the cache or changing devices won't require re-starring.

/cc @ssalinas @tpetr

@Calvinp
Copy link
Contributor

Calvinp commented Aug 15, 2016

Are we still planning on having endpoints to add or remove one star at a time?

@ssalinas
Copy link
Member

@MattCCS as part of the implementation, I believe we also discussed adding the SingularityUserSettings into the SingularityUserHolder object so we can grab things on the /auth/user call when possible. Can we add that in?

public void setUserSettings(
@ApiParam("The user id to use") @QueryParam("userId") String userId,
@ApiParam("The new settings") SingularityUserSettings settings) {
userManager.updateUserSettings(SingularityValidator.encodeZkName(userId), settings);
Copy link
Contributor

Choose a reason for hiding this comment

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

this ZK encoding stuff should be inside UserManager -- the point of it is to encapsulate away all ZK-related stuff

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will fix.

private String getAuthUserId() {
checkBadRequest(user.isPresent() && user.get().getName().isPresent(), "Singularity userId must be provided by auth");
return user.get().getName().get();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This method needs some work:

  • The error message isn't accurate because we're not using the userId query param anymore.
  • Being unauthenticated should return an Unauthorized response, not a Bad Request response. Use SingularityAuthorizationHelper as a guide here; it uses checkUnauthorized(user.isPresent(), "Please log in to perform this action."); for stuff like this.
  • It's using the name field of SingularityUser (Thomas Petr) when it should be using the id field (tpetr).

Copy link
Contributor Author

@MattCCS MattCCS Sep 2, 2016

Choose a reason for hiding this comment

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

Ah, my bad. So, should I be checking authEnabled before I do the checkAuthorized() call (as happens in SingularityAuthorizationHelper)? Or should I just be calling checkAuthorized() every time?

@ssalinas ssalinas modified the milestones: 0.11.0, 0.12.0 Sep 14, 2016
@ssalinas ssalinas added the hs_qa label Oct 31, 2016
@@ -2,6 +2,8 @@

import static com.google.common.base.Preconditions.checkNotNull;

import javax.ws.rs.HEAD;
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 this came in from a merge conflict

@ssalinas ssalinas modified the milestones: 0.12.0, 0.13.0 Nov 4, 2016
@ssalinas
Copy link
Member

@tpetr any problem with merging this one now?

@tpetr tpetr merged commit 20f0b94 into master Nov 22, 2016
@tpetr tpetr removed hs_qa labels Nov 22, 2016
@ssalinas ssalinas deleted the starred_requests_persistence branch February 8, 2017 16:09
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.

5 participants