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

[bitnami/odoo] Ability to extend python packages without custom image build #25687

Open
tbscode opened this issue May 12, 2024 · 3 comments
Open
Assignees
Labels

Comments

@tbscode
Copy link

tbscode commented May 12, 2024

Name and Version

bitnami/odoo

What is the problem this feature will solve?

There is no good way to add extra add-ons that require additional python packages.
Add-ons in /bitnami/odoo/addons can persist and it can be utilized to install custom add-ons without modifying the base image.

And I can install python requirement to the running container using source /opt/bitnami/odoo/venv/bin/activate && pip3 install -r /requirements.txt

But the helm chart utilizes the venv at /opt/bitnami/odoo/venv/ this is not part of any volume claim, therefore re-sets on every container start-up.

What is the feature you are proposing to solve the problem?

A good-way to use the odoo helm chart with custom modules that require additional python packages.

I could Imagine having a separate virtual environment inside the odoo data volume claim that is linked to the /opt/bitnami/odoo/venv/ e.g.: /bitnami/odoo/venv that users can install extra pip packages in.

What alternatives have you considered?

Installing them every time at start-up using the initContainer.

Please correct me if there already is another way to achieve this? 🙏🏻

@github-actions github-actions bot added the triage Triage is needed label May 12, 2024
@tbscode tbscode changed the title Ability to extend python packages without custom image build [bitnami/odoo] Ability to extend python packages without custom image build May 12, 2024
@javsalgar javsalgar added the odoo label May 13, 2024
@javsalgar
Copy link
Contributor

Hi!

Thank you so much for the feedback! I agree that the UX could be improved with, for example, allowing via values.yaml to introduce a set of python packages and have the chart render the init container that installs the plugin. I have my concerns on persisting the full packages section of the virtual environment as it could potentially break security upgrades. However, auto-generating the pip instal init container could be a good first step. Thoughts?

@tbscode
Copy link
Author

tbscode commented May 17, 2024

I like the idea, sounds like it would be a valid solution.

Personally not entirely sure how such a setup would look-like, do you do something similar in other charts.

@javsalgar
Copy link
Contributor

We use init containers in other charts, but we did not cover this use case. Could you try first creating an init container that covers the use case? Then, using that as a base, we could add improve the chart.

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

No branches or pull requests

2 participants