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

SOLR-16393 Cosmetic, REST-fulness improvements to v2 alias, alias-prop #1332

Merged
merged 9 commits into from
Mar 6, 2023

Conversation

stillalex
Copy link
Member

@stillalex stillalex commented Feb 3, 2023

https://issues.apache.org/jira/browse/SOLR-16393

Description

List Aliases apis only.

Solution

List Aliases api responses:

curl -X GET 'http://localhost:8983/solr/admin/collections?action=LISTALIASES' | jq

{
  "responseHeader": {
    "status": 0,
    "QTime": 0
  },
  "aliases": {
    "testalias1": "collection1",
    "testalias2": "collection2,collection1"
  },
  "properties": {
    "testalias2": {
      "someKey": "someValue"
    }
  }
}
curl -X GET http://localhost:8983/api/aliases | jq

{
  "responseHeader": {
    "status": 0,
    "QTime": 1
  },
  "aliases": {
    "testalias1": "collection1",
    "testalias2": "collection2,collection1"
  },
  "properties": {
    "testalias2": {
      "someKey": "someValue"
    }
  }
}
curl -X GET http://localhost:8983/api/aliases/testalias2 | jq
{
  "responseHeader": {
    "status": 0,
    "QTime": 1
  },
  "name": "testalias2",
  "properties": {
    "someKey": "someValue"
  }
}

Tests

Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
  • I have created a Jira issue and added the issue ID to my pull request title.
  • I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.
  • I have added tests for my changes.
  • I have added documentation for the Reference Guide

@stillalex
Copy link
Member Author

stillalex commented Feb 3, 2023

@gerlowskija if you have some time, please take a look!
Just to clarify this is for list alias, to review and confirm the approach is ok, will extend the PR to other apis next.

@gerlowskija
Copy link
Contributor

Hey, thanks for the PR Alex.

A lot of these have been blocked for awhile on SOLR-16531, but that's close enough to closed out that we should be good to start transitioning APIs again. I'll take a look shortly!

Copy link
Contributor

@gerlowskija gerlowskija left a comment

Choose a reason for hiding this comment

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

list-aliases API looks great @stillalex. Left a comment or two but nothing of import.

You're planning to add a few other APIs to this PR it sounded like, or do you want to handle those in separate PRs? (Either approach works for me 🤷 )

* </code> API.
*/
@Path("/aliases")
public class GetAliasesAPI extends AdminAPIBase {
Copy link
Contributor

Choose a reason for hiding this comment

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

[0] Nitpick that you can def ignore, but I'd prefer the name ListAliasesAPI for this class instead. Right now Solr has no API to fetch information about a single alias, but it'd be a reasonable API to add at some point. And if that ever happens, it'd be hard for a reader to distinguish between GetAliasesAPI and GetAliasAPI without a double-take 😆

Copy link
Member Author

Choose a reason for hiding this comment

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

sure, renaming makes sense

@stillalex
Copy link
Member Author

thanks for talking a look. I think I wanted to have a more complete PR with all apis. will try to add more to this, but if it turns into too much code, I will opt for splitting, it will also make the review a bit easier I guess.

.gitignore Outdated Show resolved Hide resolved
@gerlowskija
Copy link
Contributor

Small heads up for you @stillalex - I know it's tempting to force-push, but we've found that it can do weird things to Github comment history and make PRs just that bit harder to review. Obviously sometimes things get messy and you have to do what you have to do, but try to avoid those where you can at least please!

Copy link
Contributor

@gerlowskija gerlowskija left a comment

Choose a reason for hiding this comment

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

Hi Alex - everything here looks great, but there's one tiny piece missing:

There's actually a v2 API in the class ClusterAPI that implements the list-alias functionality. We should delete that and remove its registration from CollectionsHandler.

It should only take a minute or two so I'll take a crack at that, and run the tests again. Other than that though, this all looks good to go!

@gerlowskija
Copy link
Contributor

Alright, I fixed the ClusterAPI duplicate I mentioned, but in the process I found a few other things that were worth discussing here.

Specifically, the response that comes back from GET /api/aliases/aliasName isn't very useful. It's great that it returns the the free form properties. But there's not even a mention of the collections that the alias is a stand-in for.

$ curl -sk -X GET "http://localhost:8983/api/aliases/alias1" | jq '.'
{
  "responseHeader": {
    "status": 0,
    "QTime": 1
  },
  "name": "alias1",
  "properties": {}
}

AFAICT GET /api/aliases/aliasName is a brand new API, so we have some freedom to make the response format whatever we would like here. Would you be amenable to adding the collection-list to this response, or was there a reason you avoided that on your initial pass?

@stillalex
Copy link
Member Author

AFAICT GET /api/aliases/aliasName is a brand new API, so we have some freedom to make the response format whatever we would like here. Would you be amenable to adding the collection-list to this response, or was there a reason you avoided that on your initial pass?

ouch, good catch! you are absolutely right, I missed this completely. for sure the collections list needs to be present. any preference on the format? what about 'collections' (similar to the name used when creating the alias)?

"name": "alias1",
"collections": "collection1",
"properties": {}

@stillalex
Copy link
Member Author

@gerlowskija added the new entry in the response, a test for the new api and updated the guide. please take a look!

@stillalex
Copy link
Member Author

@gerlowskija gentle ping. please take another look and let me know your thoughts

@gerlowskija
Copy link
Contributor

Hey, sorry for the delay in circling back to this @stillalex - will take a look shortly with a mind to commit.

Screen Shot 2023-03-06 at 1 53 57 PM

Careful about doing this. If I'd happened to push up some tweaks or something around the same time, they could've been blown away. It also does weird things with line-level review comments in the Github UI, that can be a bit of a pain when reviewing.

@gerlowskija
Copy link
Contributor

Force-pushes also break this really nice UI feature that Github has of, "Only show me what's changed since the last time I posted a review", fwiw.
Screen Shot 2023-03-06 at 2 17 58 PM

Copy link
Contributor

@gerlowskija gerlowskija left a comment

Choose a reason for hiding this comment

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

LGTM; only one minor comment that I can cleanup prior to merge.


final CoreContainer coreContainer = fetchAndValidateZooKeeperAwareCoreContainer();
ZkStateReader zkStateReader = coreContainer.getZkController().getZkStateReader();
// if someone calls listAliases, lets ensure we return an up to date response
Copy link
Contributor

Choose a reason for hiding this comment

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

[-0] Small nit: copy/paste issue with 'listAliases'.

Relatedly though, maybe this code should be pulled into a private helper method that both getAliasByName and getAliases can call, to cut down on duplication.

Copy link
Member Author

Choose a reason for hiding this comment

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

looks good

@gerlowskija gerlowskija merged commit ef49422 into apache:main Mar 6, 2023
@stillalex
Copy link
Member Author

thank you @gerlowskija for the help in getting this merged!

@stillalex stillalex deleted the SOLR-16393 branch March 7, 2023 23:18
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.

2 participants