Change Details

Assuming there exist an object storage as described in T3054, there needs to be an object storage backend to store / retrieve objects. The name is **winery** (using the "winery namespace" agreed on on the mailing list last week). The proposed patch is what I think represents the [API dispatcher](https://wiki.softwareheritage.org/images/4/4a/Ceph-objstorage-sw-architecture.svg) which is a replacement of the [object storage](https://docs.softwareheritage.org/devel/architecture/overview.html#software-architecture-overview) at the bottom of the global architecture. {F4600269}

Assuming there exist an object storage as described in T3054, there needs to be an object storage backend to store / retrieve objects. The name is **winery** (using the "winery namespace" agreed on on the mailing list last week). The implementation is a replacement of the [object storage](https://docs.softwareheritage.org/devel/architecture/overview.html#software-architecture-overview) at the bottom of the global architecture. The backend runs in a *sgi app. At boot time it: * Gets an exclusive lock on a Shard in the Write Storage (creating a new one or resuming an existing one) * Gets a connection to the Write Storage and the global index * Registers for throttling purposes (probably a table in the database) * Serves both reads and writes from and to the Read Storage and the Write Storage When the Shard it is responsible for is full: * It stops accepting requests * Writes the Shard to the Read Storage * Shutdown Spawning the *sgi app or controlling the number of workers is not in the scope of this implementation. {F4600269}

Assuming there exist an object storage as described in T3054, there needs to be an object storage backend to store / retrieve objects. The name is **winery** (using the "winery namespace" agreed on on the mailing list last week). The proposed patchimplementation is what I thinka representslacement of the [API dispatcherobject storage](https://wikidocs.softwareheritage.org/images/4/4a/Ceph-objstorage-sw-architecture.svg) which is a replacement of the [object storage](https://docs.softwareheritage.org/devel/architecture/overview.html#software-architecture-overview) at the bottom of the global architecturedevel/architecture/overview.html#software-architecture-overview) at the bottom of the global architecture. The backend runs in a *sgi app. At boot time it: * Gets an exclusive lock on a Shard in the Write Storage (creating a new one or resuming an existing one) * Gets a connection to the Write Storage and the global index * Registers for throttling purposes (probably a table in the database) * Serves both reads and writes from and to the Read Storage and the Write Storage When the Shard it is responsible for is full: * It stops accepting requests * Writes the Shard to the Read Storage * Shutdown Spawning the *sgi app or controlling the number of workers is not in the scope of this implementation. {F4600269}