[openstack-dev] Sahara Job Binaries Storage

Jerico Revote jerico.revote at monash.edu
Thu May 26 06:14:10 UTC 2016


Hi Trevor,

Just revisiting this,
has there been any progress to deprecate sahara jobs -> internal db mechanism?
and/or the config option to disable internal db storage?
 
Regards,

Jerico



> On 18 Mar 2016, at 12:55 AM, Trevor McKay <tmckay at redhat.com> wrote:
> 
> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list