Tuesday, 2015-09-15

*** CR7 has quit IRC00:04
*** tongli has joined #openstack-swift00:09
*** tongli has quit IRC00:14
openstackgerritClay Gerrard proposed openstack/swift: Fix typo in Deployment Guide and add some formatting  https://review.openstack.org/22335600:17
*** minwoob has quit IRC00:20
*** kota_ has joined #openstack-swift00:26
*** ChanServ sets mode: +v kota_00:26
kota_good morning00:26
*** m_kazuhiro has joined #openstack-swift00:29
*** dmorita has joined #openstack-swift00:34
mattoliveraukota_: morning00:35
kota_mattoliverau: morning00:36
kota_mattoliverau: so... I updated my patch for bug 146092000:37
openstackbug 1460920 in OpenStack Object Storage (swift) "Successful PUT object might be missing container update on EC" [High,In progress] https://launchpad.net/bugs/1460920 - Assigned to Kota Tsuyuzaki (tsuyuzaki-kota)00:37
kota_mattoliverau: if you could have a time, could you review it?00:37
kota_patch is here, https://review.openstack.org/#/c/186735/00:38
mattoliveraukota_: I'll do my best too :)00:38
kota_I changed proxy to reattach missing container updates into footers of successful nodes.00:38
kota_mattoliverau: thanks ;)00:39
mattoliveraukota_: nice, yeah that's the best way.. I still have to look at the code, but do we do it for both EC and Repl? Cause in theory don't we have the same problem if the object ring has many replica's vs container replica count?00:40
kota_mattoliverau: exactly00:41
kota_but we don't have a way to put footers yet in Repl.00:41
kota_so i expect it's more big patch and it will be hard to review.00:41
mattoliverauyeah, I think footers need to be refactored out, which I think it will be cause doesn't encrytion need it00:42
kota_so IMO, the first land should be a fix for EC, and then, we will fix about Repl too.00:42
mattoliveraukota_: totally agree, just putting it out there :)00:42
*** zhill has quit IRC00:42
kota_mattoliverau: thanks but nice thought and notation to me :)00:43
*** garthb has quit IRC00:45
*** haomaiwang has joined #openstack-swift00:59
*** haomaiwang has quit IRC01:01
*** haomaiwang has joined #openstack-swift01:01
*** haomaiwang has quit IRC01:05
*** haomaiwang has joined #openstack-swift01:06
*** haomaiwang has quit IRC01:09
*** asettle has joined #openstack-swift01:19
openstackgerritZack M. Davis proposed openstack/swift: given Python 3, use parse_headers instead of rfc822.Message  https://review.openstack.org/20330401:22
*** haomaiwang has joined #openstack-swift01:46
*** haomaiwang has quit IRC02:01
*** haomaiwang has joined #openstack-swift02:01
*** asettle is now known as asettle-afk02:05
*** haomaiwang has quit IRC02:13
*** DericHorn-HP has quit IRC02:18
*** haomaiwang has joined #openstack-swift02:21
*** baojg has joined #openstack-swift02:27
*** DericHorn-HP has joined #openstack-swift02:27
*** tongli has joined #openstack-swift02:38
*** tongli has quit IRC02:43
*** DericHorn-HP has quit IRC02:57
*** haomaiwang has quit IRC03:01
*** haomaiwang has joined #openstack-swift03:01
*** gyee has quit IRC03:01
*** DericHorn-HP has joined #openstack-swift03:05
*** mahatic has joined #openstack-swift03:21
mahaticgood morning03:23
*** asettle-afk is now known as asettle03:24
*** sudorandom has quit IRC03:28
*** CrackerJackMack has quit IRC03:28
*** jroll has quit IRC03:28
*** darrenc_ has joined #openstack-swift03:29
*** zaitcev has quit IRC03:29
*** zacksh has quit IRC03:29
*** mattoliverau has quit IRC03:29
*** darrenc has quit IRC03:29
*** mattoliverau has joined #openstack-swift03:29
*** CrackerJackMack has joined #openstack-swift03:30
*** sudorandom has joined #openstack-swift03:30
*** ChanServ sets mode: +v mattoliverau03:30
*** zacksh has joined #openstack-swift03:30
mattoliveraumahatic: morning03:31
*** jroll has joined #openstack-swift03:31
*** nakagawamsa has joined #openstack-swift03:35
*** bill_az has quit IRC03:35
mahaticmattoliverau: o/ are you better now?03:35
mattoliverauMeh, but still working.. Just slowly :)03:36
mahatic:)03:36
asettle*cringe* mattoliverau I ended up with 38 comments on that patch, probably should do it myself hey? :p03:38
*** sudorandom has quit IRC03:39
*** jroll has quit IRC03:41
*** zacksh has quit IRC03:41
*** CrackerJackMack has quit IRC03:41
*** mattoliverau has quit IRC03:41
*** mattoliverau has joined #openstack-swift03:42
*** zacksh has joined #openstack-swift03:43
*** david-lyle has joined #openstack-swift03:50
*** haomaiwang has quit IRC04:01
*** haomaiwang has joined #openstack-swift04:01
*** CrackerJackMack has joined #openstack-swift04:03
*** sudorandom has joined #openstack-swift04:03
*** jroll has joined #openstack-swift04:04
*** rohit_ has joined #openstack-swift04:05
rohit_core reviewers: May i request reviews and approvals please : https://review.openstack.org/#/c/216903/ and https://review.openstack.org/#/c/217309/. These belong to ceilometermiddleware.swift04:06
*** kota_ has quit IRC04:07
*** wshao has joined #openstack-swift04:07
*** zhill has joined #openstack-swift04:08
*** wshao has quit IRC04:17
hroumahatic, quick question for you, what were your probe test results using patch 214438 ?04:20
patchbothrou: https://review.openstack.org/#/c/214438/04:20
hroumahatic, on the trello page it states "probetests: errors=2, failures=1 (probably different with mahatic changes)" but I'm seeing 2 failures my self.04:21
*** darrenc_ is now known as darrenc04:21
mahatichrou: before my changes, the probe failures were similar to what is mentioned in etherpad. error=2 failures=104:24
hroumahatic, what about after ? : )04:24
mahatichrou: none :D04:24
*** DericHorn-HP has quit IRC04:25
hrouBy your changes are you referring to 214438 ?04:25
mahatichrou: do you have probe test changes?04:25
mahatichrou: nope. patch 22089704:26
patchbotmahatic: https://review.openstack.org/#/c/220897/04:26
hrouAh do you mean patch 22089704:26
patchbothrou: https://review.openstack.org/#/c/220897/04:26
hrouah right : )04:26
hrouNope, I don't, let me pull that down and give it a go.04:26
hrouActually that should be the new head of the patch chain now.  Thanks mahatic !  I'll try that out.04:28
mahatichrou: yup, that's correct04:28
*** DericHorn-HP has joined #openstack-swift04:28
hroumahatic, great, thanks again!04:28
mahaticnp04:29
*** oc714|2 has joined #openstack-swift04:35
*** DericHorn-HP has quit IRC04:44
*** cdelatte has quit IRC04:45
*** cdelatte has joined #openstack-swift04:46
*** DericHorn-HP has joined #openstack-swift04:48
openstackgerritAlexandra Settle proposed openstack/swift: Moving DLO functionality doc to middleware  https://review.openstack.org/21999104:50
*** haomaiwang has quit IRC05:01
*** haomaiwang has joined #openstack-swift05:01
*** ppai has joined #openstack-swift05:04
*** baojg has quit IRC05:05
*** garthb has joined #openstack-swift05:06
*** baojg has joined #openstack-swift05:07
*** hezhiqiang has joined #openstack-swift05:12
*** kota_ has joined #openstack-swift05:15
*** ChanServ sets mode: +v kota_05:15
*** flwang1 has quit IRC05:18
*** DericHorn-HP has quit IRC05:20
*** esker has joined #openstack-swift05:34
*** mahatic has quit IRC05:35
asettlenotmyname, this is for you later: https://review.openstack.org/#/c/219991/505:36
*** baojg has quit IRC05:42
*** DericHorn-HP has joined #openstack-swift05:45
*** DericHorn-HP has quit IRC05:46
*** hrou has quit IRC05:50
*** baojg has joined #openstack-swift05:51
*** frank__ has joined #openstack-swift05:58
*** garthb has quit IRC05:58
*** frank__ has quit IRC05:58
*** frank__ has joined #openstack-swift05:59
*** haomaiwang has quit IRC06:01
*** frank__ is now known as fgemein_06:01
*** haomaiwang has joined #openstack-swift06:01
*** fgemein_ is now known as panchovilla06:01
panchovillahello everyone06:02
panchovillai have some questions regarding the swift builder files ( e.g. account.builder )06:04
panchovillais there anyone with some deeper insight into this topic06:05
panchovilla?06:05
* panchovilla is a sysadmin from Hamburg06:09
panchovillaLIST06:11
*** m_kazuhiro has quit IRC06:12
openstackgerritKota Tsuyuzaki proposed openstack/swift: Use small part power instead of seeds  https://review.openstack.org/22342206:12
kota_panchovilla: what do you want to ask? perhaps, I might answer for you.06:15
kota_because I'm reading ring builder code just now06:16
panchovillaHi Thx! I've restored builder out of the *.ring.gz06:20
panchovillaNow I want to check the results06:20
panchovillaMaybe you can take a short look at my question here ? https://ask.openstack.org/en/question/81708/ring-builder-files-lost-swift/06:21
*** zhill has quit IRC06:27
*** SkyRocknRoll has joined #openstack-swift06:29
*** hezhiqia_ has joined #openstack-swift06:33
*** hezhiqiang has quit IRC06:34
*** hezhiqiang has joined #openstack-swift06:38
*** hezhiqia_ has quit IRC06:38
kota_panchovilla: I'm back.06:38
*** wshao has joined #openstack-swift06:42
*** hezhiqiang has quit IRC06:43
*** hezhiqia_ has joined #openstack-swift06:44
*** m_kazuhiro has joined #openstack-swift06:46
panchovilla builder._set_parts_wanted()06:52
panchovillaTraceback (most recent call last):06:52
panchovilla  File "<stdin>", line 1, in <module>06:52
panchovilla  File "/usr/local/lib/python2.7/dist-packages/swift-1.7.5-py2.7.egg/swift/common/ring/builder.py", line 456, in _set_parts_wanted06:52
panchovilla    int(weight_of_one_part * dev['weight']) - dev['parts']06:52
panchovillaKeyError: 'parts'06:52
*** haomaiwang has quit IRC07:01
*** haomaiwang has joined #openstack-swift07:01
*** rledisez has joined #openstack-swift07:09
*** wshao has quit IRC07:10
*** hezhiqiang has joined #openstack-swift07:12
*** hezhiqia_ has quit IRC07:16
*** haomaiwang has quit IRC07:18
*** haomaiwang has joined #openstack-swift07:19
*** jordanP has joined #openstack-swift07:38
*** geaaru has joined #openstack-swift07:39
*** mahatic has joined #openstack-swift07:41
*** panchovilla has quit IRC07:49
*** hezhiqiang has quit IRC07:56
*** acoles_ is now known as acoles07:57
*** hezhiqiang has joined #openstack-swift07:58
mahaticacoles: good morning!07:58
*** m_kazuhiro has quit IRC07:59
acolesmahatic: good morning08:00
*** rohit_ has quit IRC08:00
*** haomaiwang has quit IRC08:01
acolesrohit_: swift cores cannot approve ceilometer middleware reviews. at least, i can't.08:01
*** haomaiwa_ has joined #openstack-swift08:01
*** chenhuayi has joined #openstack-swift08:07
*** mahatic has quit IRC08:14
*** jistr has joined #openstack-swift08:18
*** m_kazuhiro has joined #openstack-swift08:28
*** I has joined #openstack-swift08:40
*** I is now known as Guest1046108:40
openstackgerritAlistair Coles proposed openstack/swift: Update EC Support on how to build an EC ring with replicas count  https://review.openstack.org/22330408:41
*** haigang has joined #openstack-swift08:47
Guest10461#list08:55
*** Guest10461 has quit IRC08:56
*** haigang has quit IRC08:56
*** haomaiwa_ has quit IRC08:59
*** haomaiwang has joined #openstack-swift09:05
openstackgerritMahati Chamarthy proposed openstack/python-swiftclient: Add headers parameter  https://review.openstack.org/22348909:06
*** mahatic has joined #openstack-swift09:07
openstackgerritMerged openstack/swift: Fix typo in Deployment Guide and add some formatting  https://review.openstack.org/22335609:08
*** aix has quit IRC09:09
*** haomaiwang has quit IRC09:23
*** haomaiwa_ has joined #openstack-swift09:33
*** kota_ has quit IRC09:49
*** bill_az has joined #openstack-swift09:53
*** aix has joined #openstack-swift09:57
*** haomaiwa_ has quit IRC10:01
*** haomaiwang has joined #openstack-swift10:01
*** haomaiwang has quit IRC10:07
*** DericHorn-HP has joined #openstack-swift10:09
*** chlong has quit IRC10:09
*** haomaiwa_ has joined #openstack-swift10:10
*** chlong has joined #openstack-swift10:11
*** m_kazuhiro has quit IRC10:13
*** hezhiqiang has quit IRC10:14
*** baojg has quit IRC10:16
*** baojg has joined #openstack-swift10:16
*** baojg has quit IRC10:21
*** haomaiw__ has joined #openstack-swift10:22
*** haomaiwa_ has quit IRC10:24
*** mahatic has quit IRC10:25
*** SkyRocknRoll has quit IRC10:29
*** flwang has quit IRC10:31
*** asettle has quit IRC10:31
*** mahatic has joined #openstack-swift10:31
*** flwang has joined #openstack-swift10:32
*** flwang1 has joined #openstack-swift10:37
flwang1cschwede: ping10:37
*** ujjain- has quit IRC10:52
*** ujjain has joined #openstack-swift10:53
*** ujjain has joined #openstack-swift10:53
*** DericHorn-HP has quit IRC10:55
*** haomaiw__ has quit IRC11:01
*** haomaiwang has joined #openstack-swift11:01
*** trifon_ has quit IRC11:08
*** trifon has joined #openstack-swift11:13
*** ccavanna_ has quit IRC11:19
*** mahatic has quit IRC11:20
*** mahatic has joined #openstack-swift11:24
*** mahatic has quit IRC11:27
*** mahatic has joined #openstack-swift11:28
*** hezhiqiang has joined #openstack-swift11:37
*** kei_yama has quit IRC11:40
*** haomaiwang has quit IRC11:42
*** cdelatte has quit IRC11:46
*** mahatic has quit IRC11:51
*** mahatic has joined #openstack-swift11:52
*** nakagawamsa has quit IRC12:05
*** mahatic has quit IRC12:07
*** mahatic has joined #openstack-swift12:08
notmynamegood morning12:10
* notmyname just finished reading emails and IRC buffers12:11
*** cdelatte has joined #openstack-swift12:13
*** delattec has joined #openstack-swift12:14
*** delattec has quit IRC12:15
*** cdelatte has quit IRC12:18
*** SkyRocknRoll has joined #openstack-swift12:20
*** km has quit IRC12:24
*** annegentle has joined #openstack-swift12:25
*** cdelatte has joined #openstack-swift12:25
* notmyname is off for another day of talking about swift12:26
*** MVenesio has joined #openstack-swift12:32
*** dmorita has quit IRC12:35
*** changbl has quit IRC12:36
*** mahatic has quit IRC12:38
*** DericHorn-HP has joined #openstack-swift12:41
mattoliveraunotmyname: morning and have fun.12:59
* mattoliverau is off to bed.. and yes my phone is on silent :P12:59
*** tongli has joined #openstack-swift13:02
*** pberis1 has joined #openstack-swift13:03
*** dustins has joined #openstack-swift13:07
*** resker has joined #openstack-swift13:10
*** DericHorn-HP has quit IRC13:11
*** hrou has joined #openstack-swift13:12
*** esker has quit IRC13:14
*** dustins has quit IRC13:18
*** SkyRocknRoll has quit IRC13:20
*** dustins has joined #openstack-swift13:23
*** janonymous has joined #openstack-swift13:27
*** wbhuber has joined #openstack-swift13:29
*** ppai has quit IRC13:38
*** jkugel has joined #openstack-swift13:39
*** annegentle has quit IRC13:46
*** resker has quit IRC13:47
*** esker has joined #openstack-swift13:47
*** mahatic has joined #openstack-swift13:48
*** dustins has quit IRC13:59
*** haypo has joined #openstack-swift14:00
*** dustins has joined #openstack-swift14:03
hrouHey acoles, around ?14:07
*** annegentle has joined #openstack-swift14:08
*** jrichli has joined #openstack-swift14:15
openstackgerritOpenStack Proposal Bot proposed openstack/swift: Updated from global requirements  https://review.openstack.org/8873614:19
*** david-lyle has quit IRC14:20
acoleshrou: hi14:21
hrouHey acoles !  I think I have an answer to my question, its fairly generic but:  Regarding if-(not)-match (i.e. conditional get) functionality, do you always need to supply an object (i.e. you can't do if-match /<accnt>/<cont>/ with a etag), I poked around in the code and it seems we'll only compare when we have an object in hand at the object server.14:22
*** silor has joined #openstack-swift14:23
hrouYou can always supply the header, but when you do it and query a container for example, we seem to return everything regardless.14:23
hrou* swift client will support it but internally its a head + get with the etag on all the objects individually14:24
acoleshrou: yes just objects, i think the code path is in swift.common.swob.Response - the constructor takes a conditional_response flag that looks to only ever be True in the object path14:29
hrouacoles, that's exactly what I was looking at : )14:30
hrouacoles, Ok that's somewhat good news, though I wonder if that may ever change in the future.14:30
acoleshrou: you got it then :)14:30
jrichliacoles: hrou and I want to make sure that there is always client provided info on all if-(not)-match type requests that would tell the keymaster exactly which key was needed in order to possibly provide the correct comparison.14:31
hrouacoles, by change I mean, we simply send the request to the container for all objects and it passes down the etag to the underlying object server(s), but I doubt such functionality exists (it'd most likely be a head request first) which is Ok as long as the keymaster comes after this (so we can get the correct key).14:32
hroujrichli, yep exactly14:32
jrichliacoles: for example, if there was a way to ask "return to me any object that has this etag", then there would be no way to know which key to use to encrypt the client provided etag to possibly have a successful comparison.14:34
*** annegentle has quit IRC14:36
*** annegentle has joined #openstack-swift14:37
acolesjrichli: hrou is that funtionality did exist, how would it work today? it would need a container list to find matching object, then do a GET for the object. That would work with crypto I think ? contaner key is used to decrypt etags in container listing, then object path would be know so object key can be found.14:38
* acoles may be missing your point14:38
acoless/is/if/ at the start ^^14:39
*** chsc has joined #openstack-swift14:39
hrouacoles, thanks acoles, no that was my thought as well ! i.e. if that functionality were to be implemented it would be done so as you describe, which is fine for crypto14:40
hrouacoles, jrichli, I think the one concern that still exists is something I highlighted in the etherpad, but its a rather convulted14:40
hrouacoles, jrichli something like: say you put object 1 on path X (client saves etag 1), another client puts object 2 on the same path X ... the keymaster may choose to use a different KEY for this etag (if it picks keys per path or per container that won't be the case).14:41
acoleshrou: if the object key is random rather than a function of object path then you would need to fetch it from object metadata first before doing the conditional GET.14:43
acoleshrou: and yes, that would be prone to inconsistency between replicas14:43
acoleshrou: even if you HEAD the object for its key, you may then send GET to a different replica which has a different key14:44
hrouacoles, yep exactly, which in theory is applicable to scenarios other than conditional gets.14:44
jrichliacoles: given that container listing is acceptable in the handling on the way in, maybe another option to our if-not-match issues is to put the crypto-meta in the container listing - encrypted with container key14:45
jrichlithat way, we could still remain flexible on the crypto-alg used for etag14:46
*** jlhinson has joined #openstack-swift14:46
acolesjrichli: are we still talking about a hypothetical future feature?14:47
hroujrichli, what do you mean by acceptable though ?  Currently there is no head request for a "if .. match", the "head" was a potential 'future' implementation to support my hypothetical scenario : )14:47
jrichliacoles: do you mean the part about being flexible on crypto-alg?14:48
acolesjrichli: i don't think i mean that :) this started with a hypothetical conditional GET for any object in a container14:49
acolesyeah, what hrou said14:49
jrichlioh, right.  And I liked your answer - I wouldn't have thought of it because I typically think we should not be doing requests from the middleware - but i remember now, container requests are better than obj reqs14:50
acolesdoing a container listing to get the object etag or (hypothetically) the object key has same inconsistency issue as doing an object HEAD - the container listing may not be consistent with the state of the object replica you then send a GET to14:50
acolescontainer info lookups are "better" because they often do not incur a request when info is cached. But they are not better in terms of any guarantee of consistency with object state.14:51
hrouacoles, I'd probably state that's a generic concern that exists even today with the current implementation (not related to conditional get) e.g. re-put an object, try to get, if keymaster creates a new key it better manage which one to send due to the eventual consistency nature of the system14:52
acoleshrou: trivial keymaster always creates same key for same path14:53
acolesand its only an issue when you need the key before doing the GET - normal GETs would return the key if it were stored with the object14:53
hrouacoles, yep !  Sorry I meant for another implementation that doesn't base it on paths (I think the IBM keymaster was going down the route, jrichli ?)  But I think we discussed some solutions for that during the hackathon14:54
hrouacoles, yep that's true !  Though I'm not sure where the majority of keymasters will be storing keys, may not reside with the object (or swift in general)14:55
jrichlihrou: yes.  you can see Trello cards in column 'To Do' for Rare Cases to see if all the ideas you are talking about are represented there14:56
hroujrichli, thanks yea !  I recall the card for it.14:56
hrouOk, I feel better about conditional gets as a whole, thanks jrichli, acoles !14:56
jrichliacoles hrou: this is getting into "real" keymaster talk.  I was thinking of setting up a new etherpad for thoughts on what a real keymaster might look like, and what issues it may have14:57
hroujrichli, yea that's a really good idea.14:57
jrichlior, i could tack it onto the existing pad, but its getting sort of full14:57
jrichliactually, come to think of it, that was acoles idea14:58
jrichliwhen i talked with him about re-key14:58
hroujrichli, though that kinda of bothers me : )  See we're trying to create a generic implemenation that can satisfy any and all mythical keymasters, but clearly they're implementation has a strong effect on the reset of crypto.14:58
*** minwoob has joined #openstack-swift14:59
hroujrichli, yep I remember that @ the hackathon (I think that's when I had to leave : - )14:59
acolesi don't remember that !14:59
jrichliBut yes, a lot of our thinking has been about a keymaster that uses swift itself to store the keys.  since there aren't many cloud-scalable choices for storing a different key for each object, and key derivation was *questionable* to some people14:59
hrouacoles, haha !14:59
hroujrichli, right yea that makes sense, though we're proposing to do key derivation now ; )  But that's for the specific obj / meta / etag keys.15:00
*** pberis1 has quit IRC15:01
hroujrichli, seperate etherpad could work but I think it may effect things other than the keymaster (i.e. require changes to other parts of crypto), no big deal either way for now!15:01
jrichlione of the people here that disliked the idea of key derivation, also doesn't really care about the etag being revealed.  I explained that having the etags would mean that you have an easy way to verify whether your object body attach was successful15:01
jrichlis/attach/attack/15:02
hroujrichli, was the concern derived keys in the sense of "you have one key for a container" and derive the rest ? I can understand that, we're proposing something much more granular.15:02
*** SkyRocknRoll has joined #openstack-swift15:03
hroujrichli,  i.e. we're just doing it within swift to ensure we have separate keys for each crpyto unit.  They may be Ok with that aspect ?15:03
jrichliagain, this individual doesn't have issues with the current proposal, since its only about etag15:03
hroujrichli, ah gotcha, yep, that makes sense.15:04
hroujrichli, but yea we could start up some calls / conversations about the 'real' keymaster and the effect it may have on the rest of the solution ?15:04
jrichlihrou: sounds good.  I think the new etherpad would be a good start.15:05
hroujrichli, yep!  If we find anything that effects the rest of crypto we can just put a link into the other one.15:05
* jrichli is going to cafeteria for free starbucks beverage15:07
*** kevinc_ has joined #openstack-swift15:11
*** david-lyle has joined #openstack-swift15:13
*** then3rd has quit IRC15:18
*** SkyRocknRoll has quit IRC15:21
*** garthb has joined #openstack-swift15:33
*** robefran has joined #openstack-swift15:40
*** gyee has joined #openstack-swift15:53
*** rohit_ has joined #openstack-swift15:57
*** esker has quit IRC16:12
*** janonymous_ has joined #openstack-swift16:20
brianclinemorning16:20
brianclinemight anyone have a few minutes to review patch 219617?16:20
patchbotbriancline: https://review.openstack.org/#/c/219617/16:20
*** annegent_ has joined #openstack-swift16:22
*** jistr has quit IRC16:24
*** annegentle has quit IRC16:24
*** annegentle has joined #openstack-swift16:28
*** annegentle has quit IRC16:30
*** annegentle has joined #openstack-swift16:31
*** jordanP has quit IRC16:31
*** annegent_ has quit IRC16:31
*** breitz has joined #openstack-swift16:32
*** breitz has quit IRC16:34
*** breitz has joined #openstack-swift16:35
*** breitz has quit IRC16:37
*** breitz has joined #openstack-swift16:38
*** aix has quit IRC16:39
*** kutija has joined #openstack-swift16:40
*** rledisez has quit IRC16:41
*** janonymous has quit IRC16:43
*** breitz has quit IRC16:44
*** janonymous_ has quit IRC16:46
*** breitz has joined #openstack-swift16:48
*** cdelatte has quit IRC16:48
*** fifieldt_ has quit IRC16:49
*** geaaru has quit IRC17:04
*** cdelatte has joined #openstack-swift17:07
*** delattec has joined #openstack-swift17:07
*** changbl has joined #openstack-swift17:17
*** hezhiqiang has quit IRC17:19
*** oc714|2 has left #openstack-swift17:26
*** annegentle has quit IRC17:39
*** annegentle has joined #openstack-swift17:47
*** chenhuayi has quit IRC17:49
*** chenhuayi has joined #openstack-swift17:50
*** annegent_ has joined #openstack-swift17:56
*** annegentle has quit IRC18:00
*** annegent_ has quit IRC18:04
*** annegentle has joined #openstack-swift18:05
*** annegentle has quit IRC18:11
mahaticjrichli: hrou the error from 'gate-swiftclient-dvsm-functional' on this patch 223489 happen when the encryption is on. But I'm not sure from where is the gate picking encryption. any ideas?18:11
patchbotmahatic: https://review.openstack.org/#/c/223489/18:11
*** bill_az has quit IRC18:13
*** annegentle has joined #openstack-swift18:13
*** cdelatte has quit IRC18:35
*** delattec has quit IRC18:35
clayghello18:38
claygbriancline: I'll take a look18:38
jrichlimahatic: I don't know of a reason that the gate would pick-up encryption for a change against the python-swiftclient repo.  Are you sure that is happening?18:39
*** haypo has left #openstack-swift18:40
mahaticjrichli: I don't have an error on my local repo when I take off encryption from proxy conf. Otherwise it threw an error on etag mismatch, that got me confused18:42
jrichlimahatic: the error I am seeing from the gate is not about an etag mismatch.  It is getting unauthorized on a few container listing tests.18:43
mahaticjrichli: right, test_list_container. that's where i have etag mismatch on my repo18:44
jrichlimahatic: are you trying to find out why the gate is failing (the authorization error), or why the changes locally have an etag issue when encryption is on?18:45
mahaticjrichli: the first (which lead me to the latter)18:46
jrichlimahatic: ok.  focusing on the gate issue, I think it would be best to try to reproduce that locally - with encryption out of the pipeline.  I don't think there is any way that gate can have encryption code to run.18:48
mahaticjrichli: :) I did that and the result is etag mismatch error on the same test18:48
mahatici.e. test_list_container18:48
*** dustins has quit IRC18:49
mahaticjrichli: oh w/o encryption on pipeline, no errors. Could you cross check that?18:49
jrichlisure, i will give it a spin.18:49
mahaticgreat, thanks!18:49
*** delattec has joined #openstack-swift18:50
*** cdelatte has joined #openstack-swift18:50
*** wshao has joined #openstack-swift18:50
*** hezhiqiang has joined #openstack-swift18:50
claygso gross that head_object in swiftclient doesn't have the headers param (how's a brother supposed to if-match!?) - re: patch 22348918:54
patchbotclayg: https://review.openstack.org/#/c/223489/18:54
claygtorgomatic: timburke: you guys should also put a vote on patch 22348918:54
patchbotclayg: https://review.openstack.org/#/c/223489/18:54
mahaticclayg: thanks for looking at that !18:55
claygmahatic: didn't take long :\18:56
claygmahatic: let me know when you push something else!18:56
claygmahatic: thanks for working on it!18:56
*** hezhiqiang has quit IRC18:56
claygwhat's hamdi's handle again?18:56
mahaticclayg: sure thing. and yes this needs tests!18:57
jrichliclayg: hrou18:57
mahaticclayg: hrou there18:57
clayghrou: kudos on you too - thanks for working to make swiftclient better!18:57
*** dustins has joined #openstack-swift18:59
acolesmahatic: see my review on patch 223489, tox -e func works for me when i pass headers=headers19:00
patchbotacoles: https://review.openstack.org/#/c/223489/19:00
claygacoles: how can I help review optomistic gets?  diskfile dict change?19:02
mahaticacoles: just saw that, thanks much! it makes sense. Will pull it down and verify19:03
*** esker has joined #openstack-swift19:04
*** esker has joined #openstack-swift19:05
acolesclayg: yes that would be a good place to start. thanks! patch 22270619:05
patchbotacoles: https://review.openstack.org/#/c/222706/19:05
*** gyee has quit IRC19:05
*** esker has quit IRC19:05
*** hezhiqiang has joined #openstack-swift19:06
*** esker has joined #openstack-swift19:06
acolesclayg: then patch 215276 i marked as WIP but what is there might be worth looking over - its WIP because I need to add the proxy side changes19:08
patchbotacoles: https://review.openstack.org/#/c/215276/19:08
acolesclayg: been thinking I should change X-Durable to X-Backend-Durable19:09
acolesclayg: i should have the optimistic proxy side of things ready tomorrow.19:15
*** hezhiqiang has quit IRC19:15
*** acoles is now known as acoles_19:16
*** mahatic has quit IRC19:17
*** silor1 has joined #openstack-swift19:28
*** dustins has quit IRC19:30
*** dustins has joined #openstack-swift19:30
*** silor has quit IRC19:32
*** silor1 is now known as silor19:32
claygacoles_: oh yeah -Backend- FTW19:33
claygi don't really know what to say to the nobarriers guy on the ML19:36
clayg'ok so, maybe you suggest we change it to "nobariers is probably faster and maybe what you want on some hardware but YMMV"19:36
*** DericHorn-HP has joined #openstack-swift19:38
*** hezhiqiang has joined #openstack-swift19:40
*** flwang1 has quit IRC19:48
*** silor1 has joined #openstack-swift19:49
*** annegentle has quit IRC19:50
*** devlaps has joined #openstack-swift19:51
*** silor has quit IRC19:52
*** silor1 is now known as silor19:52
*** hezhiqiang has quit IRC19:56
* clayg puts using rclone on my list19:59
*** hezhiqiang has joined #openstack-swift20:07
*** silor1 has joined #openstack-swift20:07
*** wshao has quit IRC20:08
*** gyee has joined #openstack-swift20:08
*** silor has quit IRC20:09
*** silor1 is now known as silor20:09
*** proteusguy_ has quit IRC20:12
*** tsimp06 has joined #openstack-swift20:14
*** robefran has quit IRC20:14
*** lcurtis has joined #openstack-swift20:20
*** hezhiqiang has quit IRC20:20
*** dustins_ has joined #openstack-swift20:31
brianclineTIL what rclone is. very cool20:33
*** dustins has quit IRC20:34
*** silor has quit IRC20:35
*** proteusguy_ has joined #openstack-swift20:36
*** annegentle has joined #openstack-swift20:37
openstackgerritRichard Hawkins proposed openstack/swift: Fix object name length check.  https://review.openstack.org/22379720:38
*** dustins_ has quit IRC20:40
hurricanerixnotmyname: Should I have submitted a bug before submitting a patch?  ^^^20:43
clayghurricanerix: most of the time, yes - it complete's the circle of life20:45
claygis that constraint only enforced on PUT/COPY - that sort of thing - or do we lock data in clusters!?20:46
clayghurricanerix: ^20:47
hurricanerixclayg: That is a good question, I was only concerned with PUT/COPY when writing the patch.20:47
hurricanerixclayg: let me check a GET20:48
claygbriancline: rclone is cool because it's in golang - golang makes everything cooler20:48
openstackgerritThiago da Silva proposed openstack/swift: WIP: new attempt at single-process  https://review.openstack.org/15928520:48
clayghurricanerix: I would have swore there was an existing functest for object name length - crazy20:50
hurricanerixclayg: do you remember if it checked for the name containing percent encoded values?20:51
clayghurricanerix: no i'm sure it wouldn't have or your change would have been needed :)20:51
hurricanerixbecause if it is just 'aaaa....' then it worked as is.20:51
claygbut it coudl probably be updated w/o having to add that second new one?20:51
*** cdelatte has quit IRC20:51
*** delattec has quit IRC20:51
hurricanerixclayg: yeah, I'll look around and if I can find it, I'll clean my tests up.20:52
claygtests.TestFile.testNameLimit20:52
clayghurricanerix: I just grepped for max_object_name_length20:53
hurricanerixlol, whoops =)20:53
*** changbl has quit IRC20:55
hurricanerixclayg: looks like you can still GET20:55
clayghurricanerix: that's good right!?20:55
clayghurricanerix: probably wouldn't hurt to have a unitest for it tho20:56
claygwell... it might hurt a little20:56
hurricanerixclayg: I think so, I don't think I would want the fix to affect people who might have already accidentally exceeded the limit.20:56
*** pgbridge has quit IRC20:56
claygit wouldn't hurt *me* tho - cause I woudln't be the one writing it!20:56
clayghurricanerix: +120:56
hurricanerixBut they might get a surprise if they try to change the object.20:57
clayg*suprise*!20:57
*** wshao has joined #openstack-swift20:57
hurricanerixclayg: or if they try to update metadata.20:58
*** hrou has quit IRC20:59
claygbut I agree in principle that constraints are there to protect the operator - if you can blow up the lenght limit by 3x by making an object with lots of ' ' in the name that's not really honoring the deployers constraints - so I think it's a reasonable enough change - deployer could up the limit if they surprise anyone?20:59
hurricanerixtrue20:59
claygthen it'd be more like setting the limit in the conf file to the *real* limit20:59
*** hrou has joined #openstack-swift20:59
*** mragupat has joined #openstack-swift20:59
*** flwang1 has joined #openstack-swift21:02
*** garthb has quit IRC21:03
claygnotmyname: I'm really not loving the new gerrit view :\21:06
*** DericHorn-HP has quit IRC21:08
*** DericHorn-HP has joined #openstack-swift21:17
*** MVenesio has quit IRC21:20
*** hezhiqiang has joined #openstack-swift21:21
*** mragupat has quit IRC21:22
*** mragupat has joined #openstack-swift21:22
*** hezhiqiang has quit IRC21:25
brianclinethe name length fix is an interesting one21:28
brianclinehow do unicode characters get counted?21:29
*** rohit_ has quit IRC21:30
*** wbhuber has quit IRC21:30
*** garthb has joined #openstack-swift21:33
*** flwang1 has left #openstack-swift21:36
*** kevinc_ has quit IRC21:36
hurricanerixbriancline: I need to verify, but I would guess like this: In [2]: urllib.quote('☃')21:40
hurricanerixOut[2]: '%E2%98%83', so counted as 9 chars.21:40
claygf'ing unicode21:42
torgomaticI'd hope for 3, because that's the length of the UTF-8 representation21:43
torgomaticbut, bigger question: what's the point of the name check? what would we lose if we took it out?21:43
claygbut not all utf-8 bytes are url-safe21:43
torgomatic(i'm not proposing to take it out)21:43
claygtorgomatic: people would put zero byte object there were like 'name data' - and then do prefix listings21:44
clayg... or something21:44
torgomaticclayg: oh, so it's a "hey jerks, knock it off" kind of thing21:44
claygyeah I think so - or maybe just in general to keep the containers rows less than a few K wide21:45
*** pberis has joined #openstack-swift21:45
claygthere's probably no limit to how big your content-length can be21:45
*** jrichli has quit IRC21:45
claygjerks21:45
torgomaticwell, there's the header-line length limit21:46
torgomaticthat'll get everything but the name21:46
claygstupid name21:46
claygascii had more than enough printable characters for anyone21:47
claygand you know how wide they were!?  what char!21:49
clayg*one21:49
*** tongli has quit IRC21:51
claygq22:02
*** hrou has quit IRC22:03
*** _hrou_ has joined #openstack-swift22:03
_hrou_thanks clayg !  Just getting caught up, and great work acoles_, all for find that gate issue with the patch.22:04
_hrou_* s/find/finding22:05
*** jkugel has quit IRC22:06
openstackgerritClay Gerrard proposed openstack/swift: fixups for acoles  https://review.openstack.org/22385422:11
*** asettle has joined #openstack-swift22:24
*** pberis has quit IRC22:27
openstackgerritAlexandra Settle proposed openstack/swift: Moving DLO functionality doc to middleware  https://review.openstack.org/21999122:27
mattoliverauMorning22:30
asettleMorning o/22:30
*** lcurtis has quit IRC22:32
*** ChanServ sets mode: +v mattoliverau22:42
*** asettle has quit IRC22:43
*** DericHorn-HP has quit IRC22:51
*** darrenc is now known as darrenc_afk22:52
*** aix has joined #openstack-swift22:52
*** mragupat has quit IRC22:56
*** zhill has joined #openstack-swift22:57
*** wshao has quit IRC23:01
*** annegentle has quit IRC23:03
*** km has joined #openstack-swift23:04
*** darrenc_afk is now known as darrenc23:06
*** openstackgerrit has quit IRC23:16
*** openstackgerrit has joined #openstack-swift23:16
*** david-lyle has quit IRC23:17
*** chsc has quit IRC23:17
*** kei_yama has joined #openstack-swift23:27
*** _hrou_ has quit IRC23:33
*** breitz has quit IRC23:41
mattoliverauAnd the channel goes quiet when I arrive. Do I need to change my nick to be about to stalk you all?.. again :P23:42
*** ho has joined #openstack-swift23:47
tdasilvamattoliverau: hey!! you just need to come back to our timezone :-)23:51
*** jlhinson has quit IRC23:51
mattoliverautdasilva: lol, true.. or you all come to mine, say next month?23:52
tdasilvamattoliverau: sounds about right :-) my agenda is quite busy for the beginning of the month, but I should be there at the end of the month ;)23:53
*** aix has quit IRC23:53
mattoliverautdasilva: great, lets make a week of it, we'll talk swift, maybe go grab some sushi ;P23:55
tdasilvamattoliverau: deal!23:55
tdasilvamattoliverau: feeling better?23:57
mattoliverautdasilva: yeah much, still not 100% but enough to work faster. Managed to fumble round and get the first version of the container-sharder daemon completed (inline with last hackathon). So hasn't been a wasted week :)23:59
*** wshao has joined #openstack-swift23:59

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