Open Stack

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/20140909/ff386c3c/attachment.html>