Upgrade martin

[michael-markl]

Short description

Upgrades martin from a super old version to 0.13.0

Proposed changes

As the url scheme of martin has changed in version 0.7.0 , we need to add an nginx rewrite rule for backwards compatibility. We'll need to keep this rewrite rule until all clients have a freh style.json.

Side effects

THIS CHANGE HAS TO BE DEPLOYED IN SYNC WITH THE SALT CONFIG CHANGE IN https://git.tuerantuer.org/DF/salt/pulls/155

Also, I fixed the local setup (http://localhost:5002/map.html) and added buttons to switch between bayern and nuernberg.

Resolved issues

Fixes: #1122 #1439

[ztefanie]

Thanks for this update. Looks good, but I do not really understand what you did, so maybe another review would be nice.

[f1sh1918]

@michael-markl can you give me some instructions how to test it. If i restart the docker containers i get an error for martin.
I also tried with --force-recreate

2024-05-14 11:03:21 [2024-05-14T09:03:21Z INFO  martin] Using /app/config.yaml
2024-05-14 11:03:21 [2024-05-14T09:03:21Z ERROR martin] Can't read config: Can't read config file: missing field `connection_str

[michael-markl]

@f1sh1918 Hmm maybe docker did not pull the new image for you ? 🤔

I usually do docker compose down followed by docker compose up which would usually pull new images if the dockercompose file changed... What did you do?

[f1sh1918]

docker compose up

okay i now messed up my local dev setup :/
have to migrate and import db again

[michael-markl]

That is the normal workflow for me :D the database is usually dropped, as the image of postgres updates probably automatically. Maybe we need to fix the image of postgres

[f1sh1918]

That is the normal workflow for me :D the database is usually dropped, as the image of postgres updates probably automatically. Maybe we need to fix the image of postgres

ok. i never dropped the database so far until now. Just restarted the containers. But now the import of the stores is. finished and everything works fine.
One question. Can we merge and deploy the salt pr first without any issues? Should be backward compatible?

[f1sh1918]

Tested locally. works fine

[michael-markl]

One question. Can we merge and deploy the salt pr first without any issues? Should be backward compatible?

I think we cannot deploy one change before the other, as the new config for Martin only works with the new version of Martin... :/

(And right now we deploy the Martin binary via the entitlementcard repo - we may want to change this)

[f1sh1918]

One question. Can we merge and deploy the salt pr first without any issues? Should be backward compatible?

I think we cannot deploy one change before the other, as the new config for Martin only works with the new version of Martin... :/

(And right now we deploy the Martin binary via the entitlementcard repo - we may want to change this)

Ok i added some comments on the salt pr. it doesn't look that complicated to use the debian file. Just not sure about the .service file and we probably have to define the installation directory? i'm not very familar with debian packages tbh.

[michael-markl]

@f1sh1918 Should we merge this, and merge the corresponding salt PR once we deploy the backend?

[f1sh1918]

@f1sh1918 Should we merge this, and merge the corresponding salt PR once we deploy the backend?

I would appreciate this. We have some open issue how to avoid this deploy in sync. So maybe you could give some instructions how the process should be and we can make it at the conference with @svenseeberg

[michael-markl]

I think we have three options:

1. Keep it as is (martin is configured in salt, but the version of martin is controlled by the CircleCI). We need to deploy in sync, whenever the config of Martin needs to change with a version change of Martin (probably quite unlikely, this is the first time it happened afaik)
2. Somehow bundle the configuration of Martin in our entitlementcard package and make it configurable via a wrapped configuration file or so
3. Do not compile & bundle Martin at all in the entitlementcard package, but instead use the Debian package provided by martin's GitHub CI. Then the package and configuration can be changed synchronously in Salt.

However, probably it's just fine to do (1.) and take the risk to break the App for a short time.

[f1sh1918]

I think we have three options:

1. Keep it as is (martin is configured in salt, but the version of martin is controlled by the CircleCI). We need to deploy in sync, whenever the config of Martin needs to change with a version change of Martin (probably quite unlikely, this is the first time it happened afaik)
2. Somehow bundle the configuration of Martin in our entitlementcard package and make it configurable via a wrapped configuration file or so
3. Do not compile & bundle Martin at all in the entitlementcard package, but instead use the Debian package provided by martin's GitHub CI. Then the package and configuration can be changed synchronously in Salt.

However, probably it's just fine to do (1.) and take the risk to break the App for a short time.

Yes i meant what we have to do for option 1)
The main issue is i think that we can not apply the salt change on both servers (staging and production) at the same time.
When we create a beta release (on staging) it usually takes 2 weeks at least until its tested and can be promoted.
Therefore my suggestion would be to make a single release with this issue so the test timeframe will be shorter.
Maybe we could rebase your pr on the next git-tag. I really would like to release the koblenz issues first

In general we want to change this dependency between salt and the repo somehow. The worst thing is that the config.yml on the repo differs to the config.yml in salt (on the server)
Thats very error prone

[michael-markl]

In general we want to change this dependency between salt and the repo somehow. The worst thing is that the config.yml on the repo differs to the config.yml in salt (on the server)
Thats very error prone

I think the only way around this is to avoid making breaking changes to the (expected) structure of config.yml.