Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Migration to version 14.0 #2190

Open
MiquelRForgeFlow opened this issue Feb 5, 2020 · 44 comments
Open

Migration to version 14.0 #2190

MiquelRForgeFlow opened this issue Feb 5, 2020 · 44 comments
Labels
help wanted work in progress
Milestone
14.0

Comments

@MiquelRForgeFlow
Copy link
Contributor

MiquelRForgeFlow commented Feb 5, 2020 •
edited by pedrobaeza

(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
@MiquelRForgeFlow MiquelRForgeFlow added this to the 14.0 milestone Feb 5, 2020
@flotho
Copy link
Member

flotho commented Oct 10, 2020

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
Copy link
Member

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

  • Include OpenUpgrade modifications in core 14.0.
  • Migrate openupgrade_records module.
  • Perform analysis.
  • Develop base migration scripts.
  • Develop migration scripts of any possible dependency of such simple module.

@flotho
Copy link
Member

flotho commented Nov 1, 2020

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
Copy link
Member

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

@legalsylvain
Copy link
Contributor

  • 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
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Contributor

legalsylvain commented Nov 2, 2020 •
edited

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
Copy link
Member

See odoo/odoo#32650

@legalsylvain
Copy link
Contributor

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

@legalsylvain legalsylvain mentioned this issue Nov 3, 2020
Closed
6 tasks
@flotho
Copy link
Member

flotho commented Nov 3, 2020

amazing, it will be much more simple ...

@legalsylvain legalsylvain pinned this issue Nov 3, 2020
@legalsylvain legalsylvain mentioned this issue Dec 1, 2020
Merged
12 tasks
@habnk
Copy link

habnk commented Mar 22, 2021

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

@pedrobaeza
Copy link
Member

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

@habnk
Copy link

habnk commented Mar 22, 2021

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

oh, thank for comment

@flotho
Copy link
Member

flotho commented Apr 25, 2021

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.

@tafaRU tafaRU mentioned this issue Apr 27, 2021
Merged
@yajo
Copy link
Member

yajo commented Apr 29, 2021

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
Copy link
Member

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
Copy link
Member

flotho commented Jun 7, 2021

is this post #2190 (comment) 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
Copy link
Member

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

@flotho
Copy link
Member

flotho commented Jun 15, 2021

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
Copy link
Contributor Author

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

@pedrobaeza
Copy link
Member

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
Copy link
Member

flotho commented Jun 15, 2021

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
Copy link
Member

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
Copy link
Member

flotho commented Jun 24, 2021

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
Copy link
Member

Manual.

@flotho
Copy link
Member

flotho commented Jun 24, 2021

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
Copy link
Member

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
Copy link
Member

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.

@OCA OCA deleted a comment from Maxinvests1 Jul 22, 2021
@pedrobaeza pedrobaeza mentioned this issue Aug 6, 2021
Closed
@pedrobaeza
Copy link
Member

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

@rb3606
Copy link

rb3606 commented Aug 12, 2021

@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
Copy link
Contributor

@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
Copy link

rb3606 commented Aug 12, 2021

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

@legalsylvain
Copy link
Contributor

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 :

  • code review. just read the code analyze the analysis file, and check if all is correct
  • test review. On openupgrade project, you have to
    -> checkout the 14.0 branch you want to test
    -> install the module in the version 13
    -> make an upgrade to 14.0
    -> check if all is ok. (that is quite large...) but well, check if data are ok. In accounting scope, check if the entries are in the same state, etc... check specially datas that has been manipulated by migration script. (new field / changes in selection fields / etc...)

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.

@pjrobertson pjrobertson mentioned this issue Sep 23, 2021
Closed
@abdelrazekbadr

This comment has been minimized.

Sign in to view
@OCA OCA deleted a comment from Yasaie Oct 25, 2021
@OCA OCA deleted a comment from Yasaie Oct 25, 2021
@pedrobaeza pedrobaeza changed the title Migrations scripts for v14 Migration scripts for v14 Nov 15, 2021
This was referenced Jun 15, 2022
Closed
Closed
@legalsylvain legalsylvain changed the title Migration scripts for v14 Migration to version 14.0 Jun 20, 2022
@legalsylvain legalsylvain changed the title Migration to version 14.0 Migration to version 14.0 Jun 20, 2022
@zurawsm3
Copy link

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

@pedrobaeza
Copy link
Member

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
Copy link
Member

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

This was referenced Dec 19, 2022
Closed
Merged
@matmicro
Copy link

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

@MiquelRForgeFlow
Copy link
Contributor Author

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.

@legalsylvain legalsylvain unpinned this issue Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted work in progress
Projects
None yet
Milestone
14.0
Development

No branches or pull requests