As a user, I want to query OpenSearch for staged data via a CLI command

[alexdunnjpl]

This is a duplicate/extension of a corresponding registry ticket

📖 Additional Details

@jordanpadams to suggest details for this new registry-mgr subcommand.

• Do we want to add a --raw option for making arbitrary OS queries? (Probably)
• What level of generalization do we want? Do we want something as specific as registry-mgr query-staged-data, or registry-mgr query-products --status <SOMESTATUS> (with potentially other options besides --status, or do we want to provide just a raw query interface like registry-mgr query-products @path-to-some-file.json?

⚖️ Acceptance Criteria

Given When I perform Then I expect

⚙️ Engineering Details

[jordanpadams]

@alexdunnjpl I think the last option sounds best:

or do we want to provide just a raw query interface like registry-mgr query-products @path-to-some-file.json

Then we can provide a cookbook of JSON "recipes" for various queries people may want to perform. this way we can build up this cookbook and just link off to the various JSON files.

@tloubrieu-jpl @alexdunnjpl thoughts?

[alexdunnjpl]

@jordanpadams If that's the case, what's the difference between our new CLI command (which will presumably still take OpenSearch URL and auth file as arguments), and a simple-enough curl call?

Arguably we're abstracting away the implementation detail of our backend being OpenSearch, but is that useful?

I think that if we're going to bother to do this, it may be worth considering unifying the configuration (OS url, auth, etc) within a single file - assuming that the typical use-case is that a single deployment works with a single OpenSearch instance. Then you actually get some return on investment because you can

registry-mgr query @path/to/something.json

and the need to point to your OS instance and auth file is obviated.

Does that scan?

[tloubrieu-jpl]

The registry dashboards are fulfilling this requirement, see https://github.com/NASA-PDS/registry/issues/148