On Sat, Mar 2, 2019 at 3:31 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On 2/26/19 11:38 AM, Clement Verna wrote: > > Hi all, > > > > fedora-packages [0] code base is showing its age. The code base and > > the technology stack (Turbogears2 [1] web framework and the Moksha > > [2] 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 [3]) 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 > > - Javascript 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? > > 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? > > 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? > openSUSE has a package search system[1] that can leverage AppStream data too, but I'm not sure how its backend works. I think it currently leverages OBS specific APIs. As for Debian's package search system[2], it looks like a nightmare... :( Mageia's App DB[3] is similar to openSUSE's system, but I can't quite tell if it's just only Mageia branded or relies on Mageia-specific things. It seems to have some aspects of Bodhi in it too... As insane as it is, it looks like our existing system is the most distro agnostic approach I've seen! It's relatively easy to use it for any arbitrary set of repositories, and the branding is easy enough to swap out. It's mainly a matter of disabling the code to talk to Bodhi and simplify the package view page to remove the Fedora-specific bodhi and fedmsg integration stuff. If it had the ability to handle Debian packages, it'd probably be a decent replacement for a number of these. But then again, our tool doesn't necessarily need to be aware of the difference between RPMs and DEBs, because it uses mdapi, and an alternative implementation for Debian repos would be sufficient to make it work. [1]: https://github.com/openSUSE/software-o-o [2]: https://salsa.debian.org/webmaster-team/packages [3]: https://github.com/agallou/mageia-app-db -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
