added encoded API key placeholder for updated api_key elasticsearch authentication.

[SamoraHunter]

No description provided.

[preciserobot]

The documentation on the elasticsearch python library is quite non-specific but it appears the api_key username:password tuple is the (api_key.id, api_key.api_key), as described here.

We generally issue key ID and the key secret (plain and base64 encoded), so we should be able to use the existing implementation with some added documentation.

CORRECTION: We do not currently issue the key ID but the key name. I can change this internally to make it compatible with the current version of this repo.

[SamoraHunter]

The documentation on the elasticsearch python library is quite non-specific but it appears the api_key username:password tuple is the (api_key.id, api_key.api_key), as described here.

We generally issue key ID and the key secret (plain and base64 encoded), so we should be able to use the existing implementation with some added documentation.

CORRECTION: We do not currently issue the key ID but the key name. I can change this internally to make it compatible with the current version of this repo.

That link is for version 7.17,

I think the version we're running is https://www.elastic.co/guide/en/elasticsearch/client/python-api/8.17/connecting.html

api_key="api_key",

The jupyterhub docker image also users 8.17:
https://github.com/CogStack/cogstack-jupyter-hub/blob/master/requirements.txt

[preciserobot]

The documentation on the elasticsearch python library is quite non-specific but it appears the api_key username:password tuple is the (api_key.id, api_key.api_key), as described here.
We generally issue key ID and the key secret (plain and base64 encoded), so we should be able to use the existing implementation with some added documentation.
CORRECTION: We do not currently issue the key ID but the key name. I can change this internally to make it compatible with the current version of this repo.

That link is for version 7.17,

I think the version we're running is https://www.elastic.co/guide/en/elasticsearch/client/python-api/8.17/connecting.html

api_key="api_key",

The jupyterhub docker image also users 8.17: https://github.com/CogStack/cogstack-jupyter-hub/blob/master/requirements.txt

The docs for 8.17 still show the string|tuple|None signature. Looks like this is retained here.

Indeed the implementation for elasticsearch-py 8.17 confirms this here:
client/__init__py:143,430
_base.py:128
utils.py:254

[mart-r]

As mentioned in the comment, we still need to support the old API-based authentication, e.g:

CogStack(hosts, username=api_username, password=api_password, api=True)

That's (as far as I'm aware) used on the GSTT side.

And the other issue was the API key being a * import rather than an argument to the constructor.

What I would suggest is as follows:

• Add an optional api_key argument to __init__, defaulting to None
  • Along with documentation to the doc string
• If api_key is non-None, and api is True, use the new Elasticsearch init
• If api_key is None and api is True, use the previous authentication system

[mart-r]

So the problem with this change is the fact that this still needs to work with old system as well.
Perhaps it's an underlying Elastic version that's used there. But the last time I used this at GSTT (around 6 months ago) they relied on the old authentication method - which this PR removed.
To be explicit about it, something like this would still need to work:

CogStack(hosts, username=api_username, password=api_password, api=True)

The other issue is that now, api_key is received from an * import from credentials rather than as an argument to the constructor. While this can work, it's a significant change in operations.

[mart-r]

In favour of #19

[SamoraHunter]

Thanks all and thanks for the help.