Thursday, 2014-05-01

notmynamephyscx: thanks00:00
*** bach has joined #openstack-swift00:02
*** matsuhashi has joined #openstack-swift00:04
*** ChanServ changes topic to "Current Swift Release: 1.13.1 | Priority Reviews: https://wiki.openstack.org/wiki/Swift/PriorityReviews | Channel Logs: http://eavesdrop.openstack.org/irclogs/%23openstack-swift/"00:05
-openstackstatus- NOTICE: the gate is still fairly backed up, though nodepool is back on track and chipping away at remaining changes. some py3k/pypy node starvation is slowing recovery00:05
*** bach has quit IRC00:07
*** bach has joined #openstack-swift00:12
*** joeljwright has joined #openstack-swift00:16
claygpeluse_: so i was doing some functional tests for storage policies and noticed that clients can send x-storage-policy-index headers through the proxy for some reason?00:18
claygphyscx: and is there less cpu somehow doing chunked uploads with the buffering in diskfile?00:20
*** joeljwright has quit IRC00:20
*** dvas_ has joined #openstack-swift00:21
*** dvas_ has quit IRC00:25
*** wer has quit IRC00:26
*** wer has joined #openstack-swift00:27
*** bill_az has quit IRC00:34
*** dmorita has joined #openstack-swift00:36
*** csd_ has quit IRC00:39
*** bach has quit IRC00:56
*** joeljwright has joined #openstack-swift01:16
*** praveenkumar has quit IRC01:19
*** joeljwright has quit IRC01:21
*** dvas_ has joined #openstack-swift01:22
*** dvas_ has quit IRC01:26
*** saschpe has quit IRC01:28
*** saschpe has joined #openstack-swift01:29
openstackgerritA change was merged to openstack/swift: Merge tag '1.13.1'  https://review.openstack.org/9141701:46
*** nosnos has joined #openstack-swift01:49
*** mkollaro has joined #openstack-swift01:52
*** dvas_ has joined #openstack-swift01:52
peluse_clayg:  yeah, that's probably true.  we talked about preventing it but I think just implemented the translation on response headers at the time01:55
*** dvas_ has quit IRC01:55
peluse_clayg:  let me know if you want me to take care of it if you haven't already01:55
*** dvas_ has joined #openstack-swift01:56
claygpeluse_: nah it's cool i got it01:58
claygpeluse_: thanks for confirming01:59
*** zhiyan_ is now known as zhiyan01:59
*** dvas_ has quit IRC02:00
peluse_clayg:  no problema02:06
claygpeluse_: do you think the storage_policy key in container info should be named storage_policy_index or at least be an integer?02:08
peluse_clayg:  at least and int, yeah that makes sense.  I'm not a huge fan of the longer names and not sure we'll have too many other types of policies but for consistency might as well02:15
claygi'm less worried about the name, tripped me up it wasn't already cast for me - should I file it in trello?02:16
peluse_clayg:  up to you, doesn't seem like a very big thing to fix so adding a card might be more work than pushing the patch02:17
*** joeljwright has joined #openstack-swift02:18
*** joeljwright has quit IRC02:23
*** swills has quit IRC02:23
*** swills has joined #openstack-swift02:23
*** dvas_ has joined #openstack-swift02:26
*** dvas_ has quit IRC02:30
*** haomai___ has joined #openstack-swift02:51
*** haomaiwang has quit IRC02:54
*** mrsnivvel has joined #openstack-swift03:10
*** zhiyan is now known as zhiyan_03:18
*** joeljwright has joined #openstack-swift03:19
claygyuan: what ever happened to the patch to do the container migrations in the container auditor?03:19
*** dvas_ has joined #openstack-swift03:20
*** joeljwright has quit IRC03:23
*** dvas_ has quit IRC03:25
openstackgerritClay Gerrard proposed a change to openstack/swift: Additional functional tests for Storage Policies  https://review.openstack.org/9150203:28
openstackgerritClay Gerrard proposed a change to openstack/swift: Fix cross policy versioning DELETE  https://review.openstack.org/9150303:28
*** matsuhashi has quit IRC03:28
claygpeluse_: lol - i missed your first pass of comments on yuan's functional tests (in the gate) - you'll probably have to make them all again on https://review.openstack.org/#/c/91502/03:35
claygg'night03:35
peluse_clayg:  will do... night03:43
*** nosnos has quit IRC03:46
*** mkollaro has quit IRC03:51
*** madhuri has quit IRC04:04
*** madhuri has joined #openstack-swift04:04
*** dvas_ has joined #openstack-swift04:14
*** dvas_ has quit IRC04:19
*** joeljwright has joined #openstack-swift04:20
*** joeljwright has quit IRC04:25
*** matsuhashi has joined #openstack-swift04:35
*** nosnos has joined #openstack-swift04:36
*** matsuhashi has quit IRC04:48
*** matsuhashi has joined #openstack-swift04:53
*** bill_az has joined #openstack-swift05:05
*** dvas_ has joined #openstack-swift05:08
*** dvas_ has quit IRC05:13
*** joeljwright has joined #openstack-swift05:21
*** joeljwright has quit IRC05:26
*** zaitcev has quit IRC05:31
*** bach has joined #openstack-swift05:52
*** dvas_ has joined #openstack-swift06:02
*** bach has quit IRC06:03
*** dvas_ has quit IRC06:07
*** bach has joined #openstack-swift06:09
*** joeljwright has joined #openstack-swift06:23
*** joeljwright has quit IRC06:27
openstackgerritAndreas Jaeger proposed a change to openstack/python-swiftclient: Add "." for help strings  https://review.openstack.org/9152406:39
*** bill_az has quit IRC06:39
*** chandan_kumar has joined #openstack-swift06:44
*** dvas_ has joined #openstack-swift06:57
*** dvas_ has quit IRC07:01
*** dvas_ has joined #openstack-swift07:07
*** chandan_kumar has quit IRC07:07
*** matsuhashi has quit IRC07:09
*** matsuhas_ has joined #openstack-swift07:12
*** joeljwright has joined #openstack-swift07:23
*** joeljwright has quit IRC07:28
*** acoles_away is now known as acoles07:34
*** joeljwright has joined #openstack-swift07:52
*** mkerrin has joined #openstack-swift08:03
*** dvas_ has quit IRC08:19
*** matsuhas_ has quit IRC08:33
*** dvas_ has joined #openstack-swift08:40
*** matsuhashi has joined #openstack-swift08:41
*** zanc has quit IRC09:20
*** matsuhashi has quit IRC09:32
*** matsuhashi has joined #openstack-swift09:33
*** ccorrigan has quit IRC09:53
*** nosnos has quit IRC09:54
*** ccorrigan has joined #openstack-swift09:56
*** Midnightmyth has joined #openstack-swift09:59
*** Midnightmyth has quit IRC10:07
*** mkollaro has joined #openstack-swift10:07
*** chandan_kumar has joined #openstack-swift10:15
*** dmorita has quit IRC10:34
*** chandan_kumar has quit IRC10:52
*** dvas__ has joined #openstack-swift11:14
*** dvas_ has quit IRC11:15
*** Midnightmyth has joined #openstack-swift11:19
*** dvas___ has joined #openstack-swift11:40
*** dvas__ has quit IRC11:42
*** bach has quit IRC11:45
*** dvas___ has quit IRC11:45
*** dvas___ has joined #openstack-swift11:45
*** bach has joined #openstack-swift11:45
*** tdasilva has joined #openstack-swift12:02
*** mkollaro has quit IRC12:38
openstackgerritOpenStack Proposal Bot proposed a change to openstack/swift: Updated from global requirements  https://review.openstack.org/8873612:43
*** changbl has quit IRC12:59
*** bach has quit IRC13:26
*** Midnightmyth has quit IRC13:30
*** bach has joined #openstack-swift13:35
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-swiftclient: Updated from global requirements  https://review.openstack.org/8925013:50
*** shakamunyi has joined #openstack-swift13:59
*** chandan_kumar has joined #openstack-swift14:01
*** byeager has joined #openstack-swift14:10
physcxclayg: no, buffering has no effect on this problem (eventlets wsgi chunked read) - it gets worse as network_chunk_size increases though so buffering was an attempt at keeping it small while still being able to increase the size of chunks passed to the disk14:51
*** rcleere has quit IRC14:52
notmynameredbo: did you see http://blog.plenz.com/2014-04/so-you-want-to-write-to-a-file-real-fast.html ?14:53
*** matsuhashi has quit IRC14:54
portantenice, and I had a conversation at the same time!14:59
peluse_portante:  so I ran in process on the SP code - merged ec+master+yuanz's branch w/SP specific functional tests (and one tweak to your process patch to add another obj ring)15:05
peluse_portante:  ran link a champ and has withint 1% same coverage as master15:05
peluse_portante:  I looked into some of the details and it makes sense as much of the SP specific code is executed regardless of whether you are using pol 0 (legacy) or a 2nd one so we would expect about the same coverage15:06
peluse_also FYI for everyone.  quick snapshot of diff stats between SP and master to gauge size of full set of patches:15:06
peluse_functional code:  LOC added 653.  LOC changed: 423  (w/o reconciler)15:07
peluse_test code:  LOC added 2427.  LOC changed: 1036 (w/o reconciler)15:08
notmynamefirst thought: most expensive 1k lines evar15:09
peluse_ha!  I like the functional/test LOC ratios though15:10
portantepeluse_: sec15:11
*** mmcardle has joined #openstack-swift15:12
*** kevinc_ has joined #openstack-swift15:13
*** bach has quit IRC15:22
*** bach has joined #openstack-swift15:23
*** bach has quit IRC15:23
*** changbl has joined #openstack-swift15:27
*** dvas___ has quit IRC15:28
*** dvas___ has joined #openstack-swift15:29
*** byeager has quit IRC15:30
*** byeager has joined #openstack-swift15:30
*** dvas____ has joined #openstack-swift15:31
*** dvas___ has quit IRC15:33
*** byeager has quit IRC15:36
*** byeager has joined #openstack-swift15:36
* peluse_ needs to step away for ~20 min15:37
*** chandan_kumar has quit IRC15:39
*** bach has joined #openstack-swift15:39
*** bach has quit IRC15:41
*** byeager has quit IRC15:42
*** byeager has joined #openstack-swift15:43
*** bach has joined #openstack-swift15:46
*** kevinc_ has quit IRC15:47
*** bach_ has joined #openstack-swift15:48
*** bach_ has quit IRC15:49
*** bach has quit IRC15:51
*** bach has joined #openstack-swift15:51
*** kevinc_ has joined #openstack-swift15:51
*** bach has quit IRC15:53
*** mwstorer has joined #openstack-swift15:55
*** mmcardle has quit IRC16:07
*** zaitcev has joined #openstack-swift16:09
*** ChanServ sets mode: +v zaitcev16:09
*** dvas____ has quit IRC16:32
*** dvas____ has joined #openstack-swift16:33
*** dvas____ has quit IRC16:37
*** dvas____ has joined #openstack-swift16:38
*** dvas____ has quit IRC16:38
*** dvas____ has joined #openstack-swift16:39
*** dvas____ has quit IRC16:43
*** dvas____ has joined #openstack-swift16:55
*** Midnightmyth has joined #openstack-swift16:58
*** dvas____ has quit IRC16:59
*** mmcardle has joined #openstack-swift17:00
*** bach has joined #openstack-swift17:04
*** shri has joined #openstack-swift17:07
*** shakamunyi has quit IRC17:09
*** byeager has quit IRC17:10
*** mmcardle has quit IRC17:11
claygi'm looking at a gate failure for grenade where n-net failed to start, and I don't know why?  It has a screen log in old/ but not in new/ - and then vms' go to state error timeout waiting on network17:15
clayghave anyone ever had any luck asking in #openstack or -infra about something like that?  I'm not sure what bug to file?17:15
peluse_clayg:  not I but glad to see the SP functional tests get approved!  did you see my earlier comments on func tests w/policies?17:17
claygpeluse_: only too late - can you make them again against the additional func tests?17:17
peluse_clayg:  sorry, I mean in IRC, scroll up a few hrs17:18
peluse_but I'll go look and see if I had anything worth repeating in the review...17:18
peluse_clayg:  OK, Yuan had already addressed my earlier comments17:19
claygyeah i think his stuff was a solid start, thanks for reviewing it17:24
*** kevinc_ has quit IRC17:27
*** gyee has joined #openstack-swift17:36
*** bach has quit IRC17:40
*** byeager has joined #openstack-swift17:41
openstackgerritClay Gerrard proposed a change to openstack/swift: Fix cross policy versioning DELETE  https://review.openstack.org/9150317:47
*** kevinc_ has joined #openstack-swift17:48
*** byeager has quit IRC17:50
*** byeager has joined #openstack-swift17:57
*** cds has joined #openstack-swift17:58
cdsi just switched openstack controllers, is there an easy way to give my new controller (specifically glance) access to the containers in swift?17:58
notmynamecds: do you have an existing swift clusteR?17:59
cdsyes17:59
cdsi stood up a brand new controller with icehouse17:59
notmyname(I'm not sure what an "openstack controller" is)18:00
cdskeystone+glance+horizon18:00
*** shri1 has joined #openstack-swift18:00
cdsbasically, how can i transfer a container to a new swift user18:00
cdsmaybe that makes more sense18:00
notmynameI'd think that there aren't any changes required on the swift side of things. if you already had roles+ACLs set up to have swift working with glance, there should......ah, that's different I think18:01
*** shri1 has quit IRC18:01
notmynamesorry for the questions here, but "user" is a very overloaded term. what do you mean by "swift user"?18:01
*** bach has joined #openstack-swift18:02
cdsi suppose user = account in swift18:02
*** shri has quit IRC18:02
claygcds: so like did you setup a new service user for glance, like fresh keystone db or something?18:02
notmynameok (it could have also meant some end-user that gets keystone tokens or even the process owner)18:02
cdsclayg: yes18:03
cdsnew everything, however I am reusing all of the old passwords from the original controller18:03
clayghrmm.... you might have to like hack that users storage-url by hand?18:03
cdsthat is what it is looking like18:03
cdsjust curious if there is an easier way18:03
notmynamecds: swift should still be set up with the same data. eg all existing containers still have the same container ACLs.18:03
notmynameya, what clayg said :-)18:03
notmynamecan keystone explicitly set the storage URL when adding an entry to the service catalog?18:04
claygnotmyname: does glance really use container ACLs?  like I don't even know if the default behavior is to stuff everything into a service account or store images per user... I guess base images have to be in the service account18:04
notmynameor is it always set as some random uuid18:04
claygnotmyname: for all I know it's tied to the tenants uuid or something - it may not be it's own seperate field :\18:04
notmynameI don't know. I can imagine lots of ways it /could/ work18:05
cdsis there a simple way to list all accounts currently in swift?18:05
claygcds can keystone give you anything that will authenticate for the old data?  like idk, maybe with a superadmin/reseller admin token?18:05
*** byeager has quit IRC18:06
cdsi'm sure it could, but wouldn't the token expire eventually?18:06
*** byeager has joined #openstack-swift18:06
claygheh: for db in $(find /srv/node*/sd*/account* -name \*.db) ; do swift-account-info $db | grep "Account: "; done | sort -u18:06
claygcds well i just was wondering if you could get at the storage url of the old account - but I guess it wont' really matter until you what the data model looks like in keystone18:07
claygbut you could always just copy the data to the new glance services account too...18:07
cdsyeah18:07
cdssimple for one of my swift clusters18:08
cdsbut another has 50TB +18:08
claygcds you should probably ask in keystone if anyone knows anything about chaning the storage url of an existing user18:09
cdsgood idea.18:09
cdsthanks for the help guys :)18:09
notmynamekeystone devs lurk in #openstack-dev18:09
cdshave either of you tried 12.04 -> 14.04 with havana -> icehouse ?18:10
cdsfor glance+keystone+horizon18:10
cdsthat would solve my problem18:10
cdsonly reason i created this new controller was to hopefully migrate cleanly to 14.04 and icehouse18:11
cdsswift upgraded fine18:11
claygi have not spun up a trusty yet18:13
cdsi had the idea of spinning up a trust controller and migrating services incrementally, which hasn't worked very well18:13
cdsjust can risk my existing controller being down for extended periods18:13
cdstrusty*18:14
cdscant*18:14
acolescds: notmyname: clayg: i think when you add swift service to keystone there's some syntax to tell keystone to generate endpoint urls of form AUTH_tenantId18:16
notmynameacoles: I would trust your view on this more than my own :-) I think you use keystone more often that I do18:17
claygacoles: bollocks - so it sounds like chaging the storage url means changing the tenantId?  that's probably a terrible idea (or genious, dunno)18:17
cdscan you change a tenant id?18:17
cdsi guess i could in the sqldb18:17
acolescds: that i don't know, sorry. but sounds like the question you may need to ask keystone folks.18:18
claygcds: i'm guessing it's sorta denormalized across services in weird ways - but i if you could track down all the right references you might be able to pull it out18:18
acolescds: or can you specify an id when you create a tenant (in this case glance, if i understand the problem)18:19
cdsalright. and just to verify, a reseller admin user is *the* superuser on a swift cluster correct?18:19
acolesnotmyname: don't label me a keystone expert :)18:19
notmynamecds: from the perspective of swift, yes18:20
notmynameacoles: lol18:20
claygpeluse_: i'm waiting to hear back from yuan on some of the patches he's been working on - container sync looks pretty close, but i think it's missing a test.18:20
notmynamecds: to be more specific, the reseller admin has full read/write access to every swift account that is for that reseller (the reseller concept allows swift to use more than one auth system at the same time)18:21
notmynamecds: and funnily enough, I was just having a very similar conversation in a different channel18:21
acolescds: so maybe if you know the tenant_id of your old glance you can give your new glance reseller admin role and then point it at the url for the old glance tenant18:23
cdsthat is what i was thinking18:23
claygnotmyname: peluse_: have storage policies always had a "type"18:27
acolescds: remember to add the AUTH_ part in front of the old tenant id when constructing your url. Or whatever your reseller prefix is.18:28
notmynameclayg: I don't think so, but I'll defer to peluse_. I think that got added as peluse_ et al we're doing the EC stuff, and I think it doesn't do anything now18:28
claygoic, it was added so the replicator would know if it can process a storage directory or not...18:28
cdsacoles: is it possible to change the old url to reflect the new tenant ID>18:31
notmynamecds: no, the swift account name (ie the AUTH_XXX part) is used in the data placement in the swift cluster18:32
acolescds: not sure what you mean. change it where?18:32
cdsthe account name18:32
cdsnotmyname answered it18:32
cdswould syncing the containers between the accounts be an option?18:33
claygcds: i'd avoid a bit data migration util I'd cofirmed twiddling some fields in the db is not an option...18:35
cdsok18:35
cdsi'll work on it for a bit. thanks again for the help18:35
*** changbl has quit IRC18:36
claygbut yeah, a wholesale copy would definately square it - just gunna take a bit18:36
*** bach has quit IRC18:36
*** acoles is now known as acoles_away18:38
openstackgerritpaul luse proposed a change to openstack/swift: Add Storage Policy Support to Container Sync  https://review.openstack.org/8646918:46
peluse_clayg:  yes, I added when I added support (SP) for the replciator.  It needs it regardless of EC being introduced18:47
*** changbl has joined #openstack-swift18:50
zaitcevcds: look at http://people.redhat.com/zaitcev/tmp/keystone-setup.sh, it creates pre-set AUTH_x in Keystone.18:52
cdsawesome18:56
cdsthis is exactly what i needed18:56
notmynamezaitcev to the rescue18:58
*** bach has joined #openstack-swift19:13
openstackgerritClay Gerrard proposed a change to openstack/swift: cleanup policy parsing a bit more  https://review.openstack.org/8707819:13
claygpeluse_: ^ can you give that one a last over?  I'm looking at container sync - I think I can do a probetest for container sync (& cross policy)19:14
clayger... at least I think I can - container sync doesn't *have* to be cross realm right?  you can just go from one container to anotehr?19:15
*** kragniz has quit IRC19:18
clayggholt: does "A sync realm is a set of clusters that have agreed to allow container syncing with each other" mean that we don't expect a cluster in relam1 to be able to sync with realm2?19:21
peluse_clayg:  good question and sure I'll take a look at the parsing cleanup, about 40 min or so - have a call19:25
*** kragniz has joined #openstack-swift19:27
*** tzumainn has joined #openstack-swift19:28
tzumainnhi - would someone be able to answer some questions here about object versioning in swift?19:28
notmynametzumainn: ask away. and someone may be able to answer19:28
tzumainnnotmyname, okay, so. . .19:29
tzumainnif I understand correctly19:29
tzumainnto version an object in swift, you actually need two containers - one that always contains the latest version19:29
tzumainnand a versioning container that has copies of that object19:29
tzumainner, I mean the older versions of that object19:29
notmynamecorrect19:30
tzumainnthe older versions are prefixed19:30
tzumainnhow is that prefix determined?19:30
*** JayF has left #openstack-swift19:30
tzumainnand is the current version of the object also contained in the versioning container?19:31
notmynametzumainn: I'm not looking at the code, but IIRC, it's the length of the object name + a counter or timestamp + the object name. I should go look at the code19:31
*** tsg has joined #openstack-swift19:31
notmynametzumainn: no, the current version isn't in the versions container19:31
tzumainnnotmyname, okay, so - if we have a versioned object, and something like a heat template refers to the latest version of that object19:32
notmynameok19:32
tzumainnthat object could actually change, right?  or is there a way to say "always refer to this particular version, and not necessarily the latest"?19:33
notmynametzumainn: from http://docs.openstack.org/developer/swift/overview_object_versioning.html "The new object name (for the previous version) is <versions_container>/<length><object_name>/<timestamp>, where length is the 3-character zero-padded hexidecimal length of the <object_name> and <timestamp> is the timestamp of when the previous version was created."19:33
claygpeluse_: no it works, but i'm sitting here looking at this info dict and trying to decide which realm is acctually the same realm/cluster is the same as realm/cluster of my container :P19:33
tzumainnnotmyname, ah, ok, I read that page but completely missed that - thanks19:34
tzumainnso I guess my only question is about a heat template that refers to, say, the latest version of something in swift; is there a way to make sure it always points to that version, even if a newer version of the object is added?19:34
notmynametzumainn: no. in that case, you'd have to use a specific (static) object name19:35
notmynametzumainn: but that is possible (just not with versioned writes)19:36
tzumainnokay, so we could do it, just not with a versioned object?19:36
notmynametzumainn: you could write the stuff with a unique name and then create a manifest file referring to that one object. then request the object with the "friendly" name (eg cool_beans_latest.awesome) and update that as you add new versions. if you need a specific version, refer to it specifically19:37
notmynamewhere manifest == static large object manifest19:37
zaitcevInteresting. the API doc of 20140219 does not have a slash between the lengh-name and timestamp.19:38
tzumainnnotmyname, ah, okay, that makes sense - so essentially create our own versioning system using the manifest and static file names19:39
tzumainnthat makes sense19:39
tzumainnthat's all very helpful - thank you very much!19:39
notmynamecode says: prefix_len + self.object_name + '/' + new_ts19:40
notmynamehttp://shop.oreilly.com/product/0636920033288.do  <-- your very own Swift O-Reilly book (you can get it at the summit)19:42
physcxtrying to set up a swift-bench config file for a distributed swift-bench run and there isn't a good example for how to set the ip:port of the swift-bench-clients... anybody familiar with the tool know how to set multiple -b host:ip args in the config file?19:44
tzumainnnotmyname, nice, okay - I might pick one up there in atlanta then - thanks!19:44
notmynametzumainn: first 100 people in the swiftstack booth each day will get a free book19:44
tzumainnlol, really?19:45
notmynameyup. https://swiftstack.com/blog/2014/05/01/save-the-date-were-heading-to-atlanta-for-the-openstack-summit/19:46
notmynamephyscx: looking19:46
tzumainnawesome, I'll bring a tent and camp out19:46
*** shri has joined #openstack-swift19:48
*** lpabon has joined #openstack-swift19:49
*** zhiyan_ is now known as zhiyan19:49
zaitcevI got the original inknabula off of of Joe's minions which apparently never made it to the stores or even Amazon.19:50
zaitcevI red it through and sent him a list of some 190 corrections.19:50
notmynamephyscx: hmm...looking at the code (but not having run it) I'm not sure if that's possible. maybe only specified on the cmd line19:54
*** schofield has joined #openstack-swift19:55
swifterdarrellzaitcev: are you saying you'd like a copy of the book?19:56
*** schofield has quit IRC19:56
*** schofield has joined #openstack-swift19:57
zaitcevswifterdarrell: sure, we'll see if I can swing by19:57
zaitcevswifterdarrell: Are you going to do the booth babe duty?19:57
*** kevinc_ has quit IRC19:57
swifterdarrellzaitcev: i'm always doing babe duty, but I won't be going to the conference19:57
swifterdarrellzaitcev: however we really appreciate your help editing and I'm sure getting you a copy of the book won't be a problem :)19:58
*** kevinc_ has joined #openstack-swift19:59
physcxnotmyname: thx, just checked the python and yea it is setting conf.bench_clients = [] right after reading it so cmd line only i guess20:00
swifterdarrellphyscx: I added that feature, but never ended up using it much; I probably used it 100% via command-line20:01
*** schofield has left #openstack-swift20:04
physcxit is a nice little tool, just discovered today it can be used distributed20:06
portantephyscx: are you talking about ssbench?20:07
physcxswift-bench20:07
portanteah, k20:07
portanteokay, in-process func tests are now a gate/check job20:12
notmynameportante: voting?20:18
portantenot yet, that is the easiest way to debug it to make sure it is functioning correctly20:19
portanteonce it is passing for a bit, a healthy number of jobs (not sure what that is) they'll change it to voting20:19
portanteand yes, May 6th is Westford Town Elections, and I am planning on voting20:20
*** bach has quit IRC20:23
*** bach has joined #openstack-swift20:27
*** shri1 has joined #openstack-swift20:28
*** shri1 has quit IRC20:28
claygportante: aren't like... *real* functests already part of the gate?20:30
*** shri has quit IRC20:31
portanteclayg: yes, but if changes break the in-process func tests and don't break the regular func tests, then I think we want to know about it so that we can address it20:32
portanteso I was thinking that we'd want to know as soon as possible20:33
notmynameclayg: see, you shouldhave been at the swift meeting yesterday instead of those "customer" problems ;-)20:37
notmynamewhere we talked about devstack functests vs in-process func tests20:38
portanteclayg: the goal is to be sure in-process func tests are reliable enough that developers can use it to help write new func tests20:38
portantefor example, the swift-on-file team in Red Hat is taking on the task to work on increasing func test coverage based on this20:39
claygyeah looks like i did miss some stuff20:48
*** byeager has quit IRC20:53
*** byeager has joined #openstack-swift20:55
*** lpabon has quit IRC20:55
*** lpabon has joined #openstack-swift20:57
*** cds has quit IRC21:00
*** mwstorer has quit IRC21:02
*** bach_ has joined #openstack-swift21:12
*** bach_ has quit IRC21:12
*** bach_ has joined #openstack-swift21:13
*** lpabon has quit IRC21:15
*** bach has quit IRC21:15
*** bach_ has quit IRC21:24
*** zhiyan is now known as zhiyan_21:24
*** shri has joined #openstack-swift21:26
claygportante: ERROR: unknown environment 'pyfunc'21:26
portantehmm21:26
* portante runs over to that sandbox and looks21:27
*** changbl has quit IRC21:27
*** lpabon has joined #openstack-swift21:27
*** lpabon has quit IRC21:27
portanteclayg: job id?21:28
claygportante: what's a job id?  http://logs.openstack.org/78/87078/4/check/gate-swift-unittests-func/8ce760f/console.html21:29
openstackgerritClay Gerrard proposed a change to openstack/swift: Add probetest for container sync  https://review.openstack.org/9168521:29
portantehrumph21:33
portanterats, gonna have to see what the infra team wants to do here21:37
*** changbl has joined #openstack-swift21:48
*** joeljwright has quit IRC22:05
*** bach has joined #openstack-swift22:07
*** bach has quit IRC22:07
*** bach has joined #openstack-swift22:08
gholtclayg: re: the sync realms question: yes, each realm is its own shared grouping. For instance, Rackspace will have a realm for its clusters and maybe add an additional realm to share with SwiftStack or ... Perhaps that realm wouldn't include all Rackspace clusters due to bandwidth concerns or whatever reason. Also, I am not and cannot make any such commitments, just examples. ;)22:11
*** changbl has quit IRC22:19
*** mmcardle has joined #openstack-swift22:24
*** mmcardle has quit IRC22:28
*** bach has quit IRC22:34
*** joeljwright has joined #openstack-swift22:47
*** rahmu has left #openstack-swift22:48
*** byeager has quit IRC22:57
*** joeljwright has quit IRC23:00
openstackgerritpaul luse proposed a change to openstack/swift: cleanup policy parsing a bit more  https://review.openstack.org/8707823:04
peluse_clayg:  ^ looks fantastic.  made a few minor tweaks to get unit coverage up to 100%23:05
*** Midnightmyth has quit IRC23:06
*** shakamunyi has joined #openstack-swift23:42
*** joeljwright has joined #openstack-swift23:57
*** kevinc_ has quit IRC23:58

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