Open Stack

If an object write is sent to a hand off location, is that object deleted
from that hand off location once the primary write location is written to?
In my testing, I forced a new object write to hand off locations. Once I
brought the primary locations back online, the object is then written to
all primary locations however the object still resides in the handoff
location.

Please advise.

Thanks!


On Tue, Sep 9, 2014 at 12:41 PM, Brent Troge <brenttroge2016 at gmail.com>
wrote:

> Thanks John.. I truly appreciate your clear and concise answers.
>
>
>
>
>
> On Tue, Sep 9, 2014 at 12:09 PM, John Dickinson <me at not.mn> wrote:
>
>> Well listings is slightly different than being able to read the data if
>> you already know the object name.
>>
>> Assuming no failures in the system, the container listings will be up to
>> date before the end-user gets a 2xx response. That is, create a new object,
>> then immediately do a listing, and you'll see the object in that listing.
>>
>> However, we can pretty safely assume that there will be failures at some
>> point (especially if it's a larger cluster). In that case, the end-user
>> will still get a 2xx response because the data was durably flushed to disk,
>> but the container listing update may fall back to an asynchronous update.
>> In that case, you may or may not get the object in a container listing
>> until container replication has completed. But you'll still be able to read
>> the object directly if you know the name.
>>
>> --John
>>
>>
>> On Sep 9, 2014, at 9:15 AM, Brent Troge <brenttroge2016 at gmail.com> wrote:
>>
>> > Thanks..  My understanding is that an object will not be listed within
>> a container until it completes replication throughout the cluster. Thats
>> what I meant by 'listing'
>> >
>> > But you corrected that mis-understanding.  Such that, with respect to
>> my 3 write requirement, an object will be available  in each region once I
>> receive a 200 upon file ingest.
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Sep 9, 2014 at 10:02 AM, John Dickinson <me at not.mn> wrote:
>> > I'm not sure what the question is.
>> >
>> > If you are looking to have a successful response after it's written
>> twice in a cluster with 4 replicas, no. Swift's quorum calculation is
>> (replicas DIV 2 + 1). This means that for 4 replicas, you have a quorum
>> size of 3. What I would suggest you look in to is the write_affinity
>> setting so that you can do a full-quorum (at least) write to the local
>> region and then asynchronously replicate to the other region. See
>> http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters
>> and
>> https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/
>> .
>> >
>> > If you are looking to ensure that there is at least one replica in each
>> region, then yes. The quorum size of three (see above) will ensure that,
>> without any write_affinity settings, you'll have at least one replica in
>> each region and two in another before the client gets a 2xx success
>> response code to the PUT request.
>> >
>> > --John
>> >
>> >
>> >
>> > On Sep 9, 2014, at 6:59 AM, Brent Troge <brenttroge2016 at gmail.com>
>> wrote:
>> >
>> > >
>> > >
>> > > If I configure Swift to use 4 replicas across two regions(two
>> replicas per region), is it possible to only list a newly ingested object
>> if it has written at least twice? The goal is to only list a new object
>> only if it has a presence in each region.
>> > >
>> > > west coast
>> > > region 1 - zone 1
>> > > region 1 - zone 2
>> > >
>> > > east coast
>> > > region 2  - zone 1( 3?)
>> > > region 2 -  zone 2( 4?)
>> > >
>> > > Thanks!
>> > >
>> > >
>> > > _______________________________________________
>> > > Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> > > Post to     : openstack at lists.openstack.org
>> > > Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140917/659e3bf9/attachment.html>