[hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Gunnar Morling]

2017-06-02 10:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>
> On Fri, 2 Jun 2017, 08:56 Gunnar Morling, <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I find the exposure of an implementation detail (usage of Apache HTTP
>> client) of the Elasticsearch client a bit problematic. If they change
>> this to another HTTP client, our SPI would break.
>
>
> Yes the very point of exposing that detail is the reason for this thread.
>
> Still, our SPI being guaranteed only for a minor, that gives a lot of
> flexibility?
>
> The Elasticsearch client exposing this itself, I don't expect them to switch
> implementation in a micro release to make some bugfix. If they change it in
> a major or even minor version, we're ok to not support that version until
> our next minor.

It might be covered by the HSEARCH rules for evolvement, but
personally I think it's just not a good practice to leak internals of
a dependency in our SPI.

>
>
>>
>> Did you instead consider to just let users provide their custom
>> instance of org.elasticsearch.client.RestClient? It's still leaking an
>> implementation detail of Hibernate Search, but at least it's one
>> indirection less.
>>
>> People wishing to have a custom RestClient would have to implement a
>> few more bits themselves (the logic from
>> DefaultElasticsearchClientFactory#customizeHttpClientConfig()), but
>> I'd find that acceptable for the sake of a less detail-exposing SPI,
>> plus it grants more flexibility in terms of configuring the
>> RestClient.
>
>
>
> N.B. The client factory already is a Service so any advanced user already
> can override it.

The contract is defined under impl, though. Nothing users should
consider to implement. Unless you mean to promote it to SPI proper?

>
> We want to make it easier for cloud users. Focusing on AWS now as we've had
> user requests for this - not least our own CI - but I'd expect other clouds
> to have similar features (today or tomorrow). I just don't expect other use
> cases to need this so we might provide them all eventually, but at this
> point my goal is to leave an appealing SPI for contributors to join on that.
>
> With that I mean:
> 1# this might evolve but we need something simple to use for people to not
> get stuck.
> 2# I expect integrator implementors to contribute them back
> 3# People won't have this low level dependency in their projects for long
>
> Having them re-implement the client wouldn't encourage this ;)

You could provide an AWS-based implementation of the client factory
either as an example or in a separate module. So people can easily
make use of it, but usage of the HTTP client isn't exposed in core
SPIs. Also that way you don't commit to a low-level SPI now but rather
can gain experiences with the custom client factories people create
and evolve from there.

>
> Thanks!
> Sanne
>
>>
>> --Gunnar
>>
>>
>> 2017-06-01 19:11 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> > Yoann has been working on allowing Hibernate Search users to use
>> > Elasticsearch on AWS.
>> >
>> > Specifically on AWS the Elasticsearch security can be configured to
>> > use application identities, which implies the requests need to be
>> > signed.
>> >
>> > A good background read can be found here [1].
>> >
>> > We planned to allow people to use this but were not planning to
>> > include AWS specific libraries as dependencies - but since Yoann
>> > implemented an actual AWS signer in the tests I suppose it would be
>> > selfish to not ship it..
>> >
>> > Please see the API proposal on github (with the PR):
>> >  - https://github.com/hibernate/hibernate-search/pull/1426
>> >
>> > Thanks,
>> > Sanne
>> >
>> > [1] -
>> > https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazon-elasticsearch-service-domain/
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev