Use the workaround if we can't determine the server's version

[bartbroere]

This is related to issue #580

In some scenarios (a limited-scope API key, or maybe a corporate environment) a user of eland might not have enough permissions to determine the host's Elasticsearch version.

In that case, we could default to using the workaround, to be sure.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[pquentin]

buildkite test this please

[pquentin]

buildkite test this please

[pquentin]

I'm happy to do this is it unblocks you, but note that there are other places where we look at the ES version in the same way that would break similarly.

[bartbroere]

I'm happy to do this is it unblocks you, but note that there are other places where we look at the ES version in the same way that would break similarly.

Thanks! I noticed too that it was used in some other places. This one is probably in the place someone is most likely to encounter it. You get to this code by instantiating an eland DataFrame I believe.

Of course I'm still trying to find out if we could grant monitor/main privileges to all users in our organisation, but for now this would be very helpful.

[droberts195]

Of course I'm still trying to find out if we could grant monitor/main privileges to all users in our organisation

cluster:monitor/main literally just gives access to the / endpoint, which I find hard to believe is a security risk to allow for any user who legitimately has access to the cluster to do anything else. We probably ought to make it easier to grant access to this endpoint alone instead of requiring an obscure action name to be granted. But until then I don’t think it would be a security risk to add it manually to some of the other roles you have defined.