Ansible playbook to setup openupgrade infra

[kwoot]

Hi,

So it took me two weeks and now I have some Ansible playbooks and Linux shell scripts to configure a (Ubuntu) server to run OpenUpgrade stuff.

I just used a script to download a database and filestore from another server, and run the migration script.
No, it is not polished yet, but it seems to work and could use some feedback from people who actually know what they are doing (with regard to OpenUpgrade).
Of course I will also document my stuff.

Would anybody be interested if I created a PR for this, in ,say, an 'Ansible" subdirectory?

Looking forward to any and all responses.
Jeroen Baten

[legalsylvain]

Hi. I'm interested to see that work. Regarding the PR, I'm not sure to know where to do it. (subdirectory, new branches, etc...)
could you provide the link to the current code ?

thanks !

[rvalyi]

just a remark: if you do such a script it's important you consider the possibility to add extra OCA modules (or possibly even from different origins) in the add-ons path for each version. Indeed, for real life projects, some OCA or custom modules might trigger important migration scripts when passing through the intermediary versions of the migration and you will usually be able to tweak them (possibly to contribute them back).

That might be achieved through the requirements.txt file but also with tools such as acsone/git-aggregator...

Other factors to consider for the design:

• it's quite likey one will want to tweak his migration PostgreSQL server, like filesync=off (never for production)
• when you the migration iterations loosing 2h to load a real life production database might be a hassle, createdb -T previous_database is often used.
• copying several Gb of filestore between a version and another can be a hassle too, ideally you can just move it to the next upgrade step.

Finally, the OCA could never really agree one production deployment tools so far because there are so many flavors and trade off to consider (like: should it be easy? minimalist? Docker based or not? should it be optimized for development? should it be optimized for onsite or for the cloud? should it be optimized for CI or multi-tenancy? compatible with Kubernetes etc...)
But migration is not production deployment so I think the chances of success of such a script for OpenUpgrade is quite real. Good luck.

[pedrobaeza]

First of all, thanks for proposing this.

I don't think this should be part of the OpenUpgrade repository, as there are a lot of ways to run the migrations, and they can't be maintain at the same time of the evolution of OpenUpgrade (example: v16 framework is done, but the Ansible script not being adapted), having frictions handling this.

I would opt for putting a link in the OpenUpgrade documentation to all these deployment tools (we can include Doodba as well).

[kwoot]

Hello,

I like to thank @rvalyi and @pedrobaeza for bringing up some valuable and important questions.
Allow me to tell you how I look at this.

(Disclaimer. I am not an Odoo developer, just a simple Odoo CE user with Linux skills)

A CEO of a successful company once told me: "whatever you do, never stall a decision. A bad decision is always, always, preferable to making no decision at all.".

So, yes, there are many, many alternatives to automating OpenUpgrade. But leaving this decision hanging out there does the project IMHO a disservice. I am not saying the direction I have chosen is the best one. Far from it. But "it works for me (TM)". :-)
If someone thinks another direction is better than "show me the code(TM)" and I will happily port this stuff if I can.

The current version I uploaded (https://github.com/kwoot/automating-openupgrade) does not (yet) handle extra OCA modules (or from others). But it is possible to use the scripts and tweak them as you like.

And it does away with the first boring part of setting everything up in a consistent way. Especially when you need to upgrade from Odoo8 al the way up to Odoo15.

Of course I could just let the code stay at my repo, but then only a few people will probably find it. But I think it would be much better if it were somehow merged with this repo., say, under a subdirectory like "/contrib/ansible". Then maybe somebody can actually use this :-).

I would love to see some global OCA database or web service or other solution (maybe it already exists?) that stores module info and also handles renaming and merging of modules between versions, but that is probably for another day.

"Life is too short to spent it on upgrading stuff."

So, please tell me your thoughts on this!

Regards, Jeroen

[pedrobaeza]

I don't get you. We are not blocking anything. Just saying (at least me) that this shouldn't be part of the main repo, but we support this and to include the reference in the README. We can open also another repo inside OCA that is OpenUpgrade-Ansible or similar for handling it.

[kwoot]

Hi,
I am absolutely not thinking you are blocking anything. I also do not think my work is the only solution.
I am just looking for how to move forward in a way that benefits the OCA/Odoo users the most.
Really, whatever you guys decide on I will follow.
Regards, Jeroen

[pedrobaeza]

OK, thanks for your comprehension. I would bet for including the instructions inside OpenUpgrade, and point for now to your repository, and then let other OCA actors to give their opinion and eventually add the extra repository.

[kwoot]

Okay, now I need some help:

So, I have the easy stuff running, except for the extra installed addons part. For instance, suppose I find a warning in the migration that 'account_financial_report' is currently missing. This makes sense as it is not yet available in the migration toolchain.
As a human I can find it at https://github.com/OCA/account-financial-reporting/tree/13.0/account_financial_report but is there some digital way to locate this url from the name of the missing addon? This path is in the database in a text field 'description' along with lots of other human readable info. Is there some way to query the OCA server about this, other than web crawling and making a mess trying to do it that way?

Regards, Jeroen

[pedrobaeza]

I don't think that's feasible, as the module may be any other non from OCA. The script responsibility IMO is to provide a way to indicate a custom modules addons path and follow it on the server. You should prepare such addons in your side.

[kwoot]

I was afraid you would say that :-). Thanks for your reply.

[kwoot]

Hi.
Just like to mention that my 'step-3-try2fix-missing-odooX-addons.sh' script seems to work.
(Now testing it with my own production database. Keeping fingers crossed...)
This makes me very happy.
Took a couple of days of work, and you are probably one of the few who would understand what I was trying to achieve :-)
Greets, Jeroen

[pedrobaeza]

Great, congratulations!

[kwoot]

It took some hacking, but I seem to have succeeded in migrating a production database from 12 to 13.
Next step is making a script to copy a database (owned by user odoo13) to a copy owned by user odoo14 and run the migration from 13 to 14.
Still, the current 13 database still needs the green light from the accountant.

[kwoot]

At the moment I was able to successfully migrate 12 to 13.
13 to 14 seems to work but some addons are no longer available and I do not know yet how to handle this.

[kwoot]

Okay. Declaring it a 1.0. Renamed addons can be handled.
Vanished addons because merged with other addon is not yet implemented.