Monday, 2014-10-27

*** miurahr has quit IRC00:05
*** dmorita has joined #openstack-swift00:31
*** mitz_ has joined #openstack-swift00:40
*** HenryG has quit IRC00:41
*** miurahr has joined #openstack-swift00:42
*** miurahr has quit IRC00:45
*** HenryG has joined #openstack-swift00:46
*** miurahr has joined #openstack-swift00:47
*** miurahr has quit IRC00:51
*** addnull has joined #openstack-swift00:58
*** X019 has quit IRC01:08
*** foexle has quit IRC01:13
*** BAKfr has quit IRC01:18
*** kyles_ne has joined #openstack-swift01:18
*** HenryG has quit IRC01:24
*** kyles_ne_ has joined #openstack-swift01:25
*** kyles_ne has quit IRC01:26
*** BAKfr has joined #openstack-swift01:27
*** HenryG has joined #openstack-swift01:32
*** addnull has quit IRC01:35
*** addnull has joined #openstack-swift01:38
*** addnull has quit IRC01:53
*** nosnos has joined #openstack-swift02:07
*** addnull has joined #openstack-swift02:33
*** haomaiwa_ has joined #openstack-swift02:40
*** nosnos has quit IRC03:22
*** nosnos has joined #openstack-swift03:23
*** nosnos has quit IRC03:27
*** kyles_ne_ has quit IRC03:36
*** jyoti-ranjan has joined #openstack-swift03:42
*** elambert has joined #openstack-swift03:54
*** elambert has joined #openstack-swift03:54
*** nosnos has joined #openstack-swift04:04
*** wer has quit IRC04:06
*** haomaiwa_ has quit IRC04:06
*** addnull has quit IRC04:30
*** ppai has joined #openstack-swift04:47
*** abhirc has quit IRC04:47
*** SkyRocknRoll has joined #openstack-swift05:09
*** SkyRocknRoll has joined #openstack-swift05:09
*** elambert has quit IRC05:16
*** elambert has joined #openstack-swift05:17
*** addnull has joined #openstack-swift05:19
*** addnull has quit IRC05:31
*** elambert has quit IRC05:32
*** elambert has joined #openstack-swift05:32
*** elambert has quit IRC05:37
*** addnull has joined #openstack-swift05:44
*** nosnos has quit IRC05:59
*** nosnos_ has joined #openstack-swift05:59
*** k4n0 has joined #openstack-swift06:18
*** addnull has quit IRC06:20
*** kyles_ne has joined #openstack-swift06:36
mattoliverauI'm calling it a day, night all.06:39
*** kyles_ne has quit IRC06:41
*** wer has joined #openstack-swift06:42
*** foexle has joined #openstack-swift07:03
*** nosnos_ has quit IRC07:13
*** nosnos has joined #openstack-swift07:13
cschwedemahatic: I’m around now :)07:16
*** elambert has joined #openstack-swift07:21
*** elambert has quit IRC07:29
*** X019 has joined #openstack-swift07:35
*** ppai has quit IRC07:40
*** ppai has joined #openstack-swift07:42
*** davidhadas has quit IRC08:07
*** jyoti-ranjan has quit IRC08:09
*** X019 has quit IRC08:16
*** jyoti-ranjan has joined #openstack-swift08:36
*** jordanP has joined #openstack-swift08:38
*** geaaru has joined #openstack-swift08:48
*** jistr has joined #openstack-swift08:49
*** addnull has joined #openstack-swift09:00
*** addnull has quit IRC09:05
*** addnull has joined #openstack-swift09:11
*** addnull has quit IRC09:51
*** manish_ has joined #openstack-swift09:54
manish_clayg: Hi09:54
manish_I want to configure SWIFT with HTTPS... is it possible in SWIFT?09:55
manish_clayg: do u have any idea about this?09:55
mattoliveraumanish sure, the proxy handles https, so you can have SSL to the proxy and the no SSL from proxy to storage nodes.10:07
*** jyoti-ranjan has quit IRC10:07
mattoliveraumanish_ ^^10:08
ahaleyeah though proxy will emit a warning with https now I think? since its not as good at terminating as things designed for it like nginx/haproxy/stud/whatever10:10
*** jyoti-ranjan has joined #openstack-swift10:10
manish_mattoliverau: Thanks for information. Do you know what steps i need to follow to configure this?10:12
manish_mattoliverau: do i need to put following values in proxy-server.conf file ------------  cert_file = /etc/swift/proxy.crt , key_file = /etc/swift/proxy.key  ?10:13
manish_ahale: thanks..10:13
cschwedemanish_: have a look at pound too, you could use it as a ssl terminator in front of the proxy: http://www.apsis.ch/pound/10:15
*** addnull has joined #openstack-swift10:16
mattoliveraumanish_: yeah cert_file and key_file, but the Juno docs talk about the warning, so it'll work but SSL termination from something like pound, nginx or other load balancers would be better (as the others suggest)10:21
mattoliverauHere is the latest proxy server doc: http://docs.openstack.org/trunk/config-reference/content/proxy-server-configuration.html10:23
*** sfineberg has quit IRC10:25
*** sfineberg has joined #openstack-swift10:25
*** addnull has quit IRC10:28
manish_mattoliverau: i ma not concerned about warning as of now. SO by just mentioning above two parameters in proxy-server.conf is enough for handling HTTPS requests?10:28
*** ppai has quit IRC10:29
*** addnull has joined #openstack-swift10:41
*** ppai has joined #openstack-swift10:43
*** exploreshaifali has joined #openstack-swift10:44
*** X019 has joined #openstack-swift10:56
*** tdasilva has joined #openstack-swift10:59
*** mkollaro has joined #openstack-swift11:13
*** exploreshaifali has quit IRC11:14
*** X019 has quit IRC11:24
*** tdasilva has quit IRC11:28
*** leopoldj has joined #openstack-swift11:29
*** cdelatte has joined #openstack-swift11:36
*** delattec has joined #openstack-swift11:36
*** marcusvrn_ has joined #openstack-swift11:39
*** tdasilva has joined #openstack-swift11:41
*** dmorita has quit IRC11:42
manish_mattoliverau: i tried that by setting values for cert_file and key_file in proxy configuration, but this is not working :(11:45
*** addnull has quit IRC11:50
*** jordanP has quit IRC11:56
*** jordanP has joined #openstack-swift12:00
manish_mattoliverau: i do not have proxy.crt or proxy.key at location /etc/SWIFT12:01
manish_mattoliverau: from where i can download this?12:01
*** ppai has quit IRC12:05
mattoliveraumanish_: the cert is an SSL cert and the key is the key file you used to generate it. If your testing you can just create a self signed one, Google for openssl self signed cert. Sorry for slow responses it's 11pm here so not really awake :p12:05
*** mkollaro has quit IRC12:05
*** mahatic has joined #openstack-swift12:16
*** ppai has joined #openstack-swift12:17
*** openstackgerrit has quit IRC12:19
*** openstackgerrit has joined #openstack-swift12:21
*** foexle_ has joined #openstack-swift12:21
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-swiftclient: Updated from global requirements  https://review.openstack.org/8925012:21
*** SkyRocknRoll has quit IRC12:22
*** foexle has quit IRC12:23
openstackgerritA change was merged to openstack/python-swiftclient: Replaces Stacktraces with useful error messages.  https://review.openstack.org/12540712:24
*** miurahr has joined #openstack-swift12:28
*** miqui has joined #openstack-swift12:34
*** openstackgerrit has quit IRC12:34
*** openstackgerrit has joined #openstack-swift12:35
*** miurahr has quit IRC12:45
*** miurahr has joined #openstack-swift12:48
*** aix has joined #openstack-swift12:50
*** ppai has quit IRC12:51
manish_mattoliverau: Thank u so much..it is working now :)12:53
*** miurahr has quit IRC12:55
*** miurahr has joined #openstack-swift12:56
*** manish_ has quit IRC13:00
*** elambert has joined #openstack-swift13:03
*** elambert has quit IRC13:08
*** miurahr has quit IRC13:09
*** devkulkarni has joined #openstack-swift13:36
*** jyoti-ranjan has quit IRC13:38
*** jyoti-ranjan has joined #openstack-swift13:39
*** mkollaro has joined #openstack-swift13:40
*** dmsimard_away is now known as dmsimard13:42
*** k4n0 has quit IRC13:51
*** nosnos has quit IRC14:04
*** nosnos has joined #openstack-swift14:05
*** nosnos has quit IRC14:09
*** annegent_ has joined #openstack-swift14:25
*** silor has joined #openstack-swift14:26
*** lpabon has joined #openstack-swift15:08
openstackgerritJean-Daniel Bonnetot proposed a change to openstack/swift: This is a commit test. You can ignore it.  https://review.openstack.org/13117015:09
*** devkulkarni has left #openstack-swift15:27
*** zaitcev has joined #openstack-swift15:27
*** ChanServ sets mode: +v zaitcev15:27
*** abhirc has joined #openstack-swift15:30
*** kyles_ne has joined #openstack-swift15:39
*** kyles_ne has quit IRC15:39
*** kyles_ne has joined #openstack-swift15:40
*** gyee has joined #openstack-swift15:46
acolesclayg: hmm, i think that if os-storage-url has been set then it should never get replaced with something that auth (or a reauth) returns - that can lead to surprises15:57
acolesclayg: if os-storage-url has not been set, then use whatever url is returned by each auth attempt. is that same as what you said ? i hope so15:58
acolesclayg: btw, i can see i'm going to be rebasing to use your assert_requests thing15:59
*** leopoldj has quit IRC16:00
*** CaioBrentano has joined #openstack-swift16:01
*** annegent_ has quit IRC16:02
mahaticacoles, hi! https://review.openstack.org/#/c/125275/ Even after rebase on your patches, I'm still getting python33 error. Can you please take a look?16:16
acolesmahatic: ok i will take a look16:16
*** dmsimard is now known as dmsimard_away16:21
*** jyoti-ranjan has quit IRC16:26
*** jyoti-ranjan has joined #openstack-swift16:27
*** abhirc has quit IRC16:29
*** jyoti-ranjan has quit IRC16:32
notmynamegood morning, world16:34
*** lpabon has quit IRC16:36
*** tsg has joined #openstack-swift16:40
peluse_good morning16:48
peluse_tsg- how's progress w/you and torgomatic on the PUT path?16:48
*** exploreshaifali has joined #openstack-swift16:51
acolesnotmyname: peluse_ : expect you have seen this but just in case http://openstackparis.scality.com/16:53
*** jistr has quit IRC16:55
acolesmahatic: its a py3 change,  http://stackoverflow.com/questions/1073396/is-generator-next-visible-in-python-3-016:56
*** annegent_ has joined #openstack-swift16:56
peluse_acoles, yup.  I'll be there (not much of a choice actually)  :)16:57
*** dmsimard_away is now known as dmsimard16:58
torgomaticany core who wants easy review karma: https://review.openstack.org/#/c/130896/16:58
notmynamedone16:59
torgomaticthanks17:02
notmynameI'd like to bump the eventlet version to 0.9.16, but since we'll bump it way up for EC, no need to fight global requirements for now17:03
torgomaticindeed; EC branch has 0.15.2, and that even matches global requirements17:04
mahaticacoles, oh. But in the test, the only place (as i see it) where it needs to be taken care, it is done. ('builtins' usage). Should i be doing something else?17:04
*** kyles_ne_ has joined #openstack-swift17:07
*** kyles_ne has quit IRC17:07
mahaticacoles, my bad. The .next has to be changed i believe17:10
*** mkollaro has quit IRC17:11
acolesmahatic: yep, use next(thing) instead of thing.next()17:11
mahaticokay17:12
acolesmahatic: btw, i don't think you need that BUILTIN_OPEN stuff in test_service.py (that was my bad pastebin iirc)17:12
mahaticacoles, oh. that's required only for the main module?17:13
*** rmcall has joined #openstack-swift17:13
mahaticacoles, I mean i don't understand why it is required/not required17:14
acolesacoles: iirc i copied test_shell.py to create test_service.py and looks like i didn't then delete enough17:17
acolesmahatic: if you look in test_shell.pt to see how its used for mocking open() - you don't need it17:17
mahaticacoles, ah okay. Looked at test_shell.py. Thank you!17:19
*** wolsen|away is now known as wolsen17:20
mahaticacoles, also clayg commented asking why optparse is not used. I read about optparse but it does not fit in the context i believe?17:23
*** abhirc has joined #openstack-swift17:24
acolesmahatic: i think clayg's point is that the parse in shell.py could detect a bad (non-in) value. But this takes care of that now anyway https://review.openstack.org/#/c/126310/17:25
mahaticacoles, yeah exactly. I was going to point to that patch17:26
openstackgerritMahati proposed a change to openstack/python-swiftclient: Adds user friendly message when --segment-size is a non-integer  https://review.openstack.org/12527517:32
*** shri has joined #openstack-swift17:36
*** kyles_ne_ has quit IRC17:44
*** kyles_ne has joined #openstack-swift17:44
*** lpabon has joined #openstack-swift17:45
openstackgerritMahati proposed a change to openstack/python-swiftclient: Adds user friendly message when --segment-size is a non-integer  https://review.openstack.org/12527517:47
*** IRTermite has quit IRC17:59
*** annegent_ has quit IRC18:00
*** rmcall has quit IRC18:00
*** rmcall has joined #openstack-swift18:01
claygacoles: yeah i agree on os_storage_url - i was acctually thinking about that on friday but got distracted with the ssync/object-sysmeta thing18:02
claygdidn't get a change to look at things over the weekend18:02
claygwhich is a good change18:02
openstackgerritMichael Barton proposed a change to openstack/swift: reject problematic object names  https://review.openstack.org/13123318:06
acolesclayg: about the sysmeta/ssync thing, agree the test doesn't work, but raise interesting question as to what should happen18:09
claygacoles: yeah, idk - I think we should so something that says object system meta doesn't really work yet18:11
acolescayg: in same splitbrain scenario, ssync will (i think) take a t0.data, update its time to that of a t2.meta, and then put the composite over a t1.data18:11
acolesclayg:^^18:11
acolesclayg: so the sysmeta behavior is the same as for the object data, no?18:12
claygacoles: yeah that's what's going on - i mean I wouldn't describe it was "update it's time" - but yeah you get a t2.data18:12
claygacoles: yeah i mean ssync only does PUTs18:12
claygredbo: wtf patch 13123318:14
redboI know right18:15
torgomaticoh good, that's the whole unicode normalization thing18:16
acolesclayg: seems to me that object sysmeta 'works' as much as object data does in that splitbrain situation18:16
claygtorgomatic: there's a whole *thing* for this!?18:16
zaitcevThank you Python 318:16
zaitcevFor your wise choices18:16
torgomaticclayg: yeah, it's sort of a huge mess18:16
zaitcevI mean Guido18:16
torgomaticclayg: https://docs.python.org/2/library/unicodedata.html#unicodedata.normalize18:17
torgomaticlooks like maybe Python is doing some normalization stuff... hard to say though18:17
claygacoles: oh interesting, so the t0.data swallows the t1.data when it pushes the t0.data with the t2.meta timestamp - fuuuuu18:18
redbosome sort of normalization is my assumption, though I thought you had to opt in to that18:19
torgomaticyeah, me too18:19
claygbah, who thought unicode was a good idea - strings are bytes with encodings, deal with it18:21
torgomaticwait a minute... your example string is wacky I think18:21
*** exploreshaifali has quit IRC18:21
torgomatic'\xed\xa0\xbc\xed\xbc\xb8' is 6 bytes... I thought UTF8 only went up to 4- or 5-byte sequences18:21
torgomaticwikipedia says 4-byte, and that's on the internet so you know it's trustworthy18:22
torgomaticor maybe I'm dumb... let me regroup and try again18:23
claygtorgomatic: well redbo said it was two utf-8 code points?18:24
torgomaticclayg: yeah, it is, but it decodes to a thing that's only one codepoint long... so what the heck is going on there?18:25
openstackgerritClay Gerrard proposed a change to openstack/python-swiftclient: better capture output  https://review.openstack.org/13123818:25
torgomatic'\xed\xa0\xbc\xed\xbc\xb8'.decode("utf-8")   --->   u'\U0001f338'18:25
acolesclayg: i believe so. here's a very similar probe test for the .data side of the story - will fail with ssync and post-as-copy http://paste.openstack.org/show/125476/18:25
*** IRTermite has joined #openstack-swift18:28
*** IRTermite has quit IRC18:30
torgomatichuh, looks like those two characters are Unicode surrogates, which is a thing that I just now learned exists18:30
*** IRTermite has joined #openstack-swift18:30
claygacoles: yeah ok, so ssync and post-as-copy don't really play well together either18:30
*** IRTermite has quit IRC18:31
claygacoles: we have too many options - we need to get back to one way to do posts, and then think real hard about how we're going to get back on track moving away from rsync18:31
claygtorgomatic: lol18:31
*** IRTermite has joined #openstack-swift18:31
acolesclayg: yeah, and that test will fail for ssync and post-whichever-way18:32
torgomaticokay, so apparently Unicode has surrogate codepoints, and they always come in pairs18:32
torgomatic(at least in valid Unicode strings)18:32
claygwell but it's a slightly different failure, with post-as-copy you're setting a scenario where the old data is inaccessble during the POST which is sort of a knonw limitation of post-as-copy18:33
torgomaticand the surrogate pair is used together to indicate some other codepoint with a value above 2^1618:33
claygacoles: on the other side ssync's handling of .meta files is sorta scary where the replication eats the t1.data - if it happens during the client request... well i'm not sure it's better; but i'm not really surprised18:34
acolesclayg: true. my point was more that ssync+fast-post will fail that test18:34
torgomaticso this is some hack to fit all of Unicode into UTF-16, and someone took those magic codepoints and encoded them into UTF-818:34
claygacoles: but I'm definately left with the notion that ssync and fast-post are not friends18:34
claygacoles: sorry, already knew that - do you think that somehow makes the situation with object sysmeta "better"?18:35
*** annegent_ has joined #openstack-swift18:35
claygacoles: imho it fails basically the same way that rsync+post-as-copy fails?18:35
*** annegent_ has quit IRC18:36
claygacoles: so here's my final thoughts after the weekend - object sysmeta persistance in the face of POST has no strong guarante unless you're running rsync and fast-post18:37
*** geaaru has quit IRC18:38
claygacoles: I don't see how we can extend that to work to post-as-copy; the whole notion stands in the face of the obvious post-as-copy race that we try to sweep under the rug18:38
claygacoles: so our best bet is to get container-updates-on-post working, and deprecate post-as-copy, then make ssync sync .meta updates without transfering the whole object18:39
acolesclayg: no, not "better", but consistent in sense that if you do an object post-as-copy while the newest .data are unavailable, then replication (ssync or rsync) will result in losing the newset data, and along with it you lose the sysmeta that you PUT with that data18:39
claygand then we get to say "object sysmeta persists across a POST"18:39
claygacoles: ok, so your target for "good enough to say object sysmeta persists across POSTs" is *just* to fix ssync and .meta replication?  cause I think fast-post is sorta nutered right now, and basically no one is running ssync, so it seems like a semantic victory at best (IMHO)18:41
acolesclayg: err, no, maybe our wires are crossing18:42
claygacoles: heh - well we'll get to hash it out over beers next week right!  :D18:42
acolesclayg: i guess i'm just thinking that 'weakness' in the obj sysmeta is also true for the obj data. and that both could od with fixing :)18:43
acolesod -> do18:44
claygacoles: that's the ticket!  fix everything!18:44
acolesclayg: right, its just a matter of time and sufficient monkeys, and we'll get there :D18:44
* peluse_ works for bananas18:45
acolespeluse_: lol18:46
acolesclayg: i gotta run, sick wife, lets tackle it over beer next week18:47
redbotorgomatic: it's two 3-byte utf-8 codepoints, which represent '\ud83c\udf38', which I guess python squashes because surrogates.18:48
claygacoles: k, well i'm going to look at the contaienr-updates on POST spec that'd you've been working on - at first glance it seemed like we might be able to reduce scope some18:48
torgomaticredbo: yep, so some jerk took a UTF-16 string, went codepoint-by-codepoint and encoded them as UTF-8, concatenated the result, and used that as an object name18:48
torgomaticor something like that18:49
redboI think it was an emoji18:49
torgomatichttp://stosberg.net/unicode/cherry-blossom/codepoint/127800/18:49
torgomaticyup18:49
redbomy official position is that none of our customers are jerks18:49
torgomaticbut still, one can encode that as UTF-8 without being dumb18:49
claygacoles: specifically I don't think we need to have a depencdency on the generalized multiple .meta solution as much as just special case content-type18:50
torgomatichehe18:50
acolesclayg: ok, iirc i'd ended up thinking i needed to figure out the general case so i'd love some other input, i ended up down a bit of a rathole18:51
* acoles really going now18:51
*** acoles is now known as acoles_away18:52
openstackgerritClay Gerrard proposed a change to openstack/python-swiftclient: better capture output  https://review.openstack.org/13123819:03
*** tdasilva has quit IRC19:03
*** aix has quit IRC19:13
redbois matching surrogates in utf-8 going to be tough?19:15
redboseems like you'd almost need a utf8 decoder19:16
*** nellysmitt has joined #openstack-swift19:16
*** jordanP has quit IRC19:24
torgomaticredbo: maybe... looks like Python uses surrogates internally sometimes depending on how it's compiled, so it might be too ugly to be worth doing19:24
dmsimardHey guys, just a random question. Anyone familiar with S3QL with Swift ? How has it worked for you ? https://bitbucket.org/nikratio/s3ql/overview19:25
redbomaybe we should limit object names to 7-bit ascii19:26
torgomaticnow we're talkign19:30
*** mdorman has joined #openstack-swift19:30
mdormancan anyone recommend a good reference for configuring swift with a backend on ceph object store?19:34
claygmdorman: you should look at radosgw - it's not really affiliated with the swift project19:36
mdormanright.  but isn’t there a way to run the native openstack swift service, but just backend the storage through radosgw?19:36
mdormanor am i missing something here?19:36
portanteclayg: there is also: https://github.com/enovance/swift-ceph-backend19:38
claygmdorman: there was at least one attempt I'm aware of -> https://github.com/enovance/swift-ceph-backend <- decidely *not* radosgw, YMMV19:38
portantemdorman: ^^^19:38
claygportante: you lurk!19:38
portante;)19:38
mdormanyeah i have heard of that, too.19:38
* portante these are not the droids you are looking for ...19:39
mdormani thought there was a way to backend OS swift directly on radosgw…  so you get the benefits of librados, etc.  but i guess maybe i misunderstood what i was looking at19:40
*** exploreshaifali has joined #openstack-swift19:41
*** marcusvrn_ has quit IRC19:43
*** marcusvrn_ has joined #openstack-swift19:45
*** nellysmitt has quit IRC19:51
*** silor has quit IRC19:52
*** nellysmitt has joined #openstack-swift19:59
*** exploreshaifali has quit IRC20:13
*** kyles_ne has quit IRC20:16
*** kyles_ne has joined #openstack-swift20:16
*** lpabon has quit IRC20:17
*** kyles_ne has quit IRC20:18
*** kyles_ne has joined #openstack-swift20:18
*** kyles_ne has quit IRC20:19
*** kyles_ne has joined #openstack-swift20:19
*** mahatic has quit IRC20:20
*** fifieldt_ has quit IRC20:22
*** fifieldt__ has joined #openstack-swift20:22
portantemdorman: I believe that is  https://github.com/enovance/swift-ceph-backend20:34
portantethat use librados, no?20:34
*** CaioBrentano has quit IRC20:35
portantethat uses librados, no?20:35
mdormanunsure.  my understanding was not, but maybe that’s wrong.20:35
portanteI don't think radosgw is a 1-to-1 replacement for swift, nor is the above swift-ceph-backend a 1-to-1 replacement for the radosgw20:35
mdormanright20:36
*** svetmy has quit IRC20:42
*** svetmy has joined #openstack-swift20:42
portantemdorman: it is doing an "import rados" which is the librados client, see https://ceph.com/docs/v0.79/rados/api/python/20:50
mdormannice.   well that’s encouraging20:51
notmynameswift design summit sessions pushed to sched http://kilodesignsummit.sched.org/overview/type/swift20:53
*** nellysmitt has quit IRC21:10
mattoliveraunotmyname: yay, nice work! Lots of talking on Thursday and Friday :)21:14
notmynamemattoliverau: and monday-wednesday ;-)21:14
mattoliverauOh and good morning all21:15
notmynamehi!21:15
goodeshello21:21
goodesis there any reason why adding a field to each entry of container list should not be done e.g. if I wanted to add info about the encryption of each file, is there a reason why not to add it to the container list response?21:24
mattoliverauFrom a middleware? Adding to the standard output or to the json/XML output?21:28
*** abhirc has quit IRC21:29
goodessorry, from within a middleware, intercepting a container list request21:29
goodesmattoliverau: I'm assuming from json response it should be safe, however just wanted to make sure I was not missing some legacy issue21:34
mattoliverauThere is nothing stopping you but you'd have to take into account the possibly returned list in json or XML format, and do it chucking the returned data cause you don't know the size of the list.21:36
goodesmattoliverau: thanks - sounds like lots of fun21:38
*** kyles_ne_ has joined #openstack-swift21:46
*** kyles_ne has quit IRC21:46
openstackgerritJay Bryant proposed a change to openstack/swift: Handle os.listdir failures in object-updater  https://review.openstack.org/12574621:50
*** dmsimard is now known as dmsimard_away22:07
*** tsg has quit IRC22:11
*** abhirc has joined #openstack-swift22:15
openstackgerritJay Bryant proposed a change to openstack/swift: Handle os.listdir failures in container-updater  https://review.openstack.org/12586422:29
*** mdorman has quit IRC22:29
*** gyee has quit IRC22:31
openstackgerritA change was merged to openstack/swift: Update Getting Started requirements versions  https://review.openstack.org/13089622:48
openstackgerritA change was merged to openstack/swift: Mention Python 2.7 in Getting Started guide  https://review.openstack.org/13089822:48
*** kyles_ne_ has quit IRC22:49
*** kyles_ne has joined #openstack-swift22:49
openstackgerritSamuel Merritt proposed a change to openstack/swift: WIP: EC PUT path  https://review.openstack.org/13034922:50
*** shri1 has joined #openstack-swift22:56
*** shri has quit IRC22:58
*** Dafna has quit IRC23:03
*** kyles_ne has quit IRC23:19
*** kyles_ne has joined #openstack-swift23:20
notmynameanyone know a way to generate a line graph from the CLI that makes prettier graphs than matplotlib?23:35
*** mkollaro has joined #openstack-swift23:41

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