[FEATURE] Add OpenSearch configuration for SDKClient to read to

[owaiskazi19]

Is your feature request related to a problem?

Currently the extensions.yml file doesn't have configuration of OpenSearch such as address and port to connect to. After integrating SDKClient with an extension it requires the above mentioned attributed to connect to.

What solution would you like?

Add address and port getters in ExtensionSettings

What alternatives have you considered?

A clear and concise description of any alternative solutions or features you've considered.

Do you have any additional context?

Add any other context or screenshots about the feature request here.

[dbwiddis]

When we start up an extension, it listens on its configured port and when it receives the "init" transport request from OpenSearch it then has access to an OpenSearchNode object with this data.

I don't have a strong argument against defining these here, but it duplicates configs and I'd really like to understand the reasoning for it. For example, is it intended to support a use case where we start an extension after OpenSearch is already started up, and thus doesn't send the init request?

[owaiskazi19]

I created this for the use case like. To invoke the method getOpenSearchNode we have to make it static and set the Node before that. I am trying to avoid it and add the hostAddress and port in the yml file. This will also help us if one extension wants to talk to another then we can change the hostAddress and port. Let me know WDYT.

[dbwiddis]

I created this for the use case like.

Thanks for the example. I thin the problem is real but this is not the right solution. This is actually a much wider issue with anything else we need from OpenSearch like knowing if dependencies are initialized (#149), getting OS settings (#157), and obtaining information from dependent extensions (settings, namedXContent, etc.) that has been registered first.

The problem we have is our initialization sequence:

1. We start up the extension, but the OpenSearch node isn't even running. (So no connections can be established.)
2. When OpenSearch starts up, it sends an initialization request, which allows the ExtensionsRunner to know the OpenSearch node settings. This also triggers various actions to "initialize" the extension. This includes sending a list of REST handlers, sending extension settings, etc. to OpenSearch.

With NamedXContentRegistry I'm trying to work around this in two phases:

1. Instantiate the registry object on ExtnsionsRunner init and send it to the extension (create components)
2. After initialization, update the registry object with the new information.

I think we may need to take the same approach with SDKClient, initializing the object on startup but then setting the host/port later in the initialization sequence.

I think we should discuss the whole initialization sequence in #94, and update DESIGN.md to reflect what's decided there.

[dbwiddis]

Alternately, at least from a host/port standpoint, this may be needed for the "add an extension to an already running OpenSearch" use case, which should also be discussed in #94.

[owaiskazi19]

Based on a primary (future) use case of enabling extensions to connect to an already-running OpenSearch cluster until #94 is done.