| *** shakayumi has joined #openstack-swift | 00:00 | |
| *** joeljwright has quit IRC | 00:01 | |
| *** shakamunyi has quit IRC | 00:05 | |
| *** shakayumi has quit IRC | 00:05 | |
| *** matsuhashi has joined #openstack-swift | 00:29 | |
| *** shri has quit IRC | 00:41 | |
| *** dmorita has joined #openstack-swift | 00:55 | |
| *** joeljwright has joined #openstack-swift | 00:58 | |
| *** gadb has joined #openstack-swift | 01:02 | |
| *** joeljwright has quit IRC | 01:02 | |
| *** saschpe has quit IRC | 01:27 | |
| *** saschpe has joined #openstack-swift | 01:32 | |
| *** nosnos has joined #openstack-swift | 01:36 | |
| *** nosnos has quit IRC | 01:44 | |
| *** nosnos has joined #openstack-swift | 01:44 | |
| *** sungju has joined #openstack-swift | 01:51 | |
| *** sungju has quit IRC | 01:53 | |
| *** joeljwright has joined #openstack-swift | 01:59 | |
| *** shakayumi has joined #openstack-swift | 02:00 | |
| *** annegentle has joined #openstack-swift | 02:00 | |
| *** joeljwright has quit IRC | 02:04 | |
| *** openstackgerrit has quit IRC | 02:04 | |
| *** openstackgerrit has joined #openstack-swift | 02:05 | |
| *** shakayumi has quit IRC | 02:14 | |
| *** tsg has quit IRC | 02:18 | |
| *** shakayumi has joined #openstack-swift | 02:31 | |
| *** ppai has joined #openstack-swift | 02:40 | |
| *** lnxnut has joined #openstack-swift | 02:44 | |
| *** byeager has joined #openstack-swift | 02:45 | |
| *** nosnos has quit IRC | 02:51 | |
| *** joeljwright has joined #openstack-swift | 03:00 | |
| *** praveenkumar has joined #openstack-swift | 03:03 | |
| *** joeljwright has quit IRC | 03:04 | |
| *** lnxnut has quit IRC | 03:09 | |
| *** byeager has quit IRC | 03:13 | |
| *** gyee has quit IRC | 03:25 | |
| *** matsuhashi has quit IRC | 03:27 | |
| openstackgerrit | Hugo Kou proposed a change to openstack/swift: Fix the hash_suffix was never called for a non-None hash value https://review.openstack.org/91729 | 03:31 |
|---|---|---|
| *** tzumainn has quit IRC | 03:37 | |
| *** joeljwright has joined #openstack-swift | 04:02 | |
| *** nosnos has joined #openstack-swift | 04:05 | |
| *** joeljwright has quit IRC | 04:06 | |
| clayg | gholt i still don't get it, I can shared between //realm1/cluster1 and //realm2/cluster5 just as easily as //realm1/cluster1 and //realm1/cluster2 - I don't understand the different in having clusters grouped in realms - what can two clusters in the same realm do that two clusters in different realms can't? (maybe I'm thinking about it wrong) | 04:24 |
| clayg | gholt: and thanks for getting back on the async! | 04:25 |
| clayg | redbo: do you have any thoughts on this -> https://bugs.launchpad.net/swift/+bug/1301728 | 04:25 |
| openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Add probe tests for Account Reaper https://review.openstack.org/91732 | 04:26 |
| *** chandan_kumar has joined #openstack-swift | 04:36 | |
| clayg | redbo: nm, I think I got it (you might still wanna sanity check me) | 04:43 |
| redbo | clayg: sort of. The problem is we can't just look at all the files all the time. I was hoping to tackle that problem when I replaced hashes.pkl with a database. Then finding tombstones to delete could just be a db query. But that hasn't panned out performance-wise. | 04:44 |
| redbo | it could maybe be made part of the auditor, since it's already doing the walking | 04:46 |
| redbo | People have tried to put in hashes.pkl expiration before, but that scares the crap out of me. If you ever fall behind on replication, you'll end up reindexing the whole machine in the next replication pass. And that'll likely take long enough that they'll all be expired again the next pass. | 04:50 |
| clayg | redbo: thanks, that's good insight | 04:55 |
| redbo | My plan was to put all of a partition's filenames in a database, with "chexor"-style hashes per suffix (or whatever number of hashes has the best tradeoff). So they're continuously updated rather than re-walking the filesystem. And then we have all the filenames in a db, so we could index and query for stuff like expired tombstones. | 04:59 |
| redbo | OKAY, I need to get to the gymnasium! | 05:00 |
| *** joeljwright has joined #openstack-swift | 05:02 | |
| *** matsuhashi has joined #openstack-swift | 05:03 | |
| *** shakayumi has quit IRC | 05:04 | |
| *** joeljwright has quit IRC | 05:07 | |
| gholt | clayg: Yes you can share across realms that are available, but they will use different realms keys when the clusters communicate. So the Rackspace realm key isn't known by the Rackspace/SwiftStack realm key. So SwiftStack couldn't just start syncing to any Rackspace cluster, it'd have to be in the right realm. Does that help? | 05:09 |
| gholt | And yes, you're right that the user could sync SwiftStack->Rackspace1->Rackspace2. But they'd be allowed to sync Rackspace1->Rackspace2 regardless. Just SwiftStack->Rackspace2 wouldn't be allowed. Presumably because of route costs. | 05:16 |
| gholt | But really it's so SwiftStack<->OtherCompany doesn't necessarily mean OtherCompany<->Rackspace, though obviously if one has an account on all three and there are two syncing connections (say SwiftStack<->Rackspace as well), the user can do whatever (say OtherCompany->SwiftStack->Rackspace and back). | 05:19 |
| *** nshaikh has joined #openstack-swift | 05:19 | |
| *** changbl has joined #openstack-swift | 05:21 | |
| openstackgerrit | Hugo Kou proposed a change to openstack/swift: Fix the syntax of stripping '.' for items in storage_domain list https://review.openstack.org/91737 | 05:30 |
| *** shakayumi has joined #openstack-swift | 05:30 | |
| *** shakayumi has quit IRC | 05:35 | |
| *** chandan_kumar has quit IRC | 05:47 | |
| *** zaitcev has quit IRC | 05:59 | |
| *** chandan_kumar has joined #openstack-swift | 06:01 | |
| *** joeljwright has joined #openstack-swift | 06:04 | |
| *** joeljwright has quit IRC | 06:08 | |
| *** psharma has joined #openstack-swift | 06:14 | |
| *** shakayumi has joined #openstack-swift | 06:31 | |
| *** bvandenh has joined #openstack-swift | 06:36 | |
| *** shakayumi has quit IRC | 06:36 | |
| *** chandan_kumar has quit IRC | 06:51 | |
| *** gadb has quit IRC | 06:55 | |
| *** openstackgerrit has quit IRC | 06:57 | |
| *** joeljwright has joined #openstack-swift | 07:05 | |
| *** chandan_kumar has joined #openstack-swift | 07:05 | |
| *** joeljwright has quit IRC | 07:09 | |
| *** madhuri has quit IRC | 07:10 | |
| *** waterkinfe has joined #openstack-swift | 07:10 | |
| *** acoles_away is now known as acoles | 07:13 | |
| *** shakayumi has joined #openstack-swift | 07:32 | |
| *** mmcardle has joined #openstack-swift | 07:32 | |
| *** shakayumi has quit IRC | 07:37 | |
| *** tanee has quit IRC | 08:01 | |
| *** waterkinfe has quit IRC | 08:02 | |
| *** joeljwright has joined #openstack-swift | 08:06 | |
| *** haomai___ has quit IRC | 08:10 | |
| *** joeljwright has quit IRC | 08:11 | |
| *** haomaiwang has joined #openstack-swift | 08:11 | |
| *** joeljwright has joined #openstack-swift | 08:12 | |
| *** piousbox_ has joined #openstack-swift | 08:20 | |
| *** acoles has quit IRC | 08:21 | |
| *** cheri has joined #openstack-swift | 08:22 | |
| *** Ju_ has joined #openstack-swift | 08:25 | |
| *** tanee has joined #openstack-swift | 08:29 | |
| *** acoles has joined #openstack-swift | 08:32 | |
| *** ChanServ sets mode: +v acoles | 08:32 | |
| *** Ju_ has quit IRC | 08:33 | |
| *** shakayumi has joined #openstack-swift | 08:33 | |
| *** torgomatic_ has joined #openstack-swift | 08:34 | |
| *** psharma has quit IRC | 08:34 | |
| *** saschpe has quit IRC | 08:34 | |
| *** wkelly has quit IRC | 08:34 | |
| *** creiht has quit IRC | 08:34 | |
| *** torgomatic has quit IRC | 08:34 | |
| *** torgomatic_ is now known as torgomatic | 08:34 | |
| *** piousbox has quit IRC | 08:34 | |
| *** Ju has quit IRC | 08:34 | |
| *** gholt has quit IRC | 08:34 | |
| *** ondergetekende has quit IRC | 08:34 | |
| *** creiht has joined #openstack-swift | 08:34 | |
| *** ChanServ sets mode: +v creiht | 08:34 | |
| *** cheri has quit IRC | 08:34 | |
| *** saschpe has joined #openstack-swift | 08:35 | |
| *** shakayumi has quit IRC | 08:37 | |
| *** dmorita has quit IRC | 08:38 | |
| *** chandan_kumar has quit IRC | 08:40 | |
| *** ondergetekende has joined #openstack-swift | 08:47 | |
| *** cheri has joined #openstack-swift | 08:51 | |
| *** tzumainn has joined #openstack-swift | 08:52 | |
| *** chandan_kumar has joined #openstack-swift | 08:53 | |
| *** psharma has joined #openstack-swift | 08:53 | |
| *** wkelly has joined #openstack-swift | 08:53 | |
| *** matsuhashi has quit IRC | 09:04 | |
| *** nshaikh has quit IRC | 09:04 | |
| *** matsuhashi has joined #openstack-swift | 09:05 | |
| *** cheri has quit IRC | 09:10 | |
| *** cheri has joined #openstack-swift | 09:23 | |
| *** Ju has joined #openstack-swift | 09:33 | |
| *** shakayumi has joined #openstack-swift | 09:33 | |
| *** shakayumi has quit IRC | 09:38 | |
| *** shakayumi has joined #openstack-swift | 10:34 | |
| *** matsuhashi has quit IRC | 10:35 | |
| *** matsuhashi has joined #openstack-swift | 10:37 | |
| *** shakayumi has quit IRC | 10:39 | |
| *** nshaikh has joined #openstack-swift | 10:45 | |
| *** Trixboxer has joined #openstack-swift | 11:02 | |
| *** ppai has quit IRC | 11:09 | |
| *** mmcardle has quit IRC | 11:11 | |
| *** mmcardle has joined #openstack-swift | 11:13 | |
| *** gholt has joined #openstack-swift | 11:16 | |
| *** ChanServ sets mode: +v gholt | 11:17 | |
| *** matsuhashi has quit IRC | 11:22 | |
| *** psharma has quit IRC | 11:29 | |
| *** shakayumi has joined #openstack-swift | 11:35 | |
| *** gholt has quit IRC | 11:35 | |
| *** nosnos has quit IRC | 11:37 | |
| *** shakayumi has quit IRC | 11:39 | |
| *** matsuhashi has joined #openstack-swift | 11:48 | |
| *** nosnos has joined #openstack-swift | 11:53 | |
| *** vr2 has joined #openstack-swift | 12:21 | |
| vr2 | is there a specific place to add a blueprint for a new ObjectController ? | 12:25 |
| *** shakamunyi has joined #openstack-swift | 12:36 | |
| *** nosnos has quit IRC | 12:39 | |
| *** shakamunyi has quit IRC | 12:41 | |
| *** mmcardle has quit IRC | 12:55 | |
| *** matsuhashi has quit IRC | 13:04 | |
| *** matsuhashi has joined #openstack-swift | 13:04 | |
| *** Midnightmyth has joined #openstack-swift | 13:05 | |
| *** mmcardle has joined #openstack-swift | 13:05 | |
| *** cheri has quit IRC | 13:05 | |
| *** matsuhas_ has joined #openstack-swift | 13:08 | |
| *** matsuhashi has quit IRC | 13:08 | |
| glange | https://blueprints.launchpad.net/swift <-- there ? | 13:16 |
| vr2 | yep thanks | 13:17 |
| *** matsuhas_ has quit IRC | 13:18 | |
| vr2 | portante are you there ? | 13:18 |
| portante | vr2: back | 13:26 |
| vr2 | hey | 13:30 |
| vr2 | portante: I'm about to create a blueprint for an integration of scality sproxyd as a backend | 13:30 |
| portante | cool, got code yet? | 13:31 |
| vr2 | portante: anything special to care about ? | 13:31 |
| vr2 | we have the code | 13:31 |
| portante | can you post it? | 13:31 |
| vr2 | it is an HTTP pass-through | 13:32 |
| vr2 | yes I can | 13:32 |
| portante | great | 13:32 |
| vr2 | please note it requires the use of a proprietary component, anyways the backend can be hacked to point to other http based object stores | 13:33 |
| vr2 | I mention it since I see it is the first proprietary project related to swift | 13:33 |
| vr2 | as I've seen | 13:33 |
| portante | perhaps you should consider making it general for HTTP based object stores | 13:34 |
| portante | ? | 13:34 |
| portante | but post the code so that we can consider it and offer feedback | 13:34 |
| vr2 | ok, where shall I put it ? | 13:34 |
| portante | can you do github? | 13:34 |
| portante | vr2: and are you planning on attending the openstack summit in Atlanta? | 13:35 |
| vr2 | yes I do | 13:35 |
| vr2 | portante: yes I will be there | 13:35 |
| vr2 | portante: so I do the blueprint + I post the source | 13:35 |
| vr2 | ? | 13:35 |
| portante | yes, thanks | 13:36 |
| vr2 | ok | 13:36 |
| portante | it is not likely that we'll take backends into the swift tree, though | 13:36 |
| portante | for example, the gluster-swift (now being renamed to swift-on-file) is an existing backend that is public, but not in the swift ree | 13:36 |
| portante | tree | 13:36 |
| *** shakamunyi has joined #openstack-swift | 13:37 | |
| portante | and I believe SwiftStack has a backend for the Seagate Kinetics drive that is not in the swift tree (though I don't know where that lives) | 13:37 |
| portante | there is a proposal for a CEPH backend against the swift ree, and but that is there to help get it going, but won't land there | 13:37 |
| vr2 | What do you prefer ? do we make a fork or do we make a branch on the repo ? | 13:41 |
| *** shakamunyi has quit IRC | 13:41 | |
| *** zhiyan_ is now known as zhiyan | 13:45 | |
| vr2 | portante: the GlusterOnFile is not registered as a swift blueprint | 13:45 |
| vr2 | portante: any reason for that ? | 13:45 |
| portante | yes, it was initially done from within the GlusterFS community with no interactions with the Swift community | 13:48 |
| portante | we at red hat then worked on the DiskFile backend work, which does have blueprints | 13:48 |
| portante | the only blueprints required are those for adding things to OpenStack itself, as I understand it, though notmyname is the authority on all that | 13:49 |
| portante | creiht and others know more of the history of OpenStack and the use of blueprints | 13:49 |
| *** lnxnut has joined #openstack-swift | 13:51 | |
| *** byeager has joined #openstack-swift | 13:52 | |
| *** shakamunyi has joined #openstack-swift | 13:52 | |
| vr2 | portante: OK so do you recommend us to create a swift blueprint or something else ? | 13:56 |
| *** krtaylor has quit IRC | 13:56 | |
| portante | I would post the code first, and see if there is something there that might warrant the blueprint | 13:56 |
| portante | but I would defer to notmyname's judgement | 13:56 |
| *** mrsnivvel has quit IRC | 13:59 | |
| *** openstackgerrit has joined #openstack-swift | 14:08 | |
| *** kevinc_ has joined #openstack-swift | 14:10 | |
| *** zhiyan is now known as zhiyan_ | 14:13 | |
| vr2 | portante: but you did not tell me about fork or branch ? | 14:14 |
| portante | I would suggest that you keep this as a separate repo, much like the gluster-swift repo | 14:16 |
| portante | if you there you have code that should land in the tree, then let's propose that as a patch and we can see it and discuss it via gerrit review | 14:17 |
| *** d0ugal has joined #openstack-swift | 14:21 | |
| *** fifieldt has quit IRC | 14:21 | |
| *** bill_az has joined #openstack-swift | 14:21 | |
| *** lpabon has joined #openstack-swift | 14:22 | |
| *** nshaikh has quit IRC | 14:23 | |
| *** Midnightmyth has quit IRC | 14:24 | |
| *** gholt has joined #openstack-swift | 14:25 | |
| *** ChanServ sets mode: +v gholt | 14:25 | |
| *** shakamunyi has quit IRC | 14:31 | |
| *** shakamunyi has joined #openstack-swift | 14:31 | |
| *** bill_az_ has joined #openstack-swift | 14:32 | |
| *** shakamunyi has quit IRC | 14:32 | |
| *** bill_az has quit IRC | 14:32 | |
| *** shakamunyi has joined #openstack-swift | 14:32 | |
| *** lpabon has quit IRC | 14:32 | |
| *** ams0 has joined #openstack-swift | 14:34 | |
| *** krtaylor has joined #openstack-swift | 14:37 | |
| *** kr4zy has joined #openstack-swift | 14:40 | |
| kr4zy | Hello, has anyone gotten chunked encoding to work when hosting Swift proxy service using Apache2 mod_wsgi? | 14:41 |
| *** kevinc_ has quit IRC | 14:41 | |
| *** kevinc_ has joined #openstack-swift | 14:44 | |
| vr2 | portante: if you want to have a look https://github.com/scality/ScalitySproxydSwift/commit/99d2e3baf9967a0e21c08084cacfd8ad55185077 | 14:45 |
| portante | great, thanks | 14:47 |
| vr2 | shall I post the link somewhere ? | 14:47 |
| portante | okay, so for large objects, this is going to be memory intensive | 14:49 |
| portante | it might be better to work on a new proxy ObjectController, see swift/proxy/controllers/ObjectController, which passes on the http request as it comes through rather than the store-and-forward in-memory method you have above | 14:51 |
| portante | but we don't have a facility for loading something like that | 14:51 |
| *** shakamunyi has quit IRC | 14:53 | |
| portante | yes | 14:54 |
| portante | yet | 14:54 |
| *** shakamunyi has joined #openstack-swift | 14:54 | |
| kr4zy | So has anyone gotten chunked encoding working when hosting the proxy service using Apache2 with mod_wsgi? Thanks. | 14:55 |
| portante | kr4zy: I don't know | 14:55 |
| kr4zy | Thanks protante. | 14:55 |
| *** shakamunyi has quit IRC | 14:56 | |
| portante | but others may have, so keep asking | 14:56 |
| *** shakamunyi has joined #openstack-swift | 14:56 | |
| *** kevinc_ has quit IRC | 14:57 | |
| *** shakayumi has joined #openstack-swift | 14:59 | |
| kr4zy | anyone here beside portante that has knowledge on getting chunked encoding working when hosting swift proxy service on Apache2 mod_wsgi? | 15:01 |
| *** shakamunyi has quit IRC | 15:01 | |
| *** shakayumi has quit IRC | 15:03 | |
| *** shakamunyi has joined #openstack-swift | 15:03 | |
| *** shakamunyi has quit IRC | 15:03 | |
| *** creiht has quit IRC | 15:06 | |
| *** ams0 has quit IRC | 15:10 | |
| *** corrigac has joined #openstack-swift | 15:11 | |
| vr2 | portante: initially I planned to use some kind of message passing between httplib and the diskfilewriter abstraction | 15:15 |
| vr2 | portante: but actually the pb is that httplib requires a file compatible object because it wants to consume it at its own pace, although we don't control the swift diskfilewriter which passes chunks also at its own pace | 15:16 |
| vr2 | I tried to use the rabbitmq from eventlet, but I had issue with greenthreads | 15:17 |
| *** shakamunyi has joined #openstack-swift | 15:18 | |
| portante | that is why I am thinking about a proxy-controller backend, because we already have the for the proxy server | 15:19 |
| vr2 | portante: good idea | 15:20 |
| *** creiht has joined #openstack-swift | 15:25 | |
| *** ChanServ sets mode: +v creiht | 15:25 | |
| creiht | .exit | 15:25 |
| creiht | heh | 15:25 |
| *** creiht has quit IRC | 15:25 | |
| *** creiht has joined #openstack-swift | 15:25 | |
| *** ChanServ sets mode: +v creiht | 15:25 | |
| vr2 | portante: for now, how does the proxy obj controller works when it contacts the obj server ? | 15:27 |
| portante | when the proxy server receives the initial header of a REST API request, it makes all the calculations to figure out which object/cont/acct servers to contact, and then constructs a potentially modified header of the original and starts a set of connections to the backend servers | 15:29 |
| portante | if the servers, in their 100-continue response, accept the request, then the proxy server pulls bits off the wire and sends them on to the open backend connections | 15:30 |
| portante | this sounds a lot like what you want to do | 15:30 |
| vr2 | yes but we were afraid not being compatible since there is a lot of http header interpretation in the proxy code | 15:31 |
| vr2 | e.g. x-delete-after, etc | 15:31 |
| portante | yes, which is why you'd want to be sure the abstractions in the proxy code exist so that API handling semantics are properly seperated from backend controller communication | 15:32 |
| vr2 | yes that's a good idea | 15:34 |
| *** ChanServ sets mode: +v torgomatic | 15:34 | |
| vr2 | do you think we could do that ? or do you plan to do that ? | 15:34 |
| portante | I had started that work a long time ago, but did not get very far | 15:35 |
| portante | brb | 15:35 |
| *** shakayumi has joined #openstack-swift | 15:37 | |
| *** shakamunyi has quit IRC | 15:38 | |
| portante | vr2: back | 15:40 |
| creiht | I really don't think that type of abstraction belongs in swift | 15:40 |
| vr2 | creiht: you mean it is up to us to submit it | 15:41 |
| creiht | vr2: who is us? | 15:42 |
| creiht | sorry I had to reset my irc stuff so I lost all the history | 15:42 |
| *** peluse_ has quit IRC | 15:43 | |
| vr2 | creiht: we write a swift object backend that talks to an HTTP proxy | 15:43 |
| vr2 | we started by implementing a FileSystem but we have to do a store-and-forward in memory | 15:43 |
| vr2 | portante thinks it is better to modify the proxy controller obj with a cleaner abstraction for managing that | 15:44 |
| creiht | vr2: ahh | 15:44 |
| *** JelleB is now known as a1|away | 15:44 | |
| creiht | I'm just expressing the opinion that swift needs to focus on being an object storage system | 15:45 |
| vr2 | note that a store-and-forward + SLO make a relatively small footprint | 15:45 |
| creiht | not an abstraction for other object storage systems | 15:45 |
| creiht | and it is just my opinion :) | 15:45 |
| creiht | sorry I'll go back to my corner and let yall continue :) | 15:46 |
| vr2 | creight: that's a commendable opinion | 15:46 |
| glange | creiht: but maybe this will allow ceph on our backend | 15:46 |
| vr2 | creiht: but like any other services in OpenStack that would be cool to have contributors and vendors | 15:46 |
| vr2 | e.g. Cinder | 15:46 |
| *** Midnightmyth has joined #openstack-swift | 15:47 | |
| vr2 | Cinder has support for a variety of block devices, not only LVM | 15:47 |
| vr2 | ideally swift shall do the same, no ? | 15:47 |
| creiht | vr2: right, but cinder was written specifically for that purpose | 15:47 |
| creiht | cinder isn't a block storage system | 15:47 |
| creiht | cinder is an abstraction that has a poor default implementation | 15:48 |
| creiht | swift was written from the beginning to be a good object storage system | 15:48 |
| portante | vr2: swift could do the same for storage systems, but to layer swift on another system that does the same thing just to get the api is not necessarily the best method | 15:48 |
| *** gyee has joined #openstack-swift | 15:48 | |
| creiht | if openstack wants an abstraction, my argument is that it should be something else that swift could plug into just like every other system | 15:48 |
| glange | the api is the most important part :/ | 15:48 |
| creiht | others may not share the same opinion | 15:49 |
| vr2 | yes, an object store system is "abstractable" so swift could be | 15:50 |
| creiht | my main concern is that if swift becomes the abstraction, then we focus more on the abstraction rather than swift itself | 15:50 |
| vr2 | yes but sysadmins want a common API, different vendors, to stimulate the offer | 15:51 |
| *** bvandenh has quit IRC | 15:51 | |
| creiht | vr2: if there is a case for that, then I'm fine, but my argument is that it shouldn't be swift | 15:52 |
| vr2 | okay I hear it | 15:52 |
| portante | creiht: if you look at the layering in the proxy server, it is almost there today | 15:52 |
| creiht | portante: I agree that it *could* be done | 15:52 |
| creiht | I'm just not certain that it is the right thing | 15:53 |
| portante | a few changes to break the proxy controllers into front and backend, and you get the Swift API fronting storage implementations | 15:53 |
| *** peluse has joined #openstack-swift | 15:54 | |
| creiht | swift *could* do a lot of things | 15:54 |
| creiht | but my questions is what *should* it do? | 15:54 |
| creiht | but I'm just one dev | 15:55 |
| creiht | with his own opinions | 15:55 |
| creiht | and I must be a bit grumpy today | 15:55 |
| *** peluse_ has joined #openstack-swift | 15:55 | |
| portante | I think it is a worth while discussion to have at summit | 15:55 |
| *** chandan_kumar has quit IRC | 15:55 | |
| redbo | is it an evil chuck day? | 15:55 |
| creiht | heh | 15:56 |
| creiht | portante: yeah I would agree | 15:56 |
| portante | get out that creeper killer | 15:56 |
| vr2 | creiht: what if another popular open-source object store wants to be there ? | 15:56 |
| *** bvandenh has joined #openstack-swift | 15:56 | |
| creiht | vr2: my opinion is, if there is to be an object storage abstraction, it should be a new project which swift could be a backend for | 15:57 |
| creiht | just like any other object storage system | 15:57 |
| vr2 | is there a particular session at openstack summit to discuss that ? | 15:58 |
| creiht | not that I know of | 15:58 |
| creiht | notmyname may have a different opinion | 15:58 |
| creiht | again, I'm just one person on the project | 15:59 |
| creiht | I don't dictate for the project :) | 15:59 |
| *** acoles is now known as acoles_away | 15:59 | |
| creiht | vr2: to be clear, nobody has proposed an abstraction system | 16:00 |
| creiht | outside of swift | 16:00 |
| *** mkollaro has joined #openstack-swift | 16:02 | |
| *** csd has joined #openstack-swift | 16:11 | |
| *** joeljwright has quit IRC | 16:14 | |
| *** mwstorer has joined #openstack-swift | 16:20 | |
| notmyname | good morning. /me reads buffer playback. oh my. | 16:21 |
| *** corrigac has quit IRC | 16:24 | |
| *** zaitcev has joined #openstack-swift | 16:24 | |
| *** ChanServ sets mode: +v zaitcev | 16:24 | |
| creiht | lol | 16:25 |
| notmyname | I'm writing up some bullet points of my thoughts | 16:25 |
| creiht | notmyname: yeah I imagine you and I don't agree in this area | 16:25 |
| notmyname | creiht: actually, I think we are very closely aligned (but perhaps not identical) | 16:26 |
| notmyname | * I very much think that swift is an object storage system and not a provisioner of storage systems. | 16:27 |
| notmyname | * while it's possible to use some different object server, I also think that isn't "Swift". | 16:27 |
| notmyname | * swift already supports vendor-specific implementations (gluster, zeroVM, kinetic), and it's good to encourage good abstractions so that those can be good. but swift upstream needs to focus on a very good implementation itself | 16:27 |
| notmyname | /end | 16:27 |
| notmyname | s/implementations/extensions/ | 16:28 |
| notmyname | creiht: portante: vr2: ^ | 16:29 |
| *** byeager has quit IRC | 16:30 | |
| notmyname | also, I very much think that the API and implementation aren't decoupled (eg we should never have an "api project" and a "backend project") | 16:30 |
| *** corrigac has joined #openstack-swift | 16:34 | |
| *** byeager has joined #openstack-swift | 16:35 | |
| *** mmcardle has quit IRC | 16:36 | |
| openstackgerrit | Christian Berendt proposed a change to openstack/python-swiftclient: fixed typos found by RETF rules https://review.openstack.org/91824 | 16:39 |
| *** vr2 has left #openstack-swift | 17:08 | |
| zaitcev | Do people want to get into AUTHORS file _that_ bad? | 17:12 |
| *** shri has joined #openstack-swift | 17:13 | |
| *** praveenkumar has quit IRC | 17:15 | |
| notmyname | which reminds me...I wonder if the pep8 version will be bumped | 17:19 |
| notmyname | 73 errors with new pep8, almost all are "continuation line under-indented for visual indent" | 17:21 |
| notmyname | in swift/ and test/ | 17:21 |
| portante | notmyname: thanks, sounds like a good discussion for summit | 17:22 |
| notmyname | portante: swift extensibility? | 17:22 |
| notmyname | portante: (just checking that you arent' wanting a session on pep8 and docstring typos) | 17:23 |
| portante | yes, and what that means in relation to the API | 17:23 |
| portante | yes! | 17:23 |
| portante | defininite! | 17:23 |
| portante | definitely! that would be the most attended of all! | 17:23 |
| portante | ;) | 17:23 |
| notmyname | did you see the ops rant on the openstack-operators mailing list this morning? | 17:24 |
| portante | no, let me go look | 17:24 |
| notmyname | http://lists.openstack.org/pipermail/openstack-operators/2014-May/004405.html | 17:25 |
| *** nwagner has joined #openstack-swift | 17:28 | |
| luisbg | notmyname, thanks for the recheck! | 17:29 |
| luisbg | I was about to request it and got dragged into some client work | 17:29 |
| portante | thanks for the link regarding the ops rant | 17:31 |
| *** corrigac has quit IRC | 17:32 | |
| *** mkollaro has quit IRC | 17:35 | |
| *** shakayumi has quit IRC | 17:52 | |
| *** byeager has quit IRC | 17:54 | |
| *** ams0 has joined #openstack-swift | 17:56 | |
| clayg | is problem building netifaces for py26 a thing now? | 17:58 |
| notmyname | clayg: ya, I was looking at that just a while ago (before the eng meeting) | 18:00 |
| notmyname | clayg: not sure, shich is why I threw a recheck no bug first | 18:00 |
| notmyname | clayg: pypi trove info for netifaces 0.10.1 still says py25 py26 py26 and py3 | 18:02 |
| *** byeager has joined #openstack-swift | 18:03 | |
| * clayg spins up lucid vm | 18:04 | |
| clayg | stupid netifaces, didn't onetime somebody write a pure python impl of whataremyips | 18:06 |
| zaitcev | notmyname: Not sure if that is much relevant to Swift. Surely we are engaged with uses through the devops style companies like eNovance and Swiftstack. | 18:06 |
| clayg | maybe Alex_Gaynor? | 18:06 |
| Alex_Gaynor | I wrote a pure python impl, it uses cffi though, so "pure python" gets some scare quotes | 18:07 |
| clayg | lol | 18:07 |
| zaitcev | I'm going to target Clay to approve https://review.openstack.org/85909 | 18:07 |
| *** joeljwright has joined #openstack-swift | 18:07 | |
| clayg | oh no! | 18:07 |
| zaitcev | I cannot break it up into any smaller pieces guys | 18:07 |
| clayg | zaitcev: but what if I don't like it? I can be sorta snobby - you may not want me to look at it | 18:08 |
| zaitcev | clayg: How is it worse than what's going on now?! | 18:08 |
| clayg | zaitcev: well idk, i'm looking | 18:08 |
| clayg | zaitcev: but having spent some time recently with DBBroker, and it's subclasses and their interaction with the base db_replicator i am pretty sure that area of the code could use a few more lines in the sand | 18:09 |
| notmyname | zaitcev: I think we do a decent job of listening for ops feedback. but we are tied to broader openstack issues too, so if there are tools, processes, or ideas to help improve thinking about "does this code actually work in production" when code is written, that's beneficial to everyone | 18:10 |
| *** joeljwright has quit IRC | 18:10 | |
| notmyname | zaitcev: also, while we do a decent job, I think we could do better. but a lot of that is around ongoing public QA | 18:10 |
| zaitcev | clayg: I'm operating under a proposition that what I'm doing will actually streamline the existing API. I keep seeing the same pattern where users of the broker have to construct a complex pattern from elementary ops. Result is, things that can be down under with conn.get(): are not done. Result - races. For no reason! | 18:11 |
| clayg | zaitcev: yeah i like it, ObjectController doesn't use hash_path - why should Account/ContainerController | 18:12 |
| clayg | zaitcev: let me run it through the paces | 18:12 |
| clayg | zaitcev: although it ends up looking mostly like a factory method for DBBroker | 18:13 |
| zaitcev | clayg: if you want to see how it's supposed to develop in full contex, I keep updated this: https://review.openstack.org/47713 (although I gave up on having it approved whole). | 18:13 |
| clayg | also... what no common.DBBackend!? :P | 18:13 |
| zaitcev | hmm.... Luis also said he'd prefer to have that | 18:14 |
| zaitcev | fully returning ErrorNotImplemented | 18:14 |
| clayg | zaitcev: i was kidding, for better or worse I think the common base isn't helping us a ton - it's become more of a MixIn | 18:15 |
| *** corrigac has joined #openstack-swift | 18:16 | |
| clayg | but OTOH I do feel that DiskFile could have a decent shot a real base class - so it seems possible we could pull of something reasonable for the db's too | 18:16 |
| notmyname | luisbg: looks like your patch (and several others) were not allows because of netifaces 0.10.X on centos. the -infra team is pushing through a requirements change to exclude those versions, so maybe we'll get stuff landed later today | 18:18 |
| *** ams0 has quit IRC | 18:18 | |
| *** corrigac_ has joined #openstack-swift | 18:19 | |
| clayg | only on centos? what version? | 18:19 |
| notmyname | clayg: 0.10.0 is reported to pass on precise and fail on centos | 18:20 |
| zaitcev | clayg: I'm a little irritated by the double inheritance chain AccountBackend->AccountBroker->DatabaseBroker, because when reading the code one must look up in several places to see where the method is defined. | 18:20 |
| clayg | zaitcev: YES THAT! | 18:20 |
| zaitcev | clayg: I see you were somewhat facetous too, but surely what I created is not ideal. | 18:21 |
| *** corrigac has quit IRC | 18:21 | |
| clayg | so i looked up "face"tous - and google figured out what you mean - but I love the definition: | 18:22 |
| clayg | "treating serious issues with deliberately inappropriate humor" | 18:22 |
| clayg | ^ that's like me whole shtick | 18:22 |
| kr4zy | has anyone here gotten chunked encoding to work when using Apache2 with mod_wsgi to host the proxy-service? | 18:27 |
| notmyname | kr4zy: I haven't looked in to that. TBH, I don't know of any production Swift clusters that run behind apache actually (although some who may run it that way in a lab) | 18:30 |
| kr4zy | notmyname: so how does other people host a production quality swift cluster with SSL encryption? | 18:31 |
| notmyname | kr4zy: use your load balancer or another tool to terminate the ssl. eg an haproxy (or commercial) load balancer, or eg stud running on each proxy redirecting over localhost to the proxy process | 18:32 |
| kr4zy | notmyname: we have security requirements to have ssl all the through from client to the proxy server. Is it possible to have ssl encryption using the native proxy service? | 18:33 |
| zaitcev | clayg: how about this idea: do not overlay methods. I identified 2 for account: get_info and put_container. So, name them AccountBackend.info and AccountBackend.put_container_2 (okay that's kernel namind style, but...). This way at least your IDE will click-through to right place for you. | 18:33 |
| *** d0ugal has quit IRC | 18:34 | |
| *** d0ugal has joined #openstack-swift | 18:34 | |
| *** d0ugal has quit IRC | 18:34 | |
| *** d0ugal has joined #openstack-swift | 18:34 | |
| *** nwagner has quit IRC | 18:34 | |
| notmyname | kr4zy: not with eventlet. does talking ssl to the proxy server box (and redirecting it locally) not meet the requirements? | 18:34 |
| *** corrigac_ has quit IRC | 18:34 | |
| *** csd has quit IRC | 18:35 | |
| notmyname | kr4zy: eg one thing we do at swiftstack is to send ssl to every proxy server box and use a local process to terminate the ssl and send the plain stream to another process on the same box (ie the swift proxy server process). that way, the client connection uses ssl all the way to the proxy server box | 18:36 |
| kr4zy | notmyname: I see what you mean. | 18:36 |
| kr4zy | notmyname: thanks | 18:36 |
| luisbg | notmyname, cool! thanks for checking | 18:45 |
| notmyname | portante: in-process tests, I get 2 failures in testFileSizeLimit. swift.conf and test.conf both exist, and they have the same max_file_size (2GiB) | 18:53 |
| *** csd has joined #openstack-swift | 18:53 | |
| luisbg | notmyname, I see you changed the filter for All patches with no core reviews in the wiki page of Priority Reviews | 18:54 |
| luisbg | notmyname, do the filters need more updating? | 18:54 |
| notmyname | luisbg: yes, I think so. but I haven't looked at it since I saw the -infra dashboards queries they are trying to make global. but that probably won't happen for quite some time, so "we" (ie you?) should still update them | 18:55 |
| luisbg | notmyname, sure. Going to look at it right now :) | 18:56 |
| notmyname | luisbg: thanks :-) | 18:56 |
| luisbg | sorry, got pulled out to some client work the other day | 18:56 |
| clayg | zaitcev: no, i don't think that sound better? | 18:57 |
| zaitcev | clayg: so... Just leave as it is now? | 18:57 |
| luisbg | is there a public list somewhere of the core reviewers? | 19:03 |
| glange | core reviewers are shrouded in mystery | 19:04 |
| luisbg | torgomatic | 19:05 |
| luisbg | notmyname | 19:05 |
| luisbg | gholt | 19:05 |
| luisbg | peter-a-portante | 19:05 |
| luisbg | darrellb | 19:05 |
| luisbg | chmouel | 19:05 |
| luisbg | clay-gerrard | 19:05 |
| luisbg | zaitcev | 19:05 |
| luisbg | david-goetz | 19:05 |
| luisbg | cthier | 19:05 |
| luisbg | redbo | 19:05 |
| luisbg | greglange | 19:05 |
| luisbg | that is the list I have, but want to confirm | 19:05 |
| portante | notmyname: so is this an SAIO? | 19:05 |
| portante | and are you running the in-process tests on that SAIO? | 19:05 |
| glange | http://russellbryant.net/openstack-stats/swift-reviewers-90.txt | 19:06 |
| glange | luisbg: that hast a list of people with two **'s that are core reviewers | 19:06 |
| luisbg | glange, that is what I am looking for, yes | 19:06 |
| zaitcev | that doesn't preclude a stealth core member who never reviewes anything | 19:06 |
| glange | I don't know if that is comprehenisve though, it looks good to me | 19:06 |
| *** lpabon has joined #openstack-swift | 19:06 | |
| glange | luisbg: did we win a prize? :) | 19:07 |
| glange | best core reviewers for an opensource project in 2013, maybe? | 19:08 |
| zaitcev | There has to be a reporting structure of some kind, which allows Russell to populate parameters for his scripts. | 19:08 |
| luisbg | glange, more code to review! :P wonderful prize isn't it? | 19:08 |
| glange | -1 | 19:08 |
| glange | ^^ all day | 19:08 |
| glange | :) | 19:08 |
| luisbg | zaitcev, it is for filtering out the "if a patch has or not a core review". I know this doesn't sound ideal. looking for an alternative way | 19:09 |
| zaitcev | Looks like Sam was on a tear recently. 4x reviews over mine. | 19:10 |
| luisbg | notmyname, https://wiki.openstack.org/w/index.php?title=Swift/PriorityReviews&diff=prev&oldid=50982 | 19:15 |
| luisbg | zaitcev, you can catch up! :P | 19:16 |
| *** ams0 has joined #openstack-swift | 19:17 | |
| kr4zy | notmyname: I have notice communication problem with the native proxy service with keystone on wsgi ssl enabled. Have you guys notice the same problem? | 19:23 |
| *** bill_az_ has quit IRC | 19:23 | |
| *** tzumainn has quit IRC | 19:26 | |
| clayg | if anyone has anymore info to add on the netifaces thing -> https://bitbucket.org/al45tair/netifaces/issue/1/gcc-fails-while-installing-0100-0101 | 19:27 |
| *** csd has quit IRC | 19:27 | |
| luisbg | clayg, reading | 19:29 |
| luisbg | clayg, I am getting the same http://logs.openstack.org/03/90103/3/check/gate-swift-python26/994dac3/console.html | 19:30 |
| luisbg | clayg, output looks exactly the same | 19:30 |
| clayg | luisbg: yeah that seems to be the issue, going back to netifaces==0.8 seems to work | 19:31 |
| *** praveenkumar has joined #openstack-swift | 19:31 | |
| luisbg | clayg, hopefully this is fixed in Jenkins soon :) | 19:31 |
| clayg | hopefull author can address upstream | 19:31 |
| clayg | well - i'm not exactly sure why we have to wait on Jenkins? if just update our requiresments.txt will Jenkins still install something different? | 19:32 |
| luisbg | clayg, notmyname said the -infra teams is looking into removing those versions (or reverting to 0.8) | 19:34 |
| luisbg | clayg, oooh wait, I just realized you said something different | 19:34 |
| luisbg | clayg, netifaces>=0.5 in swift/requirements | 19:36 |
| luisbg | it only sets a minimum but not a maximum | 19:36 |
| luisbg | clayg, you could have netifaces>=0.5,<=0.8 | 19:36 |
| openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Pin netifaces while upstream is messed up https://review.openstack.org/91879 | 19:37 |
| luisbg | clayg, trivial patch if you want me to do it and give it a try | 19:37 |
| *** nwagner has joined #openstack-swift | 19:37 | |
| luisbg | clayg, aaahhh there you go :) | 19:37 |
| clayg | well, we'll see what jenkins does iwht on the py2.6 job | 19:37 |
| clayg | but yeah if that works... | 19:38 |
| luisbg | clayg, we just need to get it through to Jenkins | 19:38 |
| clayg | i don't think there is an 0.9? maybe <=0.8 would have made more sense... I just don't want 0.10 :P | 19:38 |
| luisbg | no harm on trying | 19:38 |
| luisbg | clayg, potato/potatoe if there is no 0.9 | 19:39 |
| luisbg | just thought there would be, since there was a 0.5 | 19:39 |
| clayg | i'm really mostly interested to see what Jenkins does with it - then we can decide what we want to do... | 19:42 |
| *** ams0 has quit IRC | 19:45 | |
| *** byeager has quit IRC | 19:45 | |
| *** ams0 has joined #openstack-swift | 19:45 | |
| *** byeager has joined #openstack-swift | 19:45 | |
| luisbg | clayg, I agree | 19:46 |
| *** ams0 has quit IRC | 19:49 | |
| notmyname | leews: can you see https://review.openstack.org/#/admin/groups/24,members | 19:57 |
| notmyname | portante: yes, on SAIO | 19:57 |
| *** ams0 has joined #openstack-swift | 19:58 | |
| notmyname | clayg: you'll have to wait for https://review.openstack.org/#/c/91815/ to land and then match that syntax exactly | 19:58 |
| clayg | notmyname: that's stupid | 20:03 |
| clayg | what if homeboy releases 0.10.2? | 20:03 |
| *** Trixboxer has quit IRC | 20:03 | |
| clayg | notmyname: will jenkins not run the check now that you stuck a -2 on it? | 20:04 |
| portante | notmyname: so do you see a message that says you are running in-process tests? | 20:04 |
| clayg | notmyname: cause I honestly would like to see what jenkins will acctully do rather than what we expect it to do? | 20:04 |
| luisbg | clayg, filtering out specific releases is weird indeed | 20:06 |
| luisbg | and not maintainable, it assumes the problem will be fixed in 0.10.2 | 20:06 |
| *** ams0 has quit IRC | 20:07 | |
| notmyname | clayg: luisbg: I agree. the way global requirements works though is that projects can't update requirements unless it matches the global requirements file | 20:08 |
| luisbg | notmyname, interesting! didn't knew | 20:09 |
| luisbg | notmyname, it makes sense from a release engineering point of view, keeping consistency across all openstack modules | 20:09 |
| notmyname | clayg: luisbg: leave that comment on the other review ASAP otherwise that's what will be official | 20:10 |
| notmyname | I'll pull my -2 off so it can do it's thing andyou can see the jenkins failure | 20:10 |
| clayg | w/e | 20:10 |
| *** praveenkumar has quit IRC | 20:13 | |
| luisbg | notmyname, want me to change my review back to +1? | 20:29 |
| notmyname | luisbg: on clay's patch? doesn't matter, I think | 20:29 |
| luisbg | notmyname, so which one are you talking about? "leave that comment on the other review ASAP" | 20:30 |
| *** nwagner has quit IRC | 20:30 | |
| clayg | luisbg: he ment this one -> https://review.openstack.org/#/c/91815/ | 20:31 |
| luisbg | clayg, oooh right. and you commented it. great :) | 20:32 |
| clayg | no one cares though | 20:32 |
| clayg | i mean *I* care but only as much as "this is broken let's fix it" - i'm less caring of the "oh no no - we have to wait on other people and the politic to get them to do the right thing because *process*!" | 20:34 |
| * clayg briefly wonders if he can get his picture somehwere under http://en.wiktionary.org/wiki/facetious | 20:35 | |
| luisbg | clayg, I commented because I think you meant <=0.8, and not >=0.8 | 20:35 |
| clayg | w/e | 20:35 |
| luisbg | clayg, I do share the same feeling of "let's get this out of the way and not waste time on it" | 20:36 |
| clayg | zaitcev: so I feel like there should be some testing accompanying https://review.openstack.org/#/c/85909/2 - but everyhting I try in test_backend feels rather contrived | 20:37 |
| zaitcev | clayg: I thought I verified that I run normal tests, so functionally at least it all works. | 20:38 |
| zaitcev | clayg: Lemme see if I am making us to take a dent in coverage with this. The all-inclusive patch also has mem_backend.py thing, which is separately excercised and I recall the coverage of the whole thing was acceptable. | 20:39 |
| clayg | zaitcev: i'm poking at it - i'll let you know if i have any inspiration... | 20:40 |
| *** lpabon has quit IRC | 20:46 | |
| *** csd has joined #openstack-swift | 20:50 | |
| *** byeager has quit IRC | 20:53 | |
| zaitcev | clayg: I re-run coverages and it looks like exactly same numbers. I speculate it's because all these backend and broker things are common and excercised by a whole bunch of unit tests, so new code gets automatically excertised. | 20:54 |
| zaitcev | like | 20:54 |
| zaitcev | old: swift.account.backend 163 7 71 8 94% 48, 210, 216, 218, 313, 330, 385 | 20:55 |
| zaitcev | new: swift.account.backend 171 7 71 8 94% 49, 211, 217, 219, 314, 331, 386 | 20:55 |
| *** csd_ has joined #openstack-swift | 20:55 | |
| *** csd has quit IRC | 20:56 | |
| clayg | well i wasn't specifically thinking about coverage per say | 20:57 |
| *** kr4zy has quit IRC | 20:59 | |
| zaitcev | What is it, then? Whenever I add code, it gets tested. In this case I'm skating using the existing tests, but the end result is to test anyway. You'll it better once new methods get introduced into the A/CBackend classes. | 21:01 |
| *** tzumainn has joined #openstack-swift | 21:04 | |
| *** bach has joined #openstack-swift | 21:16 | |
| *** bach has quit IRC | 21:21 | |
| *** byeager has joined #openstack-swift | 21:24 | |
| *** nwagner has joined #openstack-swift | 21:24 | |
| *** byeager_ has joined #openstack-swift | 21:24 | |
| clayg | zaitcev: what was the later patch that moved some of the create/initialize stuff into the backend? | 21:26 |
| clayg | zaitcev: i don't see it listed as a depends on 85909 | 21:27 |
| zaitcev | clayg: everything is included into https://review.openstack.org/47713 | 21:27 |
| *** byeager has quit IRC | 21:28 | |
| *** csd_ is now known as csd | 21:29 | |
| *** annegentle has quit IRC | 21:29 | |
| *** tzumainn has quit IRC | 21:31 | |
| clayg | zaitcev: k, lemme think | 21:32 |
| *** d0ugal has quit IRC | 21:33 | |
| luisbg | argjjjs, not being able to edit a review/comment after hitting submit | 21:44 |
| openstackgerrit | Pete Zaitcev proposed a change to openstack/swift: Pluggable Back-ends for account and container servers https://review.openstack.org/47713 | 21:53 |
| zaitcev | luisbg: just like e-mail huh | 21:54 |
| -openstackstatus- NOTICE: Zuul is being restarted with some dependency upgrades and configuration changes; ETA 2215 | 21:59 | |
| *** bach has joined #openstack-swift | 22:04 | |
| *** bach has quit IRC | 22:09 | |
| *** bach has joined #openstack-swift | 22:10 | |
| *** bach has quit IRC | 22:12 | |
| zaitcev | awww on the storage_directory() question, I rememeber that there was a super important reason to change it and I forgot what it was | 22:17 |
| clayg | zaitcev: lol | 22:24 |
| clayg | well if it was *super* important i'm sure it'll come back to you :P | 22:24 |
| *** lnxnut has quit IRC | 22:33 | |
| *** byeager_ has quit IRC | 22:40 | |
| clayg | zaitcev: not feeling super great about 85909, I acctually think having AccountBackend be a subclass of AccountBroker is a mis-step | 22:44 |
| zaitcev | clayg: I could refer to it by reference, just not sure it solves anything. Like... have a common class Backend, in it self.broker. As far as documentation goes, it seems like a good place for docstrings. As far as code goes, I dunno. Maybe I'm getting used to this layout. | 22:47 |
| clayg | zaitcev: I think having the class that the account controller uses delegate would acctually solve quite a bit - in that you can just stick a method on common/db.py and then refernce it in account/server.py - you have to think about it. | 22:48 |
| zaitcev | clayg: "delegate" is too big a word for me, I do not understand. | 22:48 |
| clayg | but I just stubbed that out and it looks silly (even in 47713, the list_objects_iter method that's totally a passthrough to super is pretty obviously an anti-pattern)? | 22:49 |
| clayg | well... like def get_info(): return self.broker.get_info() | 22:49 |
| clayg | anyway, doesn't matter - solves one problem - creates more - I don't think it's the right way either | 22:49 |
| zaitcev | hmm | 22:50 |
| clayg | I think the A/CBroker (or more specifically their base DatabaseBroker) just has too much guts to really serve the purpose of describing the interface the that the controller's need | 22:52 |
| clayg | but if that interface is just a subclass of them it really serves... well I care for it | 22:52 |
| zaitcev | Not sure if it helps, but I keep in mind that we have other implementations. In this case it's mem_backend.py (for both a & c). Those inevitably copy. However from the API perspective the a & c share nothing, it's just convenience for our main implementation that they are so similar. | 22:52 |
| zaitcev | So Luis wanted class Broker so it could contain common parts and common abstract methods | 22:53 |
| clayg | yeah that's got us before... I think that MemDiskfile still does the wrong thing for expired objects | 22:54 |
| zaitcev | I suppose I can claim that if API is right, we can re-implement A/CBroker any way we like "later", but I feel that if we punt it now, we'll never get back to it. | 22:55 |
| clayg | i agree, it the goal isn't to have the best abstraction that we can then it's not much of a goal - people can already subclass A/CController and return a thing that works like the existing implemetnation - e.g. https://github.com/gluster/gluster-swift/blob/master/gluster/swift/common/DiskDir.py :P | 22:57 |
| clayg | I'd like to see (and may have to try and play with) an A/CBroker class that only implements (and documents) the interfaces needed for the REST layer and then subclass those to form an A/CBackend class that can be constructed from a path on disk and answers higher order questions like get_replication_info and their ilk | 23:01 |
| *** byeager has joined #openstack-swift | 23:01 | |
| clayg | ... might be a disaster, but I'm pretty sure my concious won't let me get behind the interface being used by the controller's as a subclass of the full implementation used by the consistency engine - seems backwards | 23:03 |
| zaitcev | well, this is not the road I was taking with this split. In 47713 and 85909, the primary split is that Backend is what's needed for ReST layer (server.py) and Broker is needed for anything that has knowledge of disk layout, such as auditor. | 23:03 |
| zaitcev | maybe we should fight to death in a cage | 23:04 |
| clayg | more like fight to the death in gerrit? | 23:04 |
| zaitcev | it just so happens that in existing Swift Backend inherits from Broker in the interests of not rocking the boat too much | 23:04 |
| zaitcev | but notionally they are independent | 23:04 |
| clayg | I never could get diskfile patches up fast enough to beat out portante so if you persever you'll probably beat me out ;) | 23:05 |
| *** byeager has quit IRC | 23:05 | |
| zaitcev | oh, wait | 23:06 |
| zaitcev | I see that you apparently flipped broker and backend around with that statement about the ilk or higher order, but otherwise they are same | 23:06 |
| zaitcev | okay. The reason why 47713 is like now, higher order ilk needs the path like you said. However, you can calculate path from root/dev/part/a/c/o + h + .suff, but going backwards is a major pain. Therefore at least the calls to create instances must go that way, backend calling broker. Granted it's possible to subclass in the opposite direction... | 23:10 |
| *** rupsky has joined #openstack-swift | 23:12 | |
| zaitcev | We have subclasses providing "callback" methods today. Initialization is full of them. | 23:12 |
| zaitcev | Personally I am not a fan, but perhaps I need to think in object-oriented way. | 23:12 |
| *** Midnightmyth has quit IRC | 23:12 | |
| *** rupsky has left #openstack-swift | 23:12 | |
| clayg | well, if nothing else I like the idea of the think called Backend being the thing that's used by backend services, but more to point I'm assuming that basically everything that isn't the wsgi server starts with a db_file - so Backend could override the Broker's __init__ | 23:23 |
| clayg | I also have a feeling that if I start with A/CBroker I'll find that most of the code tangling that comes out of the shared DBBroker base goes away - the things the wsgi server calls on A/CBroker are mostly independent implementations anyway (get_info, list_X_iter, is_status_deleted) | 23:25 |
| clayg | ... but that's just hunch - I'd need to try it out and see | 23:26 |
| -openstackstatus- NOTICE: paste.openstack.org is going down for a short database upgrade | 23:27 | |
| zaitcev | it's true that syncs go away | 23:29 |
| zaitcev | initialization stays | 23:29 |
| clayg | zaitcev: well all the tables in _initialize_db are specific - and as you did in 47713 - it all needs to get re-written as create anyway | 23:30 |
| luisbg | zaitcev, gmail has a cancel feature (you can activate it and it gives you some seconds to realize you made a typo or hit submit accidentally) | 23:31 |
| luisbg | have a good weekend everyone! | 23:32 |
| *** shri has quit IRC | 23:48 | |
| *** mwstorer has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!