OFN v2 rollout plan


OFN v2 is almost ready to go.

We need to define our roll out plan.
In the last upgrade catch up meeting we have agreed that:

  • We will send an email to Katuma users to let them know about the deploy of v2
  • We will clearly define how to reach Katuma’s support for that
  • We will schedule downtime for the deploy
  • Deploy v2 to Katuma on April 29th
  • Deploy to another small instance (likely Canada) on May 6th
  • Deploy the 3 big instances after the gathering
  • Deploy the rest (still not clear exactly when)

re Katuma’s date , @sauloperez wrote this plan himself so I assume he agrees with it :smile:

re CAN’s date, @tschumilas said on slack: “May 6 is actually a really good day for this in Canada. Our 2 larger more complex hubs (ie: using inventories…) look like they are closing their cycles on May 5, 8:00 pm our time. So big users won’t be ‘up’ again until May 8. Other users right now are smaller single farm stores -so not very complex. I can reserve May 6 & 7 for issues, and I’ll email users to let them know - what exactly? OFN is down? Or just altering they might see changes? So happy to help support this anyway I can.”

We can use this thread to discuss the plan and then for the specific details of the release we can use the normal release issue, here’s the v2 release gh issue.


Upgrades, rollouts and potential blockers

An update. I discussed it with Guida and she claims that Mondays are not so good day as many hubs close their OCs that day, and so we better deploy on Tuesday. I want to check the reality in Matomo though.

I’ll keep you posted.

1 Like


hello, my suggested approach.

Somewhere before the April 30th:

  • prepare both v1.31.0 and v2.0.0 (details about code branches here)

April 30th:

  • release v1.31.0 to all instances except Katuma that gets v2.0.0.

May 6th

  • release v2.0.0 to CAN

Maybe the 30th of April is too early, shall we move Katuma to the 6th as well Pau? Or maybe start with CAN on May 6th?



Just one concern on my side:

April 30th: release v1.31.0 to all instances except Katuma that gets v2.0.0.

To make this work on the testing side I need to be able to start testing at least next Wednesday (April 24th). Is it doable from a dev perspective?

I would then need to give you the result of the tests by at least Thursday so you have time to get the release published or do a spike of the remaining bugs that I found.

I can make room for two release testings, but if @lin_d_hop you have room to take one of them it could be a good thing. I’m really afraid of missing a bug because I would be doing the same thing over and over again during a short period of time :frowning:



I’ll take one of them on @Rachel. I’ll wait for your direction as to which.



I’m not a super tester or anything so grand - but I can also help testing v2 - but realistically - I won’t do much until after Easter (so apr 23/24 ish) - and I’ll let @Rachel know if I find things – because frankly, I don’ t know the process of logging bugs into GH so well. (unless anyone has other directions to me.)

Second about pushing thorugh the V2 to Canada on May 6. This turns out to be a problem. There is a large hub that closes May 6 at 10:00 am our time - so that is May 6 afternoon in Europe. Is it possible to wait until after 2:00 ish in Europe to do the downtime and V2 to Canada? Or if you need to do it in the am - can it be May 7 am?



I’m glad that not the only considering moving the deploy to the 6th. The closer we get to the date the more I don’t see it possible. So checking the calendar I see that I’ll be working just two days between today and the initial deploy date, which was the 29th: tomorrow and the 22th (I’ll spend 3 days off that week).

Then, as I mentioned above, Guida suggests moving the deploy to a Tuesday but other than that she thinks user won’t notice anything. We are just the ones feeling a bit nervous :sweat_smile:. I will check numbers tomorrow.

So that being said, similar to what @luisramos0 suggests I think it’s better to deploy the May 7th. It gives plenty of time to prepare releases and have the server provisioned with the latest changes as well as time to communicate the data to Katuma’s user base. We just need to commit to a date so we can clearly communicate it to them.

Lastly, while chatting with @Matt-Yorkley he suggested we better replace CAN with BE as the 2nd instance to deploy to because it is a server configured with ofn-install. That will give us much more confidence at this still early stage of the roll-out process. Besides, we don’t want to tie any server upgrades with v2’s roll-out as it would make it a lot longer.

It turns out, that in the last Matomo weekly report BE had a bit more traffic than CAN so the impact will be similar. Then, I’d leave CAN for a later stage. We will need to speak @Theodore if we decide so.

This is my 2cents. I’ll wrap my ahead around all this, as well as the steps to communicate it to our local community tomorrow. Let me know what you think.