Tuesday, 2014-08-19

*** tsg has joined #openstack-swift00:00
*** yuanzz has joined #openstack-swift00:05
*** yuanz has quit IRC00:08
*** dmorita has joined #openstack-swift00:27
*** shri has quit IRC00:56
*** addnull has joined #openstack-swift01:05
*** nexusz99 has joined #openstack-swift01:18
*** kota_ has quit IRC01:31
*** shakamunyi has joined #openstack-swift01:33
*** haomaiwa_ has joined #openstack-swift01:46
*** nosnos has joined #openstack-swift01:47
*** tsg has quit IRC01:48
*** mitz has quit IRC01:48
*** dmsimard_away has quit IRC01:48
*** kevinc_ has quit IRC01:54
*** tsg has joined #openstack-swift01:57
*** dmsimard_away has joined #openstack-swift01:57
*** morganfainberg is now known as morganfainberg_Z02:14
*** addnull has quit IRC02:14
*** Krast_ has quit IRC02:26
*** Krast has joined #openstack-swift02:26
*** annegentle has joined #openstack-swift02:34
*** addnull has joined #openstack-swift02:45
*** addnull has quit IRC02:49
openstackgerritA change was merged to openstack/swift: add the account management config values to swift info  https://review.openstack.org/11487802:50
* notmyname is looking through git history and open reviews and thinking about the next swift release03:02
*** dmorita has quit IRC03:03
*** dmorita has joined #openstack-swift03:04
*** shakayumi has joined #openstack-swift03:07
mattoliveraunotmyname: is it getting clearer?03:08
notmynamemattoliverau: ?03:08
mattoliveraunotmyname: thinking about the next swift release :)03:09
notmynamethat's what thinking about it is supposed to do. I just started :-)03:09
*** shakamunyi has quit IRC03:09
*** shakayumi has quit IRC03:10
mattoliveraulol03:10
*** addnull has joined #openstack-swift03:18
*** addnull has quit IRC03:18
*** addnull has joined #openstack-swift03:19
*** haomaiwa_ has quit IRC03:20
notmynamemattoliverau: going through what's landed, I'm starting to think that 2.1.0 is better than 2.0.103:21
notmynamea few defaults were changed and some log stuff changed (at least)03:21
mattoliverauahh yeah, logging and defaults changes might require a bigger release number. otherwise operators might get grumpy03:23
*** dmorita has quit IRC03:28
*** dmorita has joined #openstack-swift03:29
*** gyee_ has quit IRC03:32
*** haomaiwang has joined #openstack-swift03:34
*** tsg has quit IRC03:47
*** annegentle has quit IRC03:51
*** addnull has quit IRC03:58
*** xianghuihui has quit IRC04:03
*** xianghuihui has joined #openstack-swift04:03
*** shakamunyi has joined #openstack-swift04:07
notmynamemattoliverau: you're added to the AUTHORS file in this release!04:12
mattoliveraunotmyname: woo!! That's awesome!04:12
*** addnull has joined #openstack-swift04:13
*** xianghuihuihui has joined #openstack-swift04:15
*** xianghuihui has quit IRC04:18
*** xianghuihuihui has quit IRC04:20
*** xianghui has joined #openstack-swift04:21
*** haomaiwang has quit IRC04:23
*** haomaiwang has joined #openstack-swift04:23
openstackgerritJohn Dickinson proposed a change to openstack/swift: authors and changelog updates for 2.1.0 release  https://review.openstack.org/11516704:24
notmynameinteresting.04:25
notmynamesometimes in the last couple of months I feel that dev work has slowed on swift (not as many people contributing). but that's actually not true at all04:27
notmynamehttps://gist.github.com/notmyname/7146d6ccdeb54d16ca3804:27
notmynamewe're actually slightly higher on the number of people participating in a release04:28
notmynameand we've got 7 new contributors in this one, which is about normal04:28
*** haomaiw__ has joined #openstack-swift04:29
*** haomaiwang has quit IRC04:32
mattoliverauwell there you go then, the swift project, still going strong. :) I get the impression that many cores are working on big awesome features (like SP and EC) while other devs are extending parts they use (scratching thier itches)  (tempurl, logging, formpost, etc.).. So nice work on the healthy developer community and friendly dev environment. I know I'm enjoying it :)04:36
notmynamemattoliverau: great to hear. and I think you're right04:36
openstackgerritJohn Dickinson proposed a change to openstack/swift: authors and changelog updates for 2.1.0 release  https://review.openstack.org/11516704:41
notmynameperfect. all authors properly tracked now04:42
zaitcevA big chunk of core like EC is going to create a distortion. Also, a ton of work is in PyECLib.04:43
*** haomaiw__ has quit IRC04:43
notmynameyup04:43
*** haomaiwang has joined #openstack-swift04:43
notmynameAUTHORS has 173 people in it. git shows 170 people with commits. which is exactly right. we have 3 contributors acknowledged with no commits in swift04:45
notmynameone did code work before it was open-sourced. one did doc work. and the last intentionally didn't do any coding, but was the initial designer of the system at rackspace04:46
notmynameand if you're curious and don't want to do the archaeology yourself, they are Ed Leafe, Stephen Milton, and Will Reese (respectively)04:48
notmynameand I just published the tool I use to keep track of these things at every release. https://github.com/notmyname/git-stats04:50
notmynameit's got hard-coded path names and stuff, but it's useful to me04:50
*** tsg has joined #openstack-swift04:52
*** kopparam has joined #openstack-swift04:52
notmyname"* Various other minor bug fixes and improvements" is my favorite changelog entry04:54
StevenKnotmyname: It may as well as include "Please read the diff for details" :-)04:57
notmynameStevenK: what!? you, the deployer, didn't read the code!?!04:57
StevenKHaha04:57
mattoliveraulol04:58
notmynameI strongly believe that `git shortlog >changelog` is very unhelpful to anyone and hand-curated changelogs are the way to go. so if we (I) miss something there, we're letting the deployers down about what's important04:59
notmyname(shade-grown, artisanal, organic changelogs. written with love.)05:00
notmynameoh, and free-range too. that's important05:00
*** zaitcev has quit IRC05:02
mattoliveraulol, very important, and don't forget gluten free05:03
notmynamenaturally05:03
StevenKlow sodium, too05:03
notmynameand naturally gluten free05:03
StevenKNow with more buzzwords!05:04
notmynameStevenK: nah, we're a bunch of salty old devs ;-)05:04
notmynameok, as a tentative framework, here's what I'm proposing for the rest of the juno cycle05:05
notmyname2.1.0 rc next monday (aug 25) with a final release on monday sept 105:06
notmynamethen swift-next (either 2.2.0 or 2.1.1) RC on monday october 6. this will be the release included in the juno integrated release on october 1605:07
notmynameI'll review these dates with ttx in the morning and see how they work with his schedule05:07
*** Krast has quit IRC05:08
notmynameand if there is any change (or even if there isn't), I'll also make sure this is brought up in the team meeting on wednesday05:09
mattoliveraunotmyname: awesome, sounds like good plan to me :)05:09
*** shakamunyi has quit IRC05:13
notmyname...and with that, I'm off to bed. I've got an early start tomorrow05:14
mattoliveraunotmyname: good night!05:17
*** ppai has joined #openstack-swift05:30
*** k4n0 has joined #openstack-swift05:36
*** nottrobin has quit IRC05:36
*** nottrobin has joined #openstack-swift05:37
*** Alex_Gaynor has quit IRC05:37
*** morganfainberg_Z is now known as morganfainberg05:41
*** Alex_Gaynor_ has joined #openstack-swift05:41
*** Alex_Gaynor_ is now known as Alex_Gaynor05:55
*** Alex_Gaynor has quit IRC05:55
*** Alex_Gaynor has joined #openstack-swift05:55
*** Krast has joined #openstack-swift06:14
*** haomaiw__ has joined #openstack-swift06:27
*** Krast has quit IRC06:28
*** haomaiwang has quit IRC06:30
*** nshaikh has joined #openstack-swift06:33
*** joeljwright has joined #openstack-swift06:52
*** chandankumar has joined #openstack-swift07:04
*** kopparam has quit IRC07:18
*** kopparam has joined #openstack-swift07:19
*** kopparam has quit IRC07:23
*** mitz has joined #openstack-swift07:49
*** kopparam has joined #openstack-swift07:53
*** aix has joined #openstack-swift07:57
*** kopparam has quit IRC07:58
*** fifieldt_ has joined #openstack-swift07:58
openstackgerritA change was merged to openstack/python-swiftclient: Do not create an empty directory 'pseudo/'  https://review.openstack.org/11514107:59
*** bkopilov has joined #openstack-swift08:17
*** nexusz99 has quit IRC08:18
*** kopparam has joined #openstack-swift08:19
*** Krast has joined #openstack-swift08:22
*** tanee has joined #openstack-swift08:31
*** aix has quit IRC08:31
*** tsg has quit IRC08:32
*** joeljwright has quit IRC08:47
*** joeljwright has joined #openstack-swift08:48
*** aix has joined #openstack-swift08:59
*** mkollaro has joined #openstack-swift09:13
*** tanee has quit IRC09:15
*** tanee has joined #openstack-swift09:15
*** fifieldt_ has quit IRC09:18
*** bkopilov has quit IRC09:24
*** addnull has quit IRC09:44
*** geaaru has joined #openstack-swift09:44
*** ujjain has quit IRC09:46
*** addnull has joined #openstack-swift09:48
*** ujjain has joined #openstack-swift09:48
geaaruhi, i'm a newbie of swift. In all examples that I found I see that rings are created all with name object.builder, container.builder and account.builder. Are mandatary these names ? If not what is options to set for define use of correct ring ? thanks in advance09:49
*** ujjain has quit IRC09:51
*** ujjain has joined #openstack-swift09:51
*** kopparam has quit IRC10:21
*** kopparam has joined #openstack-swift10:22
*** kopparam has quit IRC10:26
*** zul has quit IRC10:36
*** Midnightmyth has joined #openstack-swift10:50
*** mitz has quit IRC10:51
*** mitz has joined #openstack-swift10:53
*** kopparam has joined #openstack-swift10:53
*** kopparam has quit IRC11:33
*** dmsimard_away is now known as dmsimard11:39
*** nexusz99 has joined #openstack-swift11:55
*** ppai has quit IRC11:58
*** Krast has quit IRC12:02
nexusz99Hi. I'm using swift3 middleware and running proxy-server on apache web server. If i request 'PUT BUCKET', swift3 middleware response 'Location: /[bucket]' in response header. And then Apache redirect to '/bucket' by GET Method. But keystone response 403 forbidden. is there any solution to solve this problem?12:04
*** dmorita has quit IRC12:17
*** nexusz99 has quit IRC12:29
*** annegentle has joined #openstack-swift12:30
*** addnull has quit IRC12:33
*** kopparam has joined #openstack-swift12:44
*** kopparam has quit IRC12:46
*** annegentle has quit IRC12:52
*** nosnos has quit IRC12:56
*** miqui has joined #openstack-swift13:19
*** mrsnivvel has quit IRC13:21
notmynamegeaaru: you should use those names. the swift-ring-builder edits the .builder files and generates .ring.gz files. and the .ring.gz files have to be named a certain way. so using the documented .builder names just makes your life easier13:44
*** HenryG_ has joined #openstack-swift13:46
*** HenryG has quit IRC13:47
*** tdasilva has joined #openstack-swift13:48
geaarunotmyname: ok, thank for reply13:55
geaaru*thanks13:55
openstackgerritpaul luse proposed a change to openstack/swift: Fix sporadic false failure in xprofile unit test code (master)  https://review.openstack.org/11529213:58
*** HenryG_ is now known as HenryG14:07
*** cebruns_ has quit IRC14:12
*** shakamunyi has joined #openstack-swift14:16
*** chandankumar has quit IRC14:17
*** shakamunyi has quit IRC14:32
*** tsg has joined #openstack-swift14:35
*** shakamunyi has joined #openstack-swift14:47
*** annegentle has joined #openstack-swift15:03
*** annegentle has quit IRC15:03
*** annegentle has joined #openstack-swift15:04
*** tsg has quit IRC15:07
*** kevinc_ has joined #openstack-swift15:07
notmynamegood morning15:35
*** nshaikh has quit IRC15:35
*** kevinc_ has quit IRC15:41
*** gyee has joined #openstack-swift15:41
*** nexusz99 has joined #openstack-swift15:43
pelusegood morning15:45
notmynamemattoliverau: will you be able to put a summary of oslo.messaging together by the swift team meeting this week? https://etherpad.openstack.org/p/swift_gap_scratchpad15:48
notmynamehurricanerix: will you be able to put a summary of oslo.logging together by the swift team meeting this week? https://etherpad.openstack.org/p/swift_gap_scratchpad15:48
notmynamecschwede:  will you be able to put a summary of oslo.serialization together by the swift team meeting this week? https://etherpad.openstack.org/p/swift_gap_scratchpad15:49
hurricanerixnotmyname: yeah, i am working on something.  at the least it will be a list of questions that need to be answered, but i will try to fill in as much as i can.15:49
notmynamelooks like those are the only 3 oslo libraries left15:49
notmynamehurricanerix: thanks :-)15:49
hurricanerixnotmyname: np15:50
*** elambert has joined #openstack-swift15:53
*** kevinc_ has joined #openstack-swift15:55
*** wer has quit IRC15:55
*** kevinc_ has quit IRC15:57
*** chandankumar has joined #openstack-swift15:57
*** nexusz99 has quit IRC15:57
*** nexusz99 has joined #openstack-swift15:58
*** wer has joined #openstack-swift16:03
*** tsg has joined #openstack-swift16:16
*** mwstorer has joined #openstack-swift16:26
*** shri has joined #openstack-swift17:08
*** geaaru has quit IRC17:08
*** annegentle has quit IRC17:15
*** dmsimard is now known as dmsimard_away17:17
*** chandankumar has quit IRC17:39
*** shakamunyi has quit IRC17:39
*** nexusz99 has quit IRC18:01
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-swiftclient: Updated from global requirements  https://review.openstack.org/8925018:07
openstackgerritOpenStack Proposal Bot proposed a change to openstack/swift: Updated from global requirements  https://review.openstack.org/8873618:07
*** annegentle has joined #openstack-swift18:10
*** shakamunyi has joined #openstack-swift18:11
*** aix has quit IRC18:15
*** dmsimard_away is now known as dmsimard18:19
*** dmsimard is now known as dmsimard_away18:24
*** chandankumar has joined #openstack-swift18:28
openstackgerritA change was merged to openstack/swift: Update tempurl docstring with methods config option  https://review.openstack.org/11255918:28
*** shakamunyi has quit IRC18:30
*** zaitcev has joined #openstack-swift18:32
*** ChanServ sets mode: +v zaitcev18:32
*** shakamunyi has joined #openstack-swift18:44
*** erlon has joined #openstack-swift18:55
notmynamelast night I went through the commit history and planed out the next couple of releases. here's what's tentatively scheduled (reposting during the day for most of you)18:59
notmynamenext monday (aug 25) cut 2.1.0 RC. the current WIP changelog is at https://review.openstack.org/#/c/115167/18:59
notmynamethen finalize it on sept 118:59
notmynamethen do the 2.next release which will be in the juno integrated release on oct 6, finalized on oct 16 (the day of the juno release)19:00
*** gyee has quit IRC19:08
*** tsg has quit IRC19:30
*** mahatic has joined #openstack-swift19:35
*** kevinc_ has joined #openstack-swift19:37
*** dmsimard_away is now known as dmsimard19:38
tdasilvanotmyname: wrt 114120, i was just pointing out that current behavior if a client tried to delete an object that did not exist, it would receive a 404 back, with this patch it changes to 20419:39
tdasilvaI think that's the same thing torgomatic was saying...19:39
*** dmsimard is now known as dmsimard_away19:39
tdasilvanotmyname: definitely not a big deal, but just seemed like a change in behavior19:39
notmynametdasilva: yes, we're all saying the same thing :-)19:40
*** mahatic_ has joined #openstack-swift19:40
tdasilvaok19:40
tdasilva:D19:40
* notmyname wonders if gerrit can filter out "-1 because can't be merged" vs "-1 because gate failed"19:41
*** joeljwright1 has joined #openstack-swift19:42
*** joeljwright has quit IRC19:44
*** mahatic has quit IRC19:47
*** dmsimard_away is now known as dmsimard19:54
*** tsg has joined #openstack-swift19:54
notmynamelooks like gerrit 2.9 has a "is:mergeable" search query. but we run 2.819:55
*** dmsimard is now known as dmsimard_away19:56
*** chandankumar has quit IRC19:56
*** dmsimard_away is now known as dmsimard19:58
*** acoles has quit IRC20:06
*** mkollaro has quit IRC20:09
*** acoles_away has joined #openstack-swift20:12
*** acoles_away is now known as acoles20:12
*** ChanServ sets mode: +v acoles20:12
*** Midnightmyth has quit IRC20:27
openstackgerritJoel Wright proposed a change to openstack/python-swiftclient: Add importable SwiftService incorporating shell.py logic  https://review.openstack.org/8545320:32
*** gyee has joined #openstack-swift20:36
*** dmsimard is now known as dmsimard_away20:37
*** kevinc_ has quit IRC20:45
*** shakamunyi has quit IRC20:46
*** miqui has quit IRC20:49
*** joeljwright1 has quit IRC21:22
*** fifieldt has quit IRC21:27
*** Midnightmyth has joined #openstack-swift21:29
*** fifieldt has joined #openstack-swift21:41
*** annegentle has quit IRC22:01
mattoliverauMorning all22:06
notmynamemattoliverau: hi22:06
mattoliveraunotmyname: I'll make sure I wrote something about oslo.messaging today, at least enough to get a discussion going :)22:09
notmynamemattoliverau: thanks22:09
*** HenryG_ has joined #openstack-swift22:17
*** occupant has quit IRC22:17
*** HenryG has quit IRC22:19
*** occupant has joined #openstack-swift22:23
openstackgerritSamuel Merritt proposed a change to openstack/swift: Respect device weights when adding replicas  https://review.openstack.org/11541622:25
torgomatic*whew*22:25
torgomaticringbuilder code is always its own special blend of too-many-moving-parts... of course, I've added some of those parts over the years, so I can't complain too much22:26
notmynametorgomatic: and the best part is that the effective resulting patch is just like that one: +3/-1 lines22:27
torgomaticnotmyname: well, it was a simple enough bug once I saw it... the trick was finding it in the first place :)22:27
notmynametorgomatic: that would be good to get into this upcoming release (ie landed by friday)22:29
torgomaticnotmyname: well, I'm not gonna +2 it... get to work! ;)22:29
*** carolinea has joined #openstack-swift22:34
*** bill_az_ has joined #openstack-swift22:34
carolineaI have a question about handoff. anyone around to help?22:35
torgomaticcarolinea: I can take a shot22:37
thurloatsilly question, having trouble finding the docs for it: how do I set the content type of an object using swiftclient ?22:38
carolineaSo the replicator will push objects to a handoff zone if it cant write to one of the primary zones is what I see in all of the documentation, and have heard in training; but I tried to produce this in a cluster, and I didn't see handoff taking place. I calculated 1-3 and handoff for an object, wrote the object, saw it in all 3 primary locations. took down the networking on one of the primary locations and didn't see the obje22:38
*** occupant has quit IRC22:38
*** occupant has joined #openstack-swift22:39
torgomaticcarolinea: a node-down failure won't cause replication; try unmounting the disk22:40
torgomaticthurloat: I think there's a -H option to set arbitrary headers; try that22:40
torgomaticif it's not -H, it's something like it22:41
carolineaokay, that is what someone told me recently but I wasn't sure. So is the replicator looking for a response from the other object node saying that the drive is down and it needs to go elsewhere? as opposed to the replicator going to handoff if it doesnt get a response?22:41
thurloatswift post -H "Content-Type:text/html" ? or does it need the whole X-Object-Blah ?22:41
torgomaticcarolinea: yeah, that... the replicator needs to get a 507 response before it'll push elsewhere. It's to prevent replication storms during a rolling upgrade22:42
thurloattorgomatic: that seemed to do the trick *cheers*22:42
torgomaticif you didn't do this, every time you took a node down for a couple minutes to upgrade its software, the rest of the cluster would start replicating what was on there22:42
torgomaticthurloat: hooray! :)22:42
carolineatorgomatic: thank you!22:43
torgomaticcarolinea: you're quite welcome :)22:43
carolineatorgomatic: that makes sense, as to why to control that22:43
carolineatorgomatic: thanks again, have a good night!22:43
*** carolinea has quit IRC22:51
*** shakamunyi has joined #openstack-swift23:02
thurloatAre there performance implications for containers with thousands / tens of thousands / hundreds of thousands of files ?23:02
thurloatrather than having them with paths to define "folders", just a flat container23:03
*** tdasilva has quit IRC23:05
*** tsg has quit IRC23:14
*** shakamunyi has quit IRC23:18
notmynamethurloat: remember that containers aren't nested, so "a/c/o/foo/bar/baz" and "/a/c/o/bar/baz/foo" are in the same container23:20
thurloatnotmyname: yeah, sorry if unclear.23:20
thurloatwanting to ensure that having files as /acofoobarbazz and a/c/o/foo/bar/baz aren't any slower23:21
notmynamethurloat: and there is a performance impact for object PUTs as the number of objects in the cluster gets bigger. this is one reason we always recommend to use a lot of containers23:21
notmynamethurloat: correct. slashes in an object name have no impact on object read or write performance23:21
thurloatI just noticed that the swiftclient and glance swift backend behave differently for segmented files23:21
thurloatthe swiftclient puts hte segments in their own container, whereas the glance backend puts them all in the same container with .0001, .000223:22
thurloatnoticed that after about 1tb of glance images had been uploaded to swift, the number of files is growing quickly23:22
notmynamethurloat: hmm..that's interesting23:25
thurloatnotmyname: and in the process of migrating some glance images from our ceph backend to swift using the swiftclient, it's laying the files out differently when segmenting23:25
notmynamethurloat: is glance using large object manifests or are they managing the chunks themselves?23:27
*** Midnightmyth has quit IRC23:28
thurloatnotmyname:       Manifest: glance/05744531-c108-4344-8c19-8f74bf710793-23:30
thurloaton one of the glance images `swift stat`23:30
thurloatand       Manifest: glance_segments/b3ac3fd0-fee3-460c-ac4f-b0b71e6d3e6f/1408490408.717103/985661440/209715200 is what i get from when I copy the files in using swiftclient.23:31
thurloatlooks manifesty to me23:31
notmynamethurloat: is that 2 different containers? glance and glance_segments?23:32
thurloatuploading the image to glance container, swiftclient automatically created the glance_segments container for the segments23:33
*** shakamunyi has joined #openstack-swift23:33
notmynameoh ok23:33
notmynamethurloat: but when glance puts the chunks into the container, does it use manifests or not?23:33
thurloatyeah it does use manifests23:34
notmynamedynamic or static?23:34
thurloathttps://github.com/openstack/glance/blob/master/glance/store/swift.py#L53323:35
notmynamethurloat: ok, thanks (dynamic, BTW)23:36
thurloatthanks, was just skimming the src to find out.23:36
thurloatI don't think glance is going to be doing anything other than create/retrieve of full object paths since is stores the object path in the DB, doesn't actually do any list calls.23:38
notmynamethurloat: what are you trying to do. you said that glance is putting them in the same container. that works, if you get the prefixes right.23:41
thurloatnotmyname: wanted to check in before some client performs a snapshot that fails to upload because of some timeout on a large container. All is working as expected currently, was concerned when I noticed the swiftclient wrote the segments elsewhere.23:42
notmynamethurloat: ah, ok23:42
*** HenryG_ is now known as HenryG23:42
thurloatperhaps at some point, I'll rewrite the glance backend to use multiple containers to keep object count below 10k or something per container.23:42
notmynamethurloat: are you using flash or spinning drives in your container rings?23:43
thurloatnotmyname: rusty platters ATM.23:43
notmynamethurloat: ah. then in that case "large containers" would be around 1 million objects. (maybe 2 million, depending on how active they are). if you use flash, large containers become 10-50 million or more23:44
notmyname100 million even23:44
thurloatbeautiful information. thanks. will factor that into our growth costs.23:45
notmynamethurloat: also, remember that this only matters for object writes. object reads are unaffected23:45
notmynamethurloat: so if you have a lot of clients uploading to the same container at the same time, and that container is on spinning drives, you're going to have a bad time. higher IOPS on containers will let you have more write concurrency in a single containers23:46
torgomaticalso note that if you're planning to rewrite the Glance backend, making it use static large objects would take container listings out of the equation entirely23:46
notmynamethurloat: ^^ one reason static objects are better23:47
notmynamethurloat: what's you're expected load? are you looking to have 50+ glance backups per second?23:47
notmynameeg with 1 million objects in a container and that container on spinning drives (sharing page cache with object servers), you'll see aroung a 10-20 writes/second limit23:48
notmynameeg with 100 million objects in one container and that container on flash on its own server, you'll see 500+ writes/second limit23:49
notmynameie, flash is faster23:49
openstackgerritA change was merged to openstack/swift: Fix sporadic false failure in xprofile unit test code  https://review.openstack.org/11478123:49
thurloatwill definitely note static large files when it comes time to optimize the setup, we're currently looking at 1-3 concurrent glance snaps. usually in off hours, since no one likes taking their VMs offline during the day.23:51
notmynamethurloat: so really it all depends on your scale. if you're doing small scale stuff like just a few writes per minute and only a few tens of thousands of snapshots, then you have nothing to worry about23:51
thurloati'll know what to look out for :) cheers notmyname & torgomatic!23:52

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!