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.

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

click-odoo-update: add option to filter modules to be updated #66

Closed
gustavovalverde opened this issue Mar 3, 2020 · 6 comments
Closed
Labels
question Further information is requested

Comments

@gustavovalverde
Copy link

A common scenario, mostly in multi-tenant environments, is to update a specific set of modules (or a single one) instead of all the modules that has been changed since the last update. Sometimes you don't even want to upgrade everything.

It could be a parameter like --modules / -m

@rousseldenis
Copy link
Member

@gustavovalverde Usually, that command has to be called 'per environment'. Could you explain a little more the use case you have?

@gustavovalverde
Copy link
Author

@rousseldenis for example, I have a kubernetes cluster, each version <11, 12, 13> has their own containers. I commonly use a script like this one #39 (comment) to upgrade all the databases from a single version, but sometimes I don't want (nor can wait) a full upgrade.

@rousseldenis
Copy link
Member

Usually, if a set of modules has changed, it is safe to update them, no?

As the update process should be agnostic (and generic).

If you want to bypass this, why not using the classic -u?

@gustavovalverde
Copy link
Author

gustavovalverde commented Mar 3, 2020

If you want to bypass this, why not using the classic -u?

Actually, that's what I'm doing:
for db in <db_list>; do odoo --stop-after-init --no-http --log-level=warn -u <modules> -d $db; done

This would be just a way to keep the same script for both behaviors.

@sbidoul sbidoul added the question Further information is requested label Mar 7, 2020
@sbidoul
Copy link
Member

sbidoul commented Mar 25, 2020

@gustavovalverde would #69 help for your use case?

@gustavovalverde
Copy link
Author

Yes, that would work, in a common scenario it makes more sense to actually "filter-out" problematic modules, instead of doing the inverse.

Closing this in favor of that approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants