Re: [openstack-dev] [swift][swift3][s3] Keep containers unique among a cluster

2018-05-14 Thread Pete Zaitcev
On Thu, 10 May 2018 20:07:03 +0800 Yuxin Wang wrote: > I'm working on a swift project. Our customer cares about S3 compatibility > very much. I tested our swift cluster with ceph/s3-tests and analyzed the > failed cases. It turns out that lots of the failed cases

Re: [openstack-dev] swift3 Plugin Development

2017-06-09 Thread Pete Zaitcev
On Fri, 9 Jun 2017 10:37:15 +0530 Niels de Vos wrote: > > > we are looking for S3 plugin with ACLS so that we can integrate gluster > > > with that. > > > > Did you look into porting Ceph RGW on top of Gluster? > > This is one of the longer term options that we have under

Re: [openstack-dev] Swift3 Plugin Development

2017-06-08 Thread Pete Zaitcev
On Thu, 8 Jun 2017 17:06:02 +0530 Venkata R Edara wrote: > we are looking for S3 plugin with ACLS so that we can integrate gluster > with that. Did you look into porting Ceph RGW on top of Gluster? -- P

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-10 Thread Pete Zaitcev
On Wed, 9 Nov 2016 11:14:32 + (GMT) Chris Dent wrote: > The conversations about additional languages in this community have > been one our most alarmingly regressive and patronizing. They seem > to be bred out of fear rather than hope and out of lack of faith in >

Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-10 Thread Pete Zaitcev
On Mon, 07 Nov 2016 15:53:51 -0800 Joshua Harlow wrote: > Standards though exist for a reason (and ini files are pretty common > across languages and such); though of course oslo.config has some very > tight integration with openstack, the underlying ini concept it >

Re: [openstack-dev] [swift][keystone] Using JSON as future ACL format

2016-06-07 Thread Pete Zaitcev
On Mon, 6 Jun 2016 13:05:46 -0700 "Thai Q Tran" wrote: > My intention is to spark discussion around this topic with the goal of > moving the Swift community toward accepting the JSON format. If would be productive if you came up with a specific proposal how to retrofit JSON

Re: [openstack-dev] [tc] supporting Go

2016-05-13 Thread Pete Zaitcev
On Fri, 13 May 2016 10:14:02 +0200 Dmitry Tantsur wrote: > [...] If familiarity for Python > developers is an argument here, mastering Cython or making OpenStack run > on PyPy must be much easier for a random Python developer out there to > seriously bump the performance.

Re: [openstack-dev] [tc] supporting Go

2016-05-11 Thread Pete Zaitcev
On Mon, 9 May 2016 14:17:40 -0500 Edward Leafe wrote: > Whenever I hear claims that Python is “too slow for X”, I wonder > what’s so special about X that makes it so much more demanding than, > say, serving up YouTube. In case of Swift, the biggest issue was the scheduler. As

Re: [openstack-dev] [tc] supporting Go

2016-05-09 Thread Pete Zaitcev
On Mon, 9 May 2016 09:06:02 -0400 Rayson Ho wrote: > Since the Go toolchain is pretty self-contained, most people just follow > the official instructions to get it installed... by a one-step: > > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz I'm pretty certain the

Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

2016-05-05 Thread Pete Zaitcev
On Wed, 4 May 2016 21:52:49 + "Fox, Kevin M" wrote: > Swift is in a strange place where the api is implemented in a way to > favor one particular vendor backend implementation. Sorry, but I disagree with the above assessement. There is no one particular vendor like that,

Re: [openstack-dev] [tc] supporting Go

2016-05-04 Thread Pete Zaitcev
On Tue, 3 May 2016 22:37:30 + "Fox, Kevin M" wrote: > RadosGW has been excluded from joining the OpenStack community in part > due to its use of c++. Sounds like sheer lunacy. Nothing like that ever happened, AFAIK. -- Pete

Re: [openstack-dev] [tc] supporting Go

2016-05-04 Thread Pete Zaitcev
On Tue, 3 May 2016 22:11:06 + "Fox, Kevin M" wrote: > If we let go in, and there are no pluggable middleware, where does > RadosGW and other Swift api compatible implementations then stand? They remain where they are now. > Should we bless c++ too? As I understand it,

Re: [openstack-dev] [tc] supporting Go

2016-05-03 Thread Pete Zaitcev
On Tue, 3 May 2016 12:16:24 -0400 Rayson Ho wrote: > I like Go! However, Go does not offer binary compatibility between point > releases. For those who install from source it may not be a big issue, but > for commercial distributions that pre-package & pre-compile

Re: [openstack-dev] swift missing X-Timestamp header commit review

2016-01-20 Thread Pete Zaitcev
On Wed, 20 Jan 2016 13:46:13 +0200 (EET) Mustafa ÇELİK (BİLGEM-BTE) wrote: > commit-1: This one is my patch for the bug. > https://review.openstack.org/#/c/268163/ > I need someone to review my commit-1. > Can somebody help me with code-review? Sure... I am

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

2016-01-19 Thread Pete Zaitcev
On Tue, 22 Dec 2015 08:56:08 -0800 Clint Byrum wrote: > You could create a unique swift container, upload things to that, and > then update a pointer in a well-known location to point at that container > for the new plan only after you've verified it is available. This is a >

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

2015-06-16 Thread Pete Zaitcev
On Thu, 11 Jun 2015 11:08:55 +0300 Duncan Thomas duncan.tho...@gmail.com wrote: There's only one cinder driver using it (nimble storage), and it seems to be using only very basic features. There are half a dozen suds forks on pipi, or there's pisimplesoap that the debian maintainer recommends.

Re: [openstack-dev] [swift] Allow hostname for nodes in Ring

2014-10-15 Thread Pete Zaitcev
On Fri, 10 Oct 2014 04:56:55 + Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: Today the following patch was abandoned and I contacted with the author, so I would like to take it over if nobody else is chafing to take it. Is it OK? https://review.openstack.org/#/c/80421/ If it

Re: [openstack-dev] [swift] Use FQDN in Ring files instead of ip

2014-08-05 Thread Pete Zaitcev
On Wed, 23 Jul 2014 08:54:30 -0700 John Dickinson m...@not.mn wrote: So basically, it's a question of do we add the feature, knowing that most people who use it will in fact be making their lives more difficult, or do we keep it out, knowing that we won't be serving those who actually require

Re: [openstack-dev] About Swift as an object storage gateway, like Cinder in block storage

2014-07-11 Thread Pete Zaitcev
On Mon, 7 Jul 2014 11:05:40 +0800 童燕群 tyan...@qq.com wrote: The workflow of this middle-ware working with swift may be like this pic: Since you're plugging this into a/c/o nodes, there's no difference between this and Pluggable Back-ends. Note that PBE is already implemented in case of object

Re: [openstack-dev] Swift: reason for using xfs on devices

2014-07-01 Thread Pete Zaitcev
On Wed, 2 Jul 2014 00:16:42 + Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: So I think if performance of swift is more important rather than scalability of it, it is a good idea to use ext4. The real problem is what happens when your drives corrupt the data. Both ext4 and XFS

Re: [openstack-dev] Moving swift3 to stackforge (was: Re: [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka)

2014-03-14 Thread Pete Zaitcev
On Fri, 14 Mar 2014 09:03:22 +0100 Chmouel Boudjnah chmo...@enovance.com wrote: fujita (the maint of swift3 in CC of this email) has commented that he's been working on it. I think we should've not kicked it out. Maybe just re-fold it back into Swift? -- Pete

[openstack-dev] Guru Meditation output seems useless

2014-03-03 Thread Pete Zaitcev
Dear Solly: I cobbled together a working prototype of Guru Meditation for Swift just to see how it worked. I did not use Oslo classes, but used the code from Dan's prototype and from your Nova review. Here's the Gerrit link: https://review.openstack.org/70513 Looking at the collected

Re: [openstack-dev] Glance v1 and v2

2014-02-18 Thread Pete Zaitcev
On Tue, 18 Feb 2014 10:57:03 +0100 Joe Hakim Rahme joe.hakim.ra...@enovance.com wrote: Again, I have just spent a couple of days playing with it on a devstack. I'm by no means a reference on the subject of the API v2. I hope this will help you get a better idea of where it stands today.

[openstack-dev] Glance v1 and v2

2014-02-14 Thread Pete Zaitcev
Hello: does anyone happen to know, or have a detailed write-up, on the differences between so-called Glance v1 and Glance v2? In particular do we still need Glance Registry in Havana, or do we not? The best answer so far was to run the registry anyway, just in case, which does not feel entirely

[openstack-dev] [Glance] delayed delete and user credentials

2014-02-06 Thread Pete Zaitcev
Hi, guys: I looked briefly at a bug/fix, which looks exceedingly strange to me: https://review.openstack.org/59689 As much as I can tell, the problem (lp:1238604) is that pending delete fails because by the time the delete actually occurs, Glance API does not have proper permissions to talk to

[openstack-dev] Swift account auditor duplicated code

2013-09-05 Thread Pete Zaitcev
Hi, Guys: Here's a weird piece of duplicated call to account_audit() in swift/account/auditor.py: for path, device, partition in all_locs: self.account_audit(path) if time.time() - reported = 3600: # once an hour self.logger.info(_('Since

Re: [openstack-dev] [Swift] question on Application class concurrency; paste.app_factory mechanism

2013-07-25 Thread Pete Zaitcev
On Wed, 24 Jul 2013 02:31:45 + Luse, Paul E paul.e.l...@intel.com wrote: I was thinking that each connection would get its own instance thus it would be sage to store connection-transient information there but I was surprised by my quick test. Yeah, you have it tracked in __call__,

Re: [openstack-dev] [Swift] erasure codes, digging deeper

2013-07-24 Thread Pete Zaitcev
On Thu, 18 Jul 2013 12:31:02 -0500 Chuck Thier cth...@gmail.com wrote: I'm with Chmouel though. It seems to me that EC policy should be chosen by the provider and not the client. For public storage clouds, I don't think you can make the assumption that all users/clients will understand the