geonetwork-microservices - georchestra integration & divergences

[pmauduit]

codebase

As of today, we have a fork of the geonetwork/geonetwork-microservices repository:
https://github.com/georchestra/geonetwork-microservices

The default branch is geor-main, but it is unclear why it diverges from upstream/main.

CICD

• buildbot-side, there is a buildjob-geonetwork-microservices job, which packages the searching and ogc-api-records webservice, tracking the geor-main branch.
• GHA-side, we have one job specification, where only the searching microservice is being built.
• On the geor-main-2301 branch, the build is modified so that searching is no longer built, but ogc-api-records is.

configuration

• On https://github.com/georchestra/datadir/tree/master/geonetwork/microservices, we can see that both microservices have a suggested configuration, same in the docker-master branch.
• The ansible playbook also provides 2 templates for both microservices: https://github.com/georchestra/ansible/tree/master/roles/georchestra/templates/geonetwork

Issues

It is unclear what we do want to do with the geonetwork-microservices project into georchestra:

• What do we want to integrate ? searching ? ogc-api-records ? both ?
• which branch should be built ?
• is a fork still necessary ?

The main argument for keeping a fork is that we can control the version of the dependencies, e.g. making sure that we can build microservices which are compatible with the ES version being used in the geonetwork fork for geOrchestra.

[landryb]

• imo the fork is only necessary because there are no branches in the upstream repo, and we want to 'pin' the ogc-api-records to a version that matches the geonetwork we're shipping in georchestra.
• As of now, ogc-api-records from version 4.2.2 upstream works, not the one from master. Im not sure its only a matter of 'ES version' :)
• if ogc-api-records can supersede searching/provide a working rss feed, then it should be documented so that we can drop searching
• the last build from the bot matches the last commit on geor-main branch, eg georchestra/geonetwork-microservices@13ba7a9
• maybe we should rebase/merge upstream up to https://github.com/geonetwork/geonetwork-microservices/releases/tag/4.2.2 so that we build both working microservices in the buildbot ?
• georss - adding a simple endpoint accessible with a GET request geonetwork/geonetwork-microservices#72 tries to push the only commit that isnt upstreamed

[pmauduit]

• maybe we should rebase/merge upstream up to https://github.com/geonetwork/geonetwork-microservices/releases/tag/4.2.2 so that we build both working microservices in the buildbot ?

It is worth a try ...

[pmauduit]

We also should cleanup branches of the repository to make it clear which one is the relevant one.

[fvanderbiest]

Postponing to a 23.1 release ...

[pmauduit]

• buildbot-side, there is a buildjob-geonetwork-microservices job, which packages the searching and ogc-api-records webservice, tracking the geor-main branch.

We don't generate debian packages yet, do we ? If so we might also want it to provide a systemd service file.

[landryb]

i don't think there's the plumbing to generate debian packages for geonetwork microservices, but that'd be a nice addition indeed ! the systemd service files already exist in the ansible repo iirc

[pmauduit]

Also, the debian maven plugin we are using seems a bit outdated (last release on 2013): https://debian-maven.sourceforge.net/index.html
But someone forked it and there are some recent activites on it: https://fracpete.github.io/debian-maven-plugin/usage.html

In any of their respective documentations I could find anything related to packaging a systemd service though, but it is probably doable with a service file + a post-hook to daemon-reload systemd + starting the service.