search

OCA / OpenUpgrade

Open source upgrade path for Odoo/OpenERP
https://oca.github.io/OpenUpgrade/
GNU Affero General Public License v3.0
716 stars 689 forks source link

Migration to version 14.0 #2190

Open MiquelRForgeFlow opened 4 years ago

MiquelRForgeFlow commented 4 years ago

(del) means that the module has been removed in this version (add) means that the module has been added in this version > means that it has been identified that the module has been renamed to the name below < means that it has been identified that the module has been rename from the name below -> means that the module has been merged in the module below <- means that the module is the target where the module below has been merged

flotho commented 3 years ago

Hi,

I really would like to help on this. As I'm a little aware of using the scripts already done but could you please lead me on a "simple module" so that I can learn properly how to help here.

Regards

pedrobaeza commented 3 years ago

@flotho I'm afraid there's still some initial tasks to do before having a "simple module" to build migration scripts:

flotho commented 3 years ago

Let me know when I could start. I'm used to work on project / contract and website repos. so maybe it could help to identify what part I should handle for help

pedrobaeza commented 3 years ago

OK. This is now on hold, as we are doing the 13.0 migration scripts right now.

legalsylvain commented 3 years ago
  • Include OpenUpgrade modifications in core 14.0.
  • Migrate openupgrade_records module.

I began this work. Not a lot of time, but it could be ok in a couple of weeks. please ping me if other guys are on that task, to avoid duplicated work.

thanks !

pedrobaeza commented 3 years ago

@legalsylvain we want to apply a PoC where we detach the need of having whole Odoo code in OpenUpgrade, which forces us to maintain a big repository, do manual upstream updates, etc. It will use migration paths. There are several challenges, but it's worth to try. My colleague @Yajo will investigate it, but at least not in a month.

legalsylvain commented 3 years ago

we want to apply a PoC where we detach the need of having whole Odoo code in OpenUpgrade

@pedrobaeza ;-) awsome, I'm currently exactly working on such design.

@Yajo : let me know when you want to work on that point.

kind regards.

legalsylvain commented 3 years ago

It will use migration paths.

I remember that in last odoo Experience, they are talking about that point (the possiblity to add extra migration path), but I don't remember exactly how, and don't find any up to date documentation on the doc part of odoo.com. Any insight is welcome regarding that point. (for the time being, I'm working on adding changes in odoo Core. (for exemple, do not raise error when odoo.tools.view_validation.valid_view() is called))

pedrobaeza commented 3 years ago

See https://github.com/odoo/odoo/pull/32650

legalsylvain commented 3 years ago

thanks ! I was rgreping migration without success, but the new name is upgrades-paths.

flotho commented 3 years ago

amazing, it will be much more simple ...

habnk commented 3 years ago

Hi team, I using scripts openupgrade_scripts. I setup in config file _upgrade_path = /my_folder/OpenUpgrade/openupgradescripts/scripts/ and run. I don't see any error in logs. Where I can see migrated database? folder or database ?

pedrobaeza commented 3 years ago

There's still no migration scripts, only architecture, so you can't expect soon any migration possibility.

habnk commented 3 years ago

There's still no migration scripts, only architecture, so you can't expect soon any migration possibility.

oh, thank for comment

flotho commented 3 years ago

Hi,

As I'm totally fan of this module and already migrated v8 - v10 to v12 installation, I really would like to help on proposing migrated modules here on this new architecture that seems really Yet, I'm struggling to understand the start point of the process. AFAICS, the analysis_work.txt seems to be the starting point to all the migration and I would like to know if there is a tool to generate differences, Thanks for pointing me appropriate resources.

yajo commented 3 years ago

AFAICS, the analysis_work.txt seems to be the starting point to all the migration and I would like to know if there is a tool to generate differences,

Yes, there is, although you don't usually need it, because the work was already done.

Just go to https://github.com/OCA/OpenUpgrade/tree/14.0/openupgrade_scripts/scripts and start developing the scripts you want to contribute.

Also, the openupgrade_analysis_work.txt is created the 1st time manually by the 1st contributor of a module, by copying openupgrade_analysis.txt with that new name and manually annotating what is being done.

pedrobaeza commented 3 years ago

Made the switch to 14.0 as default branch for representing that this branch starts to be operational for the simple modules, and now the wheel is started!

flotho commented 3 years ago

is this post https://github.com/OCA/OpenUpgrade/issues/2190#issue-560365286 up to date or does the folder https://github.com/OCA/OpenUpgrade/tree/14.0/openupgrade_scripts/scripts represents the up to date WIP ?

sorry if the question looks weird but in the second case maybe updating the post to reference the forlder could be a good idea. Regards

pedrobaeza commented 3 years ago

It's this post. The folder contains all the modules analysis, having or not migration scripts.

flotho commented 3 years ago

Thanks @pedrobaeza , Just to be sure, as I can see for account_debit_note , the post indicates that the module has no upgrade script and it's confirmed here : https://github.com/OCA/OpenUpgrade/tree/14.0/openupgrade_scripts/scripts/account_debit_note/14.0.1.0 As the analysis seem very easy, does the account_debit_note need an upgrade script ? If not, what is the process to tag it as migrated in the first post ? Regards

MiquelRForgeFlow commented 3 years ago

@flotho we migrate modules in an orderly hierarchical way. The account_debit_note module depends on account, which it's still in WIP.

pedrobaeza commented 3 years ago

The analysis file only denotes changes in the model layout. Only after having all dependencies already "migrated", and studying if there's something to transform, we can say about that module if it's "Nothing to do", or if there's something and develop the migration scripts.

Example of change that doesn't have a reflect in the model layout, but required to develop scripts: on v10, you had multiple fragmented quants for each tuple of product, location, serial, etc. On v11, all are together, so we added on OpenUpgrade v11 a "deduplication" tool.

flotho commented 3 years ago

Hi @MiquelRForgeFlow @pedrobaeza ,

Thanks for great explanation to both of you. Another newbie question, which tool do you recommend for getting the module hierarchy (instead of experience and knowledge), I really would like to help on this and I want to be sure that I can concentrate on an appropriate module. Regards

pedrobaeza commented 3 years ago

Maybe https://pypi.org/project/manifestoo/. What I do is to see in the manifest if the depends modules are done. Simply that.

flotho commented 3 years ago

@pedrobaeza thanks for the manifestoo module, awesome. Regarding to the analysis, does this module https://github.com/OCA/server-tools/tree/14.0/upgrade_analysis still appropriate to start the analysis? Regards

pedrobaeza commented 3 years ago

Yes, but for Odoo modules, it's already done and put the analysis file on each folder.

flotho commented 3 years ago

ok, so my understanding of the process seems good, and the job is already done regarding this part. Another question regarding this kind of call : https://github.com/OCA/OpenUpgrade/pull/2783/files#diff-ed954c326a9e4e00f6d3c81953dd36b8af133608ca7825c826f83865b3fdec26R9 What is the purpose of the noupdate_changes.xml file? the name let me suppose that we have to put there definitions of xmlids that mustn't be updated during the process, but I'm not sure at all and don't find any documentation regarding this. Am I correct ?

pedrobaeza commented 3 years ago

That's also done by the analysis, and include the changes in XMLs corresponding to noupdate records, that are not going to be automatically updated in the process. You decide when developing the script if it needs to be loaded or not, or if there are some parts to comment for not being updated.

flotho commented 3 years ago

That's also done by the analysis, and include the changes in XMLs corresponding to noupdate records,

Is the "Analysis" an automated process or is it a manual process done by developers ?

pedrobaeza commented 3 years ago

Manual.

flotho commented 3 years ago

ok, Is there any lessons/tutorial I can found somewhere (outside the documentation) to have a more precise idea of the process? I would like to do it properly and I'm Ok to pay a one day course to be thought the good way. Maybe, that could be a good thing to add this kind of courses on OCA website. seniors like you and @legalsylvain would be able to share your knowledge in a more consistent way than this thread. Regards

pedrobaeza commented 3 years ago

I don't know any, and I don't do this process regularly. It's something that @StefanRijnhart and @MiquelRForgeFlow are always in charge, but I insist: it's already done. You don't have to repeat it, and it's not needed for the development of the migration scripts.

StefanRijnhart commented 3 years ago

That's also done by the analysis, and include the changes in XMLs corresponding to noupdate records,

Is the "Analysis" an automated process or is it a manual process done by developers ?

For the record, the noupdate_changes.xml file is generated automatically, but its loading must be added to a migration script manually by a developer. You should also weed out (comment out) any entries that seem unwise to overwrite. In the case of translatable columns that need to be overwritten, any existing translations need to be removed in the pre-migration script so that the new translations are loaded by Odoo.

pedrobaeza commented 3 years ago

Such generic question is not easy to be answered. Please focus it a bit more.

rb3606 commented 3 years ago

@pedrobaeza sorry for misunderstanding. I want to contribute for migration. I now undestood new structure for 14 migration. So i can start with any easy (small) module to migrate to 14.

legalsylvain commented 3 years ago

@rb3606 : you have to work module per module.

Work 1 : review existing 14 PR : https://github.com/OCA/OpenUpgrade/pulls?q=is%3Aopen+is%3Apr+milestone%3A14.0

Work 2 : work on new modules :

I recommand to begin to review and test existing PR.

kind regards.

rb3606 commented 3 years ago

Thanks @legalsylvain let me check with PR then. Do i have to Test PR with my local environment right ? and Review code ?

legalsylvain commented 3 years ago

Thanks @legalsylvain let me check with PR then. Do i have to Test PR with my local environment right ? and Review code ?

They are usually two kind of test :

you can : do it with a demo database or do it with a copy of a production database

In the end, report your review in the PR, mentionning which kind of review you did.

abdelrazekbadr commented 2 years ago

is there is video explain the steps? or there are simple steps to begin? If I want to upgrade from version 10 to version 14, Do I have to upgrade from one version to another sequentially 10,11,...14, or from 10 to 14 direct?

zurawsm3 commented 2 years ago

_web_settingsdashboard module was already deleted. It was moved to _basesetup module in version 13 Can You delete line about _web_settingsdashboard?

pedrobaeza commented 2 years ago

No, it should be kept and that's why it's put as (del). It's marked when the task is done to merge it or handle it with whatever it has to be done. I'm now marking it as merged in base_setup.

pedrobaeza commented 2 years ago

I'm seeing that it's not included in any script, so it's still pending.

matmicro commented 1 year ago

Is the coverage OK to use migration to v14 on a production DB ?

MiquelRForgeFlow commented 1 year ago

Just check your installed modules, and then compare to see if any module is missing. Also, in your migration tests, check flows to see if anything is wrong or missing until you are convinced everything is fine, and then you can proceed to migrate your production DB.