Upgrade alpine docker image to Alpine 3.16

[cwhite911]

Is there a plan to upgrade the alpine docker image from alpine 3.15 to 3.16 or 3.17?

[mmacata]

No immediate plan - we don't update to every alpine version, e.g. last time we went from 3.12 to 3.15. But if there are much more recent packages / features / bugfixes contained, we of course consider this.
Is there any certain version you need?

[cwhite911]

I need Alpine 3.16 or 3.17 to upgrade R to v4.2 to meet some dependencies with the GRASS FUTURES model. I have a current workaround, so it's not urgent.

[ninsbl]

Alpine 3.18 (coming in may !?) would bring GDAL 3.6 which has security relevant improvements for users of MS SQL. Updates making GDAL 3.6 available would be very much appreciated (once available in Alpine).

[mmacata]

As currently there are some python dependency conflicts preventing the actinia dependencies Dockerimage build, we plan to wait for the alpine may release and fix it all at once.

[mmacata]

Although we decided to not make too many changes at once just recently anymore :D
After our last update of alpine and from GRASS GIS 7 to 8 we had some strange behaviours and it took a while to figure out what the reason was.
So for this update it would be nice to have one intermediate version for testing to see that everything is still running smoothely.

[ninsbl]

Good point! What would you suggest as intermediate version(s)?

• GRASS 8.2 with alpine 3.17/3.18 or
• GRASS 8.3 with Alpine 3.15?
  I really would like to use 8.3 with actinia, so I could do some testing...

[ninsbl]

BTW: Should the snap docker repo be added to actinia-org as well?

[mmacata]

Good point! What would you suggest as intermediate version(s)?

• GRASS 8.2 with alpine 3.17/3.18 or
• GRASS 8.3 with Alpine 3.15?
  I really would like to use 8.3 with actinia, so I could do some testing...

Maybe first GRASS 8.3 with Alpine 3.15, if the new GRASS GIS is released not after the new alpine version. Usually that update is much more smooth and less effort than the alpine one.

[mmacata]

BTW: Should the snap docker repo be added to actinia-org as well?

Slight tendency to "no" - there is no actinia included and with multistage build it is easy to use it independently of the repository. it is easy to make use of it independent of the repository.

[ninsbl]

OK, I built actinia with GRASS GIS 8.3 now (Alpine 3.15). Will test how that behaves and report back.

Meanwhile, Alpine 3.18 is out. And the biggest obstackle that I encountered for now (or the first blocker in a way), is snappy, which does not seem work with more recent Python/jpy versions. See e.g.:
https://forum.step.esa.int/t/problem-installing-snappy-on-mac-m1/37032

The problem in short: Snappy does not support jpy > 0.9.0 and jpy <= 0.9.0 does not work with Python > 3.9...

[ninsbl]

Just got a reply on the SNAP forum (link above) that this will be addressed end of june.

[mmacata]

😳 thats far away

[ninsbl]

BTW: do you have any pointer to documentation on running the actinia test cases with custom docker images?

[mmacata]

We only have the documentation to run tests locally: https://github.com/actinia-org/actinia-core/blob/main/tests/README.md

[mmacata]

Update:
While we updated to alpine 3.18 without using snappy so far, we plan to update also GRASS GIS to 8.3 within the next weeks.

[ninsbl]

Personally, I would not miss snappy. Performance of using gpt directly appears to be way better.
If you mainly use it for Geocoding of Sentinel-1 images, you may have a look here: https://github.com/NVE/actinia_modules_nve/blob/main/src/imagery/i.sentinel1.pyrosargeocode/ for a solution with pyrosar and without snappy.
I hope I will be able to merge the addons that can be of more general interest into the official addons repo at some point in time...

[mmacata]

ah cool! We will definitely look into this :)

[neteler]

(tracked at #467)