[IMP] extend odoo cdn to use s3 storages
jjscarafia opened this issue · 12 comments
I believe it would be more-less easy to extend odoo CDN functionality so that s3 objects are used instead.
Any thoughts ?
@jjscarafia what do you mean? Can you elaborate a bit?
AFAIK the purpose of that setting is to replace matching URL w/ the CDN URL you provide.
If you set your S3 storage's public URL or the CDN URL (if you have a CDN) you'll bypass Odoo.
Hi @simahawk
I'm not the sepeciallist on this topic, but this it what I understand
c2c attachment_* modules solves on a very nice way storage challenges by using object storage (+ db storage) instead of file-system
On the other hand, object storage are also used for web apps as they can be served directly to the end user from the most suitable location.
So, if somehow we take advantage of odoo CDN mechanism and, instead using a CDN we tell odoo to give the 3 public URL, for all this frontend content (mainly images) we would serve them directly to the end-user from the s3 storage and avoid processing them in odoo.
I see some benefit but not sure the cost is paid. Because actually it may be hard/ugly to achieve (we should know which attachments needs to be public so that not everything is published on the s3 storage). Maybe it's just easier and better to use a CDN (integrated as keycdn) or on front (as cloudflare)
Just an idea to share and learn
I believe this module is doing something similar.
Instead of letting assets go thought the odoo pipeline (to forward them), it would make a lot of sense to answer with a signed-URL to access assets directly on the CDN, thus offloading Odoo and profiting from CDN goodies like the edge delivery.
Note that if correctly done, you bucket remains private.
@jjscarafia to have complete isolation it's probably better to use storage_backend* from OCA/storage (which at some point I'd like to integrate here and remove all the low level storage mgmt).
The con is that when you use storage_file and storage_image images are not stored as ir.attachment, hence if you use Odoo's std website you'll have to adapt few things and you won't probably be able to use the editor w/out hacks.
The pro is that you have total isolation.
@theoo regarding storing customer documents and serve the through CDN I'm not sure where the real benefit is, assuming - of course - that you don't have to serve gazillion of documents at the same time for hundreds of users.
@jjscarafia last but not least: this sounds like a good subject for an OCA sprint 😉
@simahawk well, the ecommerce is delivering document using the same principles, and the load can quickly grow.
Anyways, Odoo website is just a toy, but delivering assets through a CDN could help improve the dramatic performances when it comes to a real ecommerce use-case.
Yeah, you are right... a toy 😄
But then, what is not working ATM if you use the modules here? AFAIS - not tested tho - if you use attachment_s3 + CDN configuration pointing to your S3-plugged CDN you should get the work done.
What am I missing?
Any ideas on how this of odoo v16 will affect this object storage approach?
There is a recommendation to delegate access for static content by adding "alias /path/to/odoo/data-dir/filestore" on nginx.
But we're not having any filestore!
Without going deeper, my hunch is that we could take benefit of that odoo change. If we need a change in odoo core for better inheritance may be better now than after the freeze?
@jjscarafia Not sure that is a great idea to publish the filestore on the web. The filestore contains quotes, invoices, bills and other confidential documents.
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.