Monday, 2016-11-07

*** vint_bra has quit IRC00:33
*** sams-gleb has joined #openstack-swift00:51
zhengyinmattoliverau:morning01:23
*** sams-gleb has quit IRC01:23
mattoliverauzhengyin: morning01:26
kota_morning01:31
kota_clayg: i didn't yet file it but just thinking do today :P01:32
kota_notmyname: thanks for adding pyeclib/liberasurecode to swift review dashboard which is very useful.01:32
*** david_c_ has joined #openstack-swift02:00
*** sams-gleb has joined #openstack-swift02:21
*** trananhkma has joined #openstack-swift02:27
*** takashi has joined #openstack-swift02:52
*** sams-gleb has quit IRC02:54
*** bkopilov has quit IRC02:57
mahaticgood morning!03:42
*** sams-gleb has joined #openstack-swift03:52
*** links has joined #openstack-swift03:55
*** trananhkma has quit IRC03:57
*** winggundamth has quit IRC04:03
*** trananhkma has joined #openstack-swift04:15
*** bkopilov has joined #openstack-swift04:17
*** sams-gleb has quit IRC04:24
*** chlong has joined #openstack-swift04:47
kota_mahatic: good morning!04:50
openstackgerritCharles Hsu proposed openstack/python-swiftclient: Add additional headers for HEAD/GET/DELETE requests.  https://review.openstack.org/37265605:18
*** Jeffrey4l has joined #openstack-swift05:21
*** sams-gleb has joined #openstack-swift05:21
openstackgerritMerged openstack/liberasurecode: Fix clang compile time error  https://review.openstack.org/32408305:27
*** SkyRocknRoll has joined #openstack-swift05:39
*** sams-gleb has quit IRC05:54
*** rcernin has joined #openstack-swift06:03
*** sams-gleb has joined #openstack-swift06:51
*** tesseract has joined #openstack-swift07:06
*** tesseract is now known as Guest7131007:06
*** ChubYann has quit IRC07:16
*** pcaruana has joined #openstack-swift07:17
*** Jeffrey4l has quit IRC07:18
*** sams-gleb has quit IRC07:24
*** two_tired has quit IRC07:25
*** sams-gleb has joined #openstack-swift07:36
*** hseipp has joined #openstack-swift07:59
*** klrmn has quit IRC08:05
*** Jeffrey4l has joined #openstack-swift08:17
*** rledisez has joined #openstack-swift08:26
*** amoralej|off is now known as amoralej08:41
*** chlong has quit IRC08:41
-openstackstatus- NOTICE: Gerrit is going to be restarted due to slowness and proxy errors08:47
*** openstackgerrit has quit IRC08:48
*** openstackgerrit has joined #openstack-swift08:48
*** winggundamth has joined #openstack-swift09:32
*** sams-gleb has quit IRC10:02
*** sams-gleb has joined #openstack-swift10:03
*** asettle has joined #openstack-swift10:05
*** sams-gleb has quit IRC10:06
*** sams-gleb has joined #openstack-swift10:06
*** rickflare has quit IRC10:07
*** sureshj has joined #openstack-swift10:09
sureshjhii all i am uploading 3 objects of size 5.1GB with segment size 512MB at a time10:09
sureshjbut all of them are failed with 503 service unavialable10:10
*** sams-gleb has quit IRC10:10
sureshjplese someone help on this10:10
*** sams-gleb has joined #openstack-swift10:10
*** sams-gleb has quit IRC10:10
*** asettle has quit IRC10:11
*** asettle has joined #openstack-swift10:11
*** rickflare has joined #openstack-swift10:11
*** acoles_ is now known as acoles10:12
acolessureshj: take a look in your proxy logs for any error messages container string "returning 503", they may give some hint as to what is happening - could be backend connection timeouts10:42
sureshjacoles: here is some part of  my log http://paste.openstack.org/show/588230/10:44
cschwedeHello everyone!10:51
cschwedeacoles: i’m looking into the pyeclib testing in the gate we discussed in Barcelona10:52
cschwedeacoles: but i’m no longer sure what is really missing here? at the end of the day we need a job to run probetests, right?10:53
acolescschwede: remind me what the discussion was? (I remember discussing upgrade tests and tiering tests and the need for multi-policy func tests)10:57
acolescschwede: did we discuss running swift tests in gate for pyeclib???10:58
cschwedeacoles: we discussed running EC probetests on the gate with John, but looking into the current gate setup it either looks much more simple to me as it sounded in Barcelona or I am missing something10:58
acolescschwede: oic. hmmm, TBH  I have never looked into why we do not run probe tests in gate, I just assumed there was a good reason that we could not.11:01
acolesprobe tests make assumptions about the SAIO deployment11:01
acoleslike tempauth is required IIRD, but devstack has that11:01
cschwedeacoles: well, there is one. it requires more resources, because we need more than 1 replica11:01
acolescschwede: does devstack use a single replica policy?11:02
cschwedeacoles: yes, but one can override this, and use 3 for example to rest replication11:03
cschwedeacoles: and my assumption is that we can simply increase that for EC, modify the swift.conf and run these tests11:03
cschwedethere are already tests for pyeclib itself, for example: https://review.openstack.org/#/c/390149/11:04
patchbotpatch 390149 - pyeclib - Remove Ryuta Kon from NTT shss reference (MERGED)11:04
cschwede(last patch on master branch)11:04
cschwedeacoles: anyhow - i will continue testing on devstack how to enable EC probetests on the gate. i’ll ping you again soon ;)11:05
acolescschwede: so currently we have no gate *functional* test using EC policy, that would be a good addition. I had thought it could be achieved with the in-process framework by adding an EC policy to that.11:06
acolesIDK about probe tests in the gate, if it can happen then great!11:07
cschwedehmm, looking into that oo11:07
cschwedes/oo/too11:07
acolessureshj: your logs are showing that the backend PUT requests are timing out after 10 secs - you could try increasing the timeout value (node_timeout in proxy-server section of proxy-server.conf)11:10
openstackgerritAlistair Coles proposed openstack/swift: Unset random seed after rebalancing ring  https://review.openstack.org/37156411:11
*** sams-gleb has joined #openstack-swift11:16
*** chlong has joined #openstack-swift11:16
*** sams-gleb has quit IRC11:45
*** zhengyin has quit IRC11:45
*** silor has joined #openstack-swift12:02
*** tdasilva has quit IRC12:06
*** tdasilva has joined #openstack-swift12:16
*** bkopilov has quit IRC12:21
*** kei_yama has quit IRC12:27
*** SkyRocknRoll has quit IRC12:28
*** rcernin has quit IRC12:43
*** rcernin has joined #openstack-swift12:44
*** sams-gleb has joined #openstack-swift12:44
timssHi. Does the containers/objects created with swift-dispersion-populate use any significant amount of disk space? Is the dispersion_coverage just about partition coverage, or can it grow out of control if there's many partitions?12:54
*** takashi has quit IRC13:00
*** jordanP has joined #openstack-swift13:07
*** amoralej is now known as amoralej|lunch13:11
*** sams-gleb has quit IRC13:15
*** adb5a56 has quit IRC13:17
*** vint_bra has joined #openstack-swift13:38
*** mvk has quit IRC13:38
*** links has quit IRC13:40
*** bkopilov has joined #openstack-swift13:52
*** amoralej|lunch is now known as amoralej13:53
*** Guest71310 has quit IRC13:58
*** klamath has joined #openstack-swift14:01
*** klamath has quit IRC14:01
*** klamath has joined #openstack-swift14:01
*** mvk has joined #openstack-swift14:11
*** Guest71310 has joined #openstack-swift14:12
*** sams-gleb has joined #openstack-swift14:14
*** Guest71310 has quit IRC14:18
*** tesseract has joined #openstack-swift14:19
*** tesseract is now known as Guest4111714:19
*** Guest41117 has quit IRC14:22
*** _JZ_ has joined #openstack-swift14:27
*** tesseract- has joined #openstack-swift14:27
*** thurloat has joined #openstack-swift14:31
*** chlong has quit IRC14:34
*** rvasilets___ has joined #openstack-swift14:45
*** sams-gleb has quit IRC14:46
*** mvk has quit IRC15:02
*** sams-gleb has joined #openstack-swift15:04
*** tuan_luong has joined #openstack-swift15:12
*** geaaru has joined #openstack-swift15:14
*** StraubTW has joined #openstack-swift15:16
openstackgerritMathias Bjoerkqvist proposed openstack/swift: WIP: Storing encryption root secret in Barbican  https://review.openstack.org/36487815:17
*** sgundur has joined #openstack-swift15:17
*** mvk has joined #openstack-swift15:18
openstackgerritNandini Tata proposed openstack/swift: Allow custom swift configuration directory  https://review.openstack.org/39395215:24
*** Renich has joined #openstack-swift15:29
*** Renich has quit IRC15:31
*** links has joined #openstack-swift15:34
tdasilvado we have documented anywhere all the environment variables that could be set for swift and swift dev?15:35
tdasilvantata: ^ maybe you know this...15:36
*** serverascode has quit IRC15:41
*** kmARC has quit IRC15:41
*** kmARC has joined #openstack-swift15:42
*** sgundur has quit IRC15:42
*** cppforlife_ has quit IRC15:42
*** cargonza has quit IRC15:42
*** kozhukalov has quit IRC15:42
*** amit213 has quit IRC15:42
*** zhiyan has quit IRC15:42
*** raginbaj- is now known as raginbajin15:42
*** philipw has quit IRC15:43
*** madorn has quit IRC15:43
*** rsFF has quit IRC15:43
*** fungi has quit IRC15:43
*** zacksh has quit IRC15:43
*** zacksh has joined #openstack-swift15:44
*** zhiyan has joined #openstack-swift15:45
*** cppforlife_ has joined #openstack-swift15:46
openstackgerritMerged openstack/swift: update urls to newton  https://review.openstack.org/38819615:46
*** cargonza has joined #openstack-swift15:46
*** amit213 has joined #openstack-swift15:47
*** kozhukalov has joined #openstack-swift15:48
*** serverascode has joined #openstack-swift15:48
*** rsFF has joined #openstack-swift15:52
*** sgundur has joined #openstack-swift15:54
*** rcernin has quit IRC15:55
*** philipw has joined #openstack-swift15:55
*** fungi has joined #openstack-swift15:55
*** Renich has joined #openstack-swift15:56
*** madorn has joined #openstack-swift15:56
*** tuan_luong has quit IRC15:58
*** sgundur has quit IRC16:01
*** pcaruana has quit IRC16:12
*** david_c_ has quit IRC16:15
*** klrmn has joined #openstack-swift16:17
*** stradling has joined #openstack-swift16:28
*** tesseract- has quit IRC16:31
*** david_c_ has joined #openstack-swift16:34
*** sgundur has joined #openstack-swift16:36
*** sgundur has quit IRC16:38
*** sgundur has joined #openstack-swift16:39
ntatatdasilva, good question. Well, I couldn't find anything that talks about all the possible environment variables at a single place16:47
tdasilvantata: yeah, i was just wondering, it would probably be helpful to do that at some point16:52
ntatatdasilva, agree, I can pool them together (to deployment guide maybe?) unless you're planning to..16:55
*** diogogmt has joined #openstack-swift17:02
tdasilvantata: feel free to go ahead17:05
*** klrmn has quit IRC17:07
*** Renich has quit IRC17:10
*** mvk has quit IRC17:10
*** arch-nemesis has joined #openstack-swift17:19
*** links has quit IRC17:20
*** hseipp has quit IRC17:21
notmynamegood morning17:22
notmynamewell this is interesting http://lists.openstack.org/pipermail/openstack-dev/2016-November/106877.html17:22
notmynameI haven't read the referenced blog post yet17:22
*** mvk has joined #openstack-swift17:22
claygyay mondays!17:23
*** amoralej is now known as amoralej|off17:30
*** diogogmt has quit IRC17:33
*** asettle has quit IRC17:33
notmynamewell, while I'm piling on the mondays, there's this too https://review.openstack.org/#/c/365590/17:34
patchbotpatch 365590 - governance - Add "Assume Good Faith" to OpenStack principles17:34
*** cbartz has joined #openstack-swift17:34
*** ukaynar has joined #openstack-swift17:37
*** ukaynar has quit IRC17:38
*** jordanP has quit IRC17:39
*** diogogmt has joined #openstack-swift17:43
openstackgerritDonagh McCabe proposed openstack/swift: Document access control lists (ACLs)  https://review.openstack.org/37421517:43
*** rledisez has quit IRC17:45
*** cbartz has left #openstack-swift17:45
tdasilvanotmyname: i read the blog post and i think it seems sensible, i couldn't point out anything that's necessary wrong the the ideas (principles), just not sure I agree with some of the specifics...17:46
notmynametdasilva: yeah, the "team asking for golang must first create goslo.{config,messaging,db} and auth" seems ... well, I'm not sure what ;-)17:47
tdasilvanotmyname: yeah, i think asking 'us' to help contribute to common code is sensible, defining what that common code is will be the challenge17:48
notmynametdasilva: in our specific case, most of those don't make sense. config might, but the requirement (no different in python) is that existing configs must continue to work17:49
tdasilvanotmyname: agree...honestly, top of my head i can only think of config and logging which is not even on his list17:50
tdasilvai'm not sure authentication makes sense at the moment as we are not proposing changes to user facing services, but maybe other services have authentication in the backend services??? i have no idea17:51
notmynamecould be. same with db and messaging, too17:51
openstackgerritChristian Hugo proposed openstack/swift: Use direct_get_suffix_hashes in the reconstructor  https://review.openstack.org/39455117:52
*** cdelatte has joined #openstack-swift17:54
*** dmorita has joined #openstack-swift18:00
*** stradling has quit IRC18:01
*** klrmn has joined #openstack-swift18:02
*** mvk has quit IRC18:02
*** stradling has joined #openstack-swift18:03
*** sgundur has quit IRC18:15
*** sgundur has joined #openstack-swift18:22
*** ChubYann has joined #openstack-swift18:23
*** rvasilets___ has quit IRC18:28
claygi can't get half way through a sentence without having to delete it - and I'm normally pretty lippy18:35
openstackgerritMerged openstack/swift: Fix signal handling for daemons with InternalClient  https://review.openstack.org/25934718:36
openstackgerritChristian Hugo proposed openstack/swift: object-replicator cleanup  https://review.openstack.org/39161718:46
openstackgerritChristian Hugo proposed openstack/swift: Use direct_get_suffix_hashes in the reconstructor  https://review.openstack.org/39455118:46
openstackgerritOpenStack Proposal Bot proposed openstack/swift: Updated from global requirements  https://review.openstack.org/8873618:48
*** stradling has quit IRC19:00
*** stradling has joined #openstack-swift19:02
*** geaaru has quit IRC19:02
openstackgerritChristian Hugo proposed openstack/swift: Use direct_get_suffix_hashes in the reconstructor  https://review.openstack.org/39455119:23
*** sgundur has quit IRC19:28
*** d0ugal has quit IRC19:30
*** d0ugal has joined #openstack-swift19:31
*** d0ugal has quit IRC19:31
*** d0ugal has joined #openstack-swift19:31
claygjrichli: nice response on lp bug #131909619:32
openstackLaunchpad bug 1319096 in OpenStack Object Storage (swift) "Include object metadata in container list" [Undecided,In progress] https://launchpad.net/bugs/131909619:32
*** sgundur has joined #openstack-swift19:32
jrichliclayg: I looked for a nick that might match Christian Hugo to see if we could chat here, but no luck.19:33
jrichliI see he has uploaded a few different patches lately19:34
claygjrichli: yeah!  would love to see him get more engaged!  ... see if there's anything we can do to help/support?19:36
openstackgerritOndřej Nový proposed openstack/swift: object-replicator cleanup  https://review.openstack.org/39161719:36
*** sgundur has quit IRC19:40
*** sgundur has joined #openstack-swift19:40
*** acoles is now known as acoles_19:50
notmynamefungi: torgomatic: tdasilva: patch 394600 and patch 394601 set up a testing environment that allows for checking xattrs in swift's tests, thus enabling patch 336323 to land (I think)19:53
patchbothttps://review.openstack.org/#/c/394600/ - openstack-infra/project-config - enable xfs for swift in-process functests19:53
patchbothttps://review.openstack.org/#/c/394601/ - openstack-infra/project-config - add python-jobs-with-xfs for swift19:53
patchbothttps://review.openstack.org/#/c/336323/ - swift - Add checksum to object extended attributes19:53
notmynamefungi: I'd definitely appreciate your insight on the 2 infra patches19:53
notmynameI spearated them to make it more clear about the 2 things I'm doing, but i'm happy to combine if that's what you'd prefer19:53
funginotmyname: yep, saw 394601 and its parent scroll by in the infra channel and already have them pulled up19:53
notmynamethanks :-)19:54
fungii'll look closer once the jobs report back on them in a few minutes19:54
*** sgundur has quit IRC19:57
*** sgundur has joined #openstack-swift19:57
*** Renich has joined #openstack-swift20:00
*** silor has quit IRC20:00
claygtimburke: I'm on vbox -> 5.0.14r105127 and vagrant -> 1.8.4.120:03
claygobvs no problems mounting file systems - could totally be a guest agent thing tho - i'd be happy to upgrade if you're on newer-er versions and see i can duplicate your pain20:04
timburkeclayg: hmm... i *am* on newer, though when i first hit trouble, i was on older (at least for vbox)20:05
timburkecurrently on 5.0.28 & 1.8.5.320:05
timburkebut the USERNAME tip got me off & running on trusty, so w/e20:05
notmynamefungi: ah, I'm guessing the errors are from the consolidation I did to https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L14043-L1405520:09
claygtimburke: but xenial is *so* much better!20:09
notmynamefungi: I don't see why those need to be different sections (one with trusty+xenial and one with just xenial).20:09
notmynamefungi: from git history, it seems that they got split as part of some trusty->xenial migration in infra. certainly not intended to only work in one or the other from the swift perspective20:10
timburkeclayg: eh, may as well be on a platform that my customers might actually be using20:10
timburke(i should really look into adding centos support for vsaio...)20:10
notmynamefungi: but I'll admit to not really understanding all the layout. fwiw, the error is at http://logs.openstack.org/00/394600/1/check/gate-project-config-layout/65bcf33/console.html#_2016-11-07_19_57_01_19048520:12
notmynameoh! because layout.yaml doesn't reference the new name! (I think)20:12
funginotmyname: sorry, had to step afk for a moment but i'm taking a look now20:15
claygtimburke: yes20:17
claygtimburke: however, there was *some* reason I needed to move to xenial?  some skip tests if you have an old kernel maybe?20:17
notmynamefungi: pushed new revisions20:18
claygtimburke: I think it was honestly because the haproxy that comes with precise can't do ssl termination and I wanted to play with the proxy protocol stuff for the ip address handling patch/story?20:18
funginotmyname: the error i see there is "jenkins_jobs.errors.JenkinsJobsException: Duplicate definitions for job 'swift-branch-tarball' specified" which i think is because you have the python-jobs and python-jobs-with-xfs-tmp job-groups instantiated on swift in jenkins/jobs/projects.yaml, and each of those job groups defines some of the same jobs20:18
notmynamefungi: oh? can't reference the same job names in 2 different job groups?20:18
funginotmyname: if the plan is to use both those job-groups together, you probably just need to have gate-{name}-python27-xfs-tmp-{node} and gate-{name}-python34-xfs-tmp in the python-jobs-with-xfs-tmp group20:19
timburkedammit! that was on my shortlist of things to go +A, just as soon as i could get around to func testing it...20:19
notmynamefungi: that doesn't seem to align with python-db-jobs20:20
funginotmyname: yeah, in this case it's that jjb isn't smart enough to know that you're instantiating, say, {name}-branch-tarball twice with the same set of parameters (if it were smarter it might learn to dedupe those). instead it worries that you're instantiating templates that result in jobs with identical names (which as far as it knows might be different jobs)20:20
notmynamefungi: ...which seems to be a copy of python-jobs but with a couple of names changed20:20
claygtimburke: you're going to need xenial20:20
clayg:P20:21
notmynamefungi: oh, do you prefer these to be one commit or the 2 separate ones I've proposeD?20:21
claygoh... wait - were you talking about the proxy protocl patch or the other xfs-gate thing20:21
timburkeclayg: the PROXY proto patch20:22
claygtimburke: ah20:22
funginotmyname: right, the projects which use the python-db-jobs group don't use the normal python-jobs group. honestly that's probably an oversight and they should use both but factor out the jobs common between them (so that nova can't accidentally make it impossible to run their tox env without mysql and postgres both installed)20:23
fungii'll write that up as a separate change20:23
notmynamefungi: TBH, I'd be totally ok with not running the normal python-jobs group and running this one instead, but I've been given the impression that wouldn't fly with the TC and the common testing interface (or "swift being different")20:24
funginotmyname: yep, i'm writing this one up for parity with the swift change. either they're both needed or neither is but i definitely want a level playing field here whichever way things go20:25
notmynamefungi: ok. I'll change mine to just have the two xfs jobs in the -with-xfs-tmp group20:25
notmynamefungi: but do you want me to keep my 2 patches or squash them together?20:26
*** d0ugal has quit IRC20:26
*** dfisher has joined #openstack-swift20:26
*** sgundur has quit IRC20:27
*** d0ugal has joined #openstack-swift20:27
*** d0ugal has quit IRC20:27
*** d0ugal has joined #openstack-swift20:27
openstackgerritTim Burke proposed openstack/swift: Always set swift processes to use UTC  https://review.openstack.org/33136920:27
funginotmyname: i'm not opposed to keeping them separate changes. probably slightly easier to review this way20:28
fungii see 394600 failed (different) tests. i was looking at the error on 39460120:29
fungiand yeah, it looks like the job failure on 394600 is due to needing to also update the gate-swift-tox-bandit-ubuntu-(trusty|xenial) regex in zuul/layout.yaml20:30
*** sams-gleb has quit IRC20:31
notmynamefungi: ok, thanks. new version pushed20:32
*** sams-gleb has joined #openstack-swift20:32
*** sams-gleb has quit IRC20:36
mattoliverauMorning20:41
funginotmyname: for reference, here's my first attempt at the strawman for making sure all projects using custom db setup in unit tests are also tested without: https://review.openstack.org/39462020:48
patchbotpatch 394620 - openstack-infra/project-config - Make sure opportunistic DB use in unit tests works20:48
fungii agree that's basically the same case as expecting someone to make an xfs filesystem available when running unit tests20:48
funginotmyname: it still doesn't look like 394600 patchset 3 updated the gate-swift-tox-bandit-ubuntu-(trusty|xenial) regex in zuul/layout.yaml20:58
*** sgundur has joined #openstack-swift21:09
jrichlitimburke: I just glanced at patch 331369 and am wondering what the impacts are.  Is this change visible to the user?21:12
patchbothttps://review.openstack.org/#/c/331369/ - swift - Always set swift processes to use UTC21:12
*** clu_ has joined #openstack-swift21:14
*** abalfour has joined #openstack-swift21:15
*** jamielennox is now known as jamielennox|away21:19
abalfourSo... I could use some advice. It appers that the swift ring files are architecture dependent. I.e. if you use swift-ring-builder to create a ring file on an little endian machine, and then copy that ring file to a big endian machine, you're going to have a bad time. For example: http://paste.openstack.org/show/588317/21:24
abalfourThe obvious problem being on the endianess the file wasn't built on, the device index of 256 isn't going to work for indexing into the r2p2d array... Should we be creating the ring files locally on each architecture, or should the file format be endinan agnostic?21:26
*** sgundur has quit IRC21:29
*** vint_bra has quit IRC21:32
*** sams-gleb has joined #openstack-swift21:34
*** Jeffrey4l has quit IRC21:35
*** stradling has quit IRC21:46
pdardeauabalfour: ouch! i don't have a BE environment to verify, but you might try hacking https://github.com/openstack/swift/blob/master/swift/common/ring/ring.py#L7621:48
pdardeaumaybe change 'H' to '!H'21:49
pdardeauabalfour: it's possible it might be written to file ok, and then converted improperly on BE load21:49
dfisherabalfour had to step away.  here's another possible solution http://paste.openstack.org/show/588319/21:52
claygabalfour: I did not know that!21:53
dfisheri don't really grok array/struct python objects to comment on 'H' vs '!H'21:53
notmynameinteresting21:53
pdardeaudfisher: https://docs.python.org/2/library/struct.html#byte-order-size-and-alignment21:53
timburkejrichli: ideally, not really. the trouble i was running into was that some middleware would try to parse some user-provided timestamp with our stdlib in a crazy split-brain, so the result would be hours off. this lead to some authz errors in swift3 (which i suppose is user-visible), but to my knowledge we always report timestamps in UTC anyway21:54
claygcan i make a vm with backwards default platform bits?  and why would python even allow me to serialize in a platform dependent way.21:54
pdardeauthe table in 7.3.2.1 shows the architecture specific modifiers21:54
pdardeauand table in 7.3.2.2 shows data types21:54
claygthat's so annoying21:55
notmynamefungi: thanks. back from lunch, and I'm looking now21:55
*** sgundur has joined #openstack-swift21:55
dfisherwell, i can certainly try to hammer the '!H' in and see what happens21:56
timburkehuh. i find it a little disconcerting that there's no reference to endianness in https://docs.python.org/2/library/array.html21:58
timburkefor that matter, "!H" isn't referenced either :-(21:59
*** jamielennox|away is now known as jamielennox22:02
jrichlitimburke: re: timestamps - which user-provided timestamp?  i guess that it wasn't a Unix Epoch timestamp?22:04
timburkejrichli: peak at the... third related change. we were parsing a user-provided header (either x-amz-date or, if that wasn't present, Date)22:06
*** sams-gleb has quit IRC22:07
jrichliok, thx22:07
pdardeautimburke: dfisher: and just because '!H' works for struct packing/unpacking doesn't mean it's valid for array :/22:12
dfisherstill poking at it.  results in a sec...22:12
notmynamefungi: https://review.openstack.org/#/c/394600/ and https://review.openstack.org/#/c/394601/ have passed the checks!22:13
patchbotpatch 394600 - openstack-infra/project-config - enable xfs for swift in-process functests22:13
patchbotpatch 394601 - openstack-infra/project-config - add python-jobs-with-xfs for swift22:13
notmynamefungi: is there any way to run swift through those without having them land in infra first?22:17
timburkehmm. i guess we need to make a call to byteswap()? looks like array.array wants a character, not a string22:28
*** mvk has joined #openstack-swift22:29
dfisheryeah, changing to !H didn't seem to make a difference22:31
dfishersparc:   'replica2part2dev_id': [array('H', [0, 0, 256, 256, 0, 256,22:31
dfisherx86:  'replica2part2dev_id': [array('H', [0, 0, 1, 1, 0, 1, 1, 0,22:31
patchbotError: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.22:31
patchbotError: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.22:31
dfisher^ ha22:31
notmynamedfisher: someday I'll rewrite patchbot to be smarter22:32
dfisherseems pretty smart to me.22:32
dfishersmarter than I am, anyway :)22:33
jrichlipor patchbot gets no luv :-(22:33
dfishertimburke: my paste.openstack.org has the byteswap() patch in it.  http://paste.openstack.org/show/588319/22:35
pdardeau&patchbot-not-so-fussy; don't freak out about my non-matching [22:36
patchbotError: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.22:36
funginotmyname: you could run the script from mount-tmp-with-xfs before running `tox -e py27`22:40
torgomaticnotmyname: what if you made the xattrs patch depend on those infra ones? I'm totally guessing here; I have no idea how any of that works.22:40
torgomaticI mean, I know some things... but "will a pending job-specifier patch get used if it's a dependency of a Swift patch" is not anywhere in there22:41
funginotmyname: my main concern with this is that if our underlying job infrastructure relies on files places in /tmp prior to starting the job payload, it could get confused once it can no longer find them later. i'll try to find out if that will pose a problem22:41
notmynamefungi: yeah, that seems like a totally reasonable concern. TBH I was a little surprised linux let me do it :-)22:42
claygtimburke: wow so https://github.com/eventlet/eventlet/pull/354 is acctaully pretty epic22:51
timburkewas it? idk. i had a much worse time with that UTC/stdlib-doesn't-know-what-timezone-it's-in thing22:53
claygtimburke: first learning for me was that eventlet has some dynamic patching of stuff like getaddrinfo if you have dnspython installed -> oh crap or at least it *used* to (!?) https://github.com/eventlet/eventlet/blob/4872be77001bde7b393f8973779a15c65ce36086/eventlet/green/socket.py#L2222:53
claygnow it just bundles dnspython!?22:53
timburkeclayg: you're welcome? https://github.com/eventlet/eventlet/pull/34122:55
claygtimburke: second learning for me at least is that dnspython compleatly reimplements stuff like getaddrinfo - which is like... glibc stuff22:55
claygprobably just a sign that I need to do better reading the eventlet change lots22:58
clayg*changelogs22:58
*** sgundur has quit IRC23:00
dfisherso, here's a random question that i've wondered about for awhile … why does swift use rsync to keep data nodes updated instead of something like libtorrent?23:03
*** sams-gleb has joined #openstack-swift23:04
claygdfisher: i'm not really sure there's a direct comparison to be made between the rsync client/server and the torrent *library* - rsync was choosen as the basis for data movement back in ~09 because it was broadly comfortable for the devops that would be running cloud files - always assuming it would be replaced when needed23:10
* dfisher nods23:11
claygdfisher: and in fact SSYNC and now REPCON (hummingbird) are going down that path23:11
dfishercool23:11
dfisher just figured that the idea of torrents for data would be more efficient than rsync, especially as more storage nodes are brought online23:12
claygdfisher: FWIW no one then or now really likes the rsync *protocol* - but since swift only moves whole files i'm not sure it matters that much23:12
claygdfisher: but both SSYNC and REPCONN are still following the same basic "push" model that the rsync replicators employ23:12
claygdfisher: I'm not sure anyone has experiemented much to determine if an entire partition could be "pulled" from multiple replica peers in some fashsion that'd be more "efficient" along an axis where there's a need to optomise23:13
dfishersure.  there's probably an inflection point where if you < X nodes, rsync is probably as good if not better than a torrent-esque solution (ignoring things like network speeds for now)23:14
dfisherif you have* < X nodes23:14
claygdfisher: mostly you just have three primary nodes - the "swarm" effect (lots of hosts/nics/disks all "participating" in the filling of new capacity) mostly comes from the placement algorightm and doing a good job managing incoming streams23:15
claygdfisher: yeah I suppose if your cluster had an asymmetric link it would become more important for all three replicas of a partition to some how "coordinate" to push subsets of the partition during a rebalance if you don't want to way for a 1:1 push of each part - but again since you're taking 100-1000-10K's of parts onto a single node - you can normally mostly overwhelm whatever resource you're aiming to overwhelm pretty easil23:18
*** abalfour1 has joined #openstack-swift23:18
*** dfflanders has joined #openstack-swift23:20
clayga big part of what the hummingbird replicator is trying to tackle is reducing disk reads that are only tanginially related to the transfer of data during rebalance23:20
abalfour1sorry, had to run to get eyeballs checked. so it appears the general consensus is that the ring file should be endian agnostic, correct? so I should file a bug?23:22
notmynameabalfour1: yes you should file a bug so that we can track it. but I'm not sure that the resolution is to make the ring byte-order agnostic23:24
claygabalfour1: yeah I think it's a bug - how critical is this for you?23:24
abalfour1well, I have a horrible hack fix that I think dfisher pasted in here. So I can get it to work for me now. :)23:24
*** StraubTW has quit IRC23:24
claygabalfour1: oh that worked!?23:24
abalfour1the byteswap(), yep.23:25
claygoh...23:25
notmyname(eg the resolution might be "don't do that" and document and print warnings about building a ring on a different architecture than prod machines)23:25
abalfour1it's just the check to see if we need to do the byteswap() is gross.23:25
abalfour1both archiretcures are prod, btw.23:25
abalfour1we have a swift cluster with x86 and sparc nodes.23:26
abalfour1we figured we get cute and pregenerate the ring files and have puppet plop them on all the nodes.23:26
abalfour1and it failed in humerous ways. :)23:27
claygabalfour1: that's really awesome23:28
abalfour1thanks.23:28
notmynamehmm...if you build the ring on each architecture with the same seed value, it would give the same effective results. but md5 checks would be different23:28
abalfour1correct23:28
notmyname(right?)23:28
claygabalfour1: can something in sys. tell us the byte of the machine?23:28
abalfour1sys.byteorder23:28
abalfour1but, we can't tell what byteorder the file was generated with, I don't think.23:29
claygabalfour1: I would be fine with the ring file growing a field to say which one it is is - and on load it byteswaps based on != my.byteorder23:29
abalfour1oh, cool.23:29
notmynameclayg: yeah, that's it23:29
clayggreat all over but the typing23:29
abalfour1ok, I'll file the bug, code it up and submit the patch.23:29
abalfour1thanks for looking at it!23:29
claygabalfour1: NICE!23:29
notmynameclayg right now: https://i.imgflip.com/kzxw3.jpg23:30
notmynameabalfour1: thanks :-)23:30
abalfour1now that's just mean. :)23:30
dfisherabalfour as management is a *terrifying* thought23:30
claygvirtualbox is shit - i bet vmware player or whatever the kids use can toally make a big endian sparc cpu23:31
dfisheri've worked with him for 13 years now.  that's the last thing ANYBODY wants.23:31
*** Jeffrey4l has joined #openstack-swift23:31
dfisherclayg:  ebay a T2000 + solaris 11.3 ;)23:31
notmynameclayg: what's funny is that the same company that makes virtualbox also owns sparc ;-)23:31
claygabalfour1: forgive notmyname - he sorta "is" upper management - he doesn't realize it's mostly insulting to the rest of us23:31
notmynamelol23:31
dfishersorry, abalfour and I work for Sun.23:32
claygnotmyname: ;)23:32
claygrofl23:32
* dfisher sobs quietly23:32
claygthis is #$%^&ing rich - open source is fun23:32
notmyname"sun"23:32
dfishermy badge says Sun.23:32
* dfisher continues to sob23:32
*** cdelatte has quit IRC23:33
*** sams-gleb has quit IRC23:37
*** kei_yama has joined #openstack-swift23:41
*** Renich_ has joined #openstack-swift23:44
openstackgerritMerged openstack/swift: EC: reconstruct using non-durable fragments  https://review.openstack.org/37663023:45
notmynametorgomatic: tdasilva: just remounting /tmp as XFS int he gate won't work. turns out a lot of the stuff infra does puts stuff in /tmp, so we can't blow it away23:46
torgomaticnotmyname: woo23:46
torgomaticnotmyname: can you get an XFS filesystem mounted somewhere else and set $TMPDIR?23:46
notmynametorgomatic: tdasilva: new plan is to mount the xfs loopback somehwere else, set that to TMPDIR and pass TMPDIR through to the tests. it should probably work23:46
notmynameyeah :-)23:46
torgomaticnotmyname: the good news is that TMPDIR is in tox's internal list of environment variables to allow through, so hopefully you won't need to mess with the passenv directive at all23:47
notmynameoh cool23:47
notmynameand so you'll probably be wondering, "are we good devs and we're just using the tempfile module/methods, or did we ever hard code /tmp somehwere?"23:47
*** Renich has quit IRC23:47
notmynamehint: it's not the good one23:48
mattoliveraulol23:49
notmynameit's probably fine, though23:49
*** _JZ_ has quit IRC23:49
pdardeaunotmyname: if you could just go ahead and send out the memo on that /tmp report that would be great! mmkay?23:50
notmynamelet me rephrase. it's not really fine, but it isn't likely to break test in the same way that not having xattrs does. tests should all work if we redefine TMPDIR23:51
notmynamebut there's a bit of stuff that should change23:54
claygnotmyname: i bet timburke could come up with a creative python/sed script that will walk the testdir and rewrite and class TestFoo(unitest.TestCase) as TestFoo(unit.test.BaseTestCase) if you need that23:54
*** Renich_ has quit IRC23:58

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