Hi Jerico, Internal db storage for job binaries was added at the start of EDP as an alternative for sites that do not have swift running. Since then, we've also added integration with manila so that job binaries can be stored in manila shares.
You are correct, storing lots of binaries in the sahara db could make the database grow very large. Swift or manila should be used for production, internal storage is a good option for development/test. There is currently no way to disable internal storage. We can took a look at adding such an option -- in fact we have talked informally about the possibility of deprecating internal db storage since swift and manila are both mature at this point. We should discuss that at the upcoming summit. Best, Trevor On Thu, 2016-03-17 at 10:27 +1100, Jerico Revote wrote: > Hello, > > > When deploying Sahara, Sahara docos suggests to > increase max_allowed_packet to 256MB, > for internal database storing of job binaries. > There could be hundreds of job binaries to be uploaded/created into > Sahara, > which would then cause the database to grow as well. > Does anyone using Sahara encountered database sizing issues using > internal db storage? > > > It looks like swift is the more logical place for storing job > binaries > (in our case we have a global swift cluster), and this is also > available to the user. > Is there a way to only enable the swift way for storing job binaries? > > Thanks, > > > Jerico > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev