Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch
2017-06-02 10:30 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
On Fri, 2 Jun 2017, 08:56 Gunnar Morling, <gunnar(a)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(a)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-amazo...
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev