search

kadaster-labs / sensrnet-helm-charts

Other
0 stars 0 forks source link

MongoDB migraties uitvoeren tijdens helm upgrade #43

Closed kad-floriw closed 2 years ago

kad-floriw commented 2 years ago

Toevoegen van een job, die de nog-niet uitgevoerde mongoDB migraties uitvoert. Deze wordt uitgevoerd na een helm install / upgrade van de backend, door middel van een helm hook.

marcvanandel commented 2 years ago

Fancy! Dit ziet er wel goed uit ... maar hoe test ik dit? Kan ik gewoon een install doen in mijn lokale cluster?

marcvanandel commented 2 years ago

Afhankelijk van je client ... maar ik krijg deze melding:

batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
kad-floriw commented 2 years ago

Afhankelijk van je client ... maar ik krijg deze melding:

batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob

Dit heeft te maken met de CronJob die gebruikt wordt om de eventstore op te ruimen, dat is niet gerelateerd aan deze PR maar kan wel meegenomen worden!

kad-busses commented 2 years ago

Gaaf! 😎 Zal er naar kijken en testen. Schieten me alvast een paar vragen te binnen:

  1. Kunnen we een rollback kunnen doen in dit scenario? Ben hier zelf over na aan het denken, maar had je daar zelf ook aan gedacht? Het mooie van K8s is natuurlijk dat we eenvoudig tussen versies kunnen switchen en eenvoudig kunnen terugrollen, mocht er een fout in een nieuwe versie zitten
  2. En nog een stapje terug: Had je ook gekeken naar de optie om de view opnieuw op te bouwen? Blijft een beetje vreemd voelen om de projectie te bewerken, doen we dan eigenlijk niet dubbel werk?
  3. Denk niet dat de migrate: true hoeven toe te voegen, daarmee kunnen we/partijen immers ook de migrate onterecht skippen 😉

Kubernetes v1.25 is nu nog niet uit, verwachting is later dit jaar. De ES cronjob hoeft die niet direct, maar mag in een andere PR 😄

kad-floriw commented 2 years ago

Gaaf! 😎 Zal er naar kijken en testen. Schieten me alvast een paar vragen te binnen:

  1. Kunnen we een rollback kunnen doen in dit scenario? Ben hier zelf over na aan het denken, maar had je daar zelf ook aan gedacht? Het mooie van K8s is natuurlijk dat we eenvoudig tussen versies kunnen switchen en eenvoudig kunnen terugrollen, mocht er een fout in een nieuwe versie zitten
  2. En nog een stapje terug: Had je ook gekeken naar de optie om de view opnieuw op te bouwen? Blijft een beetje vreemd voelen om de projectie te bewerken, doen we dan eigenlijk niet dubbel werk?
  3. Denk niet dat de migrate: true hoeven toe te voegen, daarmee kunnen we/partijen immers ook de migrate onterecht skippen 😉

Kubernetes v1.25 is nu nog niet uit, verwachting is later dit jaar. De ES cronjob hoeft die niet direct, maar mag in een andere PR 😄

1) Dat zit er nog niet in, het lijkt mij vrij ingewikkeld om dat te implementeren, en bij andere projecten hebben we het ook niet. Misschien een ticket op de backlog van maken? 2) Dat zou in principe ook kunnen, maar dan moet eerst de database geleegd worden waarna alle events opnieuw uitgevoerd worden. Ik vind dat zelf een ietwat omslachtige methode, maar ik weet niet of het binnen event-sourcing gebruikelijker is, misschien weet jij dit @marcvanandel?

kad-floriw commented 2 years ago

Ik testte nog met een oude versie van het deploy_local_images.sh script. Met de nieuwe versie waarin de backend in 1 stap gedeployed wordt is het eenvoudiger, ik heb de migrate optie verwijderd!

kad-floriw commented 2 years ago

Dat maakt het nog iets netter inderdaad.