On Sat, 2 Mar 2019 at 21:36, Kevin Fenzi <kevin(a)scrye.com> wrote:
On 2/26/19 11:38 AM, Clement Verna wrote:
> Hi all,
> fedora-packages  code base is showing its age. The code base and
> the technology stack (Turbogears2  web framework and the Moksha
>  middleware) is currently not ready for Python3 and I am not
> planning to do the work required to make it Python3 compatible, so the
> application will stop working when Fedora 29 is EOL.
> In order to keep the service running, I have started a Proof Of
> Concept (fedora-search ) to replace the backend of the application.
> Fedora-search would be a REST API service offering full test search
> API. Such a service would then be available for other application to
> use, fedora-packages would then become a frontend only application
> using the service provided by fedora-search.
> While the POC shows that this is a viable solution, I don't think that
> we should be proceeding that way, for the simple reason that this add
> yet another code base to maintain, I think we should use this
> opportunity to consider using Elasticsearch instead of maintaining our
> own "search engine".
> I think that Elasticsearch offers quite a few advantages :
> - Powerful Query language
> - Python bindings
> - Can be deployed in our infrastructure or used as a service
> - Can be useful for other applications ( docs.fp.o, pagure, ??)
> So what is the general feeling about using Elasticsearch in our
> infrastructure ? Should we look at deploying a cluster in our infra /
> Should we approach the Council to see if we can get founding to have
> this service hosted by Elastic ?
Well, I am not sure this could really work, but I don't know enough
about ES to say. What would the frontend look like?
The frontend will be an independent application that we will need to
develop or as suggested by Ryan we may explore using src.fp.o. Having
a separated backend for search capabilities makes a lot of sense to me
since that makes this service easy to reuse by other apps and let
people write their custom client if they wish to do so.
I think users currently use packages to look at information about
packages in a structured way. A "homepage" for the package if you will.
I am sure ES could pull the rpm data and let people search it, but could
it show a nice page with all the various types of information about a
particular package? Or would it just say "here's the first page of your
search results" and let users have to try and craft a search result that
will find the info they are looking for? I think that would be a pretty
big step back.
I agree with the points smooge brought up eariler about us running it
(rpm difficult, etc), but now we do have openshift and it does ship with
ES and might be easy to add to an app. But I am not sure if that helps
if we still need a app to use it, xiapan isn't the issue here right?
With the idea to have a separate search backend with HTTP API, xapian
is a problem since we have to write the HTTP wrapper around xapian's
API to make it available to all, there is xapiand
) but the project seems fairly recent and
not yet mature. The other benefits of Elasticsearch are a maintained
largely adopted solution (easier to get people interested in).
Finally, I wonder if we could look at what other distros do? Could we
work with say debian on theirs and add ability to theme it and handle
rpm vs deb data?
Yes +1 that's sounds like a good idea.
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: