Hi Andi, My perspective is that I'm working on an application that should work with arbitrary service providers using swift. Therefore, I'm interested in the minimal set of guarantees that I can always rely on, no matter how the service provider has configured his particular swift instance.
Best, Nikolaus On 01/20/2012 04:10 PM, andi abes wrote: > I'm finding this thread a bit confusing. You're comparing offered > SERVICES to Software. While some of the details of the software will > dictate what's possible, some are heavily dependent on how you deploy > the swift software, and what kind of deployment decisions you (or your > service provider) make. > > As an extreme example - if you deploy 1 container server in a highly > available fashion (hardware style), the you probably could get > consistent container listings in the different update followed by read > scenarios. Hosting huge swift installations with such a setup is not > realistic - but that doesn't say you can't do that. > > Similarly, swift offers quite a lot of flexibility in setting the > eventual consistency window sizes (replication frequency, rates and > such). So, while there are theoretical answers to missing replicas, the > likelihood of those occurring depends on your deployment and operational > practices employed. (e.g. how many replicas are made, how quickly are > failed nodes/drives fixed and their content replicated to their > replacement etc). > In the amazon case, much of this is captured in the 17 9's or the 3 9's > guarantees for the reduced redundancy class. > > If your approach is from an API perspective, then issues around # of > replicas (which is deployment parameter) are probably not relevant - if > you trust your provider. > > If your approach in this is from a Swift developer / deployer > perspective - then nvm. keep asking, cause it's much easier to read > email than python ;) > -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
