Thursday, 2016-02-04

*** mrmoje has joined #openstack-swift00:00
*** haomaiwa_ has quit IRC00:01
*** mrmoje has quit IRC00:01
*** lcurtis has quit IRC00:01
*** haomaiwang has joined #openstack-swift00:01
*** baojg has joined #openstack-swift00:06
*** mrmoje has joined #openstack-swift00:06
*** baojg has quit IRC00:16
*** then3rd has joined #openstack-swift00:17
*** baojg has joined #openstack-swift00:18
*** mingdang1 has joined #openstack-swift00:18
then3rdDumb question.. I can't seem to remember or locate the swift api url that reports the version number. Anyone know what I'm thinking of?00:19
*** PsionTheory has quit IRC00:19
timburkethen3rd: /info00:19
*** nadeem has quit IRC00:19
then3rdperfect, thank you. I was looking right at it.00:20
*** mingdang1 has quit IRC00:25
*** mrmoje has quit IRC00:27
*** mrmoje has joined #openstack-swift00:29
*** bill_az has quit IRC00:31
*** asettle has joined #openstack-swift00:39
*** chlong has joined #openstack-swift00:40
*** mingdang1 has joined #openstack-swift00:43
*** takashi has joined #openstack-swift00:45
*** daemontool has joined #openstack-swift00:47
*** daemontool_ has quit IRC00:48
*** mingdang1 has quit IRC00:54
*** zhill has quit IRC00:57
*** haomaiwang has quit IRC01:01
*** jamielennox is now known as jamielennox|away01:01
*** haomaiwang has joined #openstack-swift01:01
rickyremI'm running the kilo release of Swift. I have 2 proxies, but only one of them is connecting to rabbitmq01:11
rickyremDo any of your have any pointer on what the issue could be?01:12
zaitcevSwift connecting to Rabbit... what?01:12
zaitcevWhat middleware do we have that does it? Not recon, surely.01:12
rickyremOh, ceilometer01:13
zaitcevOh, right. Thanks01:13
zaitcevHmm...01:13
rickyremI diff'ed the configs and they look the same01:13
rickyremboth servers had their services installed via rpm01:14
zaitcevUnfortunately, I'm fairly clueless about Ceilometer. I don't even know if it has any agent processes or if middleware talks to it directly, on the context of Swift proxy.01:15
zaitcevI suppose asking at #rdo may help, but I'm not sure01:16
claygis the client facing traffic hitting both of them - what are you doing for load balancing01:16
rickyremhaproxy as the balancer01:17
rickyremand yes, the logs show both servers are getting hit01:17
rickyremzaitcev: ill keep in mind that I could go there01:18
claygand how are you deciding that only one of them is connected to rabbit - some sort rabbitmqctl command to list connections?01:18
rickyremproxy1 is the only one that shows connection  when running `ss -plant | grep 5672`. So then I went into the rabbitmq admin panel and saw that proxy2 wasn't listed as a connection either.01:20
*** Jeffrey4l has joined #openstack-swift01:22
*** asettle has quit IRC01:24
zaitcevI'd look at firewalls first. What if firewall-cmd screwed up...01:25
rickyremFirewalld isn't running and iptables has no rules.01:27
rickyremWell i mean the only rules are accept everything.01:27
*** garthb has quit IRC01:27
zaitcev  self._notifier = oslo_messaging.Notifier(oslo_messaging.get_transport(cfg.CONF, url=conf.get('url')), publisher_id='ceilometermiddleware', .....)01:33
zaitcevmy, my01:34
zaitcevSo it is fairly simple after all. All the connection-making stuff is buried inside Oslo.01:34
rickyremohhh, gotcha01:35
rickyremWhere is that line located?01:35
zaitcevhttps://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L11101:35
rickyremAgh, I was looking for that in the Swift project.01:36
rickyremThis makes more sense now01:36
zaitcevI wanted to ask to make sure if the middleware is actually in the pipeline in proxy-server.conf, but you said you compared all configs01:36
rickyremCorrect01:36
zaitcevpython-ceilometermiddleware.noarch is a separate RPM01:37
zaitcevat this point I'd look at proxy processes with lsof, to see if it even tries01:38
zaitcevIIRC AMQP runs over TCP for us01:38
zaitcevs/for us/in OpenStack/01:38
kota_back to online :)01:39
*** Jeffrey4l has quit IRC01:39
rickyremI verified that I didn't miss that RPM, and the egg is there. But I would assume it would have complained about the missing egg.01:41
rickyremI'll see what I can find with lsof now01:41
zaitcevBy it you mean proxy server process, right?01:41
rickyremCorrect01:42
zaitcevSadly /info does not show currently active pipeline01:45
rickyremI'm not seeing anything in lsof to show that it is attempting to bind to a socket.01:50
zaitcevOslo could try once at start, then sit on the error silently.01:50
*** lyrrad has quit IRC01:51
*** klrmn has quit IRC01:51
rickyremThat's what i'm afraid of01:52
*** mgarza_ has joined #openstack-swift01:55
zaitcevCeilometer does this _log_and_ignore_error() thing with except Exception. It's supposed to log "An exception occurred processing the API call: %s", but I hit situations wen log wasn't visible. And in fact Ceilometer does _LOG = logging.getLogger(__name__), which has a ton of reasons for not working.01:57
zaitcevIn Swift all these things are muted unless they use get_logger()01:57
zaitcevThere's some kind of patching through and setting priorities that getLogger alone does not do01:58
rickyremI see what you're talking about02:00
*** haomaiwang has quit IRC02:01
*** haomaiwa_ has joined #openstack-swift02:01
zaitcevMy preferred approach to this problem is to identify people who use except Exception, then meet up with them and beat them up with a PVC pipe02:02
zaitcevIt's not solving the issue of getLogger not working though02:02
zaitcevWell, except in this case the exception would patch up from middleware into our code, where we log it properly.02:03
*** klrmn has joined #openstack-swift02:04
zaitcevOne can verify if that thing fails by adding a little code snipped right ander _LOG, which writes the exception into /tmp/debugdump or whatnot...02:05
rickyremRight, and I'm trying to trace down any remants of that02:06
rickyremI'll see if I can do that02:06
*** baojg has quit IRC02:07
zaitcevJohn always tells me to use "import q" to do that, and I never get around to learn q.02:07
openstackgerritJames Nzomo proposed openstack/python-swiftclient: Fix segmented upload to pseudo-dir via <container>  https://review.openstack.org/27172802:07
rickyremI had never seen q before. Looks cool02:09
*** baojg has joined #openstack-swift02:10
*** klrmn has quit IRC02:12
*** Mingyu has quit IRC02:12
*** Mingyu has joined #openstack-swift02:13
rickyremThanks a lot for your help zaitcev02:16
zaitcevrickyrem: sorry I can't do more, working here...02:16
rickyremIt's fine, I'll let you know if I find anything significant02:17
*** alejandrito has joined #openstack-swift02:20
alejandritohi gyus, quick question, reading > https://blueprints.launchpad.net/swift/+spec/storage-tiers02:21
alejandritoits not clear if storage tiers is supported by swift through storage policies02:21
alejandritocan someone clarify ?02:21
alejandritothx ^_^02:21
*** baojg has quit IRC02:23
*** baojg has joined #openstack-swift02:23
*** jamielennox|away is now known as jamielennox02:32
openstackgerritMerged openstack/python-swiftclient: Fix intermittent fail of test_delete_bulk_account  https://review.openstack.org/27458102:48
*** baojg has quit IRC02:51
*** baojg has joined #openstack-swift02:52
*** thurloat_isgone is now known as thurloat02:54
*** davechen has joined #openstack-swift02:59
*** davechen has left #openstack-swift03:00
*** haomaiwa_ has quit IRC03:01
*** haomaiwang has joined #openstack-swift03:01
*** baojg has quit IRC03:02
*** baojg_ has joined #openstack-swift03:02
*** baojg_ has quit IRC03:05
*** jamielennox is now known as jamielennox|away03:06
*** baojg has joined #openstack-swift03:06
*** baojg has quit IRC03:09
*** baojg has joined #openstack-swift03:09
*** rickyrem has quit IRC03:09
*** jamielennox|away is now known as jamielennox03:11
*** sanchitmalhotra has joined #openstack-swift03:14
*** baojg has quit IRC03:16
*** baojg has joined #openstack-swift03:16
*** alejandrito has quit IRC03:17
janonymousnotmyname: Hi, i would work on it this weekend. I was very busy this month due to some releases in ofc so could not got much time to contribute, but from this weekend i am looking forward to start contributing :)03:18
openstackgerritMerged openstack/swift: Allow IPv6 addresses/hostnames in StatsD target  https://review.openstack.org/27099103:23
*** klrmn has joined #openstack-swift03:27
*** mrmoje has quit IRC03:33
*** thumpba has joined #openstack-swift03:34
*** Jeffrey4l has joined #openstack-swift03:42
*** daemontool has quit IRC03:46
*** daemontool has joined #openstack-swift03:46
*** baojg has quit IRC03:46
*** links has joined #openstack-swift03:49
*** thumpba has quit IRC03:53
*** thumpba has joined #openstack-swift03:54
*** baojg has joined #openstack-swift03:54
*** esker has quit IRC03:55
*** haomaiwang has quit IRC04:01
*** haomaiwang has joined #openstack-swift04:01
*** esker has joined #openstack-swift04:05
*** mgarza_ has quit IRC04:06
*** dmorita has quit IRC04:07
*** briancurtin has quit IRC04:11
*** thumpba_ has joined #openstack-swift04:12
*** cppforlife_ has quit IRC04:12
*** jamielennox is now known as jamielennox|away04:12
*** thumpba has quit IRC04:13
*** kaleta has quit IRC04:13
*** jroll has quit IRC04:13
*** CrackerJackMack has quit IRC04:13
*** kaleta has joined #openstack-swift04:13
*** chlong has quit IRC04:13
*** dosaboy_ has quit IRC04:14
*** CrackerJackMack has joined #openstack-swift04:14
*** jroll has joined #openstack-swift04:14
*** dosaboy has joined #openstack-swift04:15
*** silor has joined #openstack-swift04:18
*** amit213 has quit IRC04:19
*** BAKfr has quit IRC04:19
*** dfg_ has quit IRC04:19
*** tristanC has quit IRC04:19
*** dfg has joined #openstack-swift04:19
*** tristanC has joined #openstack-swift04:19
*** BAKfr has joined #openstack-swift04:20
*** briancurtin has joined #openstack-swift04:20
*** cppforlife_ has joined #openstack-swift04:23
*** mingdang1 has joined #openstack-swift04:24
*** thumpba_ has quit IRC04:25
*** chlong has joined #openstack-swift04:28
*** haomaiwang has quit IRC04:28
*** mingdang1 has quit IRC04:28
*** asettle has joined #openstack-swift04:40
*** bkumar has joined #openstack-swift04:50
openstackgerritMichael Barton proposed openstack/swift: go: fix some range parsing problems  https://review.openstack.org/27603905:08
*** DericHorn-HP has joined #openstack-swift05:10
*** klrmn has quit IRC05:14
*** DericHorn-HP has quit IRC05:17
*** haomaiwa_ has joined #openstack-swift05:20
*** asettle has quit IRC05:26
openstackgerritTim Burke proposed openstack/python-swiftclient: Add --get <key> option to `swift capabilities` / `swift info`  https://review.openstack.org/27604305:27
*** asettle has joined #openstack-swift05:28
*** baojg has quit IRC05:46
*** dmorita has joined #openstack-swift05:50
*** dmorita has quit IRC05:55
*** dmorita has joined #openstack-swift05:59
*** haomaiwa_ has quit IRC06:01
*** haomaiwang has joined #openstack-swift06:01
*** baojg has joined #openstack-swift06:02
*** zaitcev has quit IRC06:12
*** mingdang1 has joined #openstack-swift06:13
*** mingdang1 has quit IRC06:17
*** haomaiwang has quit IRC06:18
*** haomaiwang has joined #openstack-swift06:19
*** asettle has quit IRC06:26
*** proteusguy__ has quit IRC06:27
*** zhill has joined #openstack-swift06:29
*** tongli has quit IRC06:30
*** zhill has quit IRC06:39
*** proteusguy__ has joined #openstack-swift06:40
*** mingdang1 has joined #openstack-swift06:45
*** trifon has joined #openstack-swift06:49
*** SkyRocknRoll has joined #openstack-swift06:51
openstackgerritKota Tsuyuzaki proposed openstack/swift: Refactor versioned_writes middleware  https://review.openstack.org/20931506:57
*** tdasilva has quit IRC07:00
*** haomaiwang has quit IRC07:01
*** haomaiwa_ has joined #openstack-swift07:01
*** Jeffrey4l has quit IRC07:19
*** tdasilva has joined #openstack-swift07:24
*** Jeffrey4l has joined #openstack-swift07:32
*** eranrom has joined #openstack-swift07:34
*** dmorita has quit IRC07:38
eranromGot a fast-post question. The spec says (under: proposed changes->Container-server): "Note that each object will continue to have only one row in the database table." Does this mean that if I delete an object merge_items would find the object row, mark it as deleted an 'move' its location timestamp-wise?07:39
eranromIf I understand the code correctly, this is indeed what is happening. That is, the original object row is deleted, and a new one is added at the 'bottom' of the table, where lower in the table means later timestamp. Can someone pls confirm?07:42
*** zhill has joined #openstack-swift07:42
*** joeljwright has joined #openstack-swift07:50
*** ChanServ sets mode: +v joeljwright07:50
*** joeljwright has quit IRC07:50
*** gyee has quit IRC07:53
*** mvk_ has quit IRC07:57
*** cbartz has joined #openstack-swift07:58
*** haomaiwa_ has quit IRC08:01
*** haomaiwa_ has joined #openstack-swift08:01
*** ChubYann has quit IRC08:07
*** zhill has quit IRC08:09
*** rledisez has joined #openstack-swift08:10
*** mingdang1 has quit IRC08:17
*** mvk_ has joined #openstack-swift08:26
*** jmccarthy has joined #openstack-swift08:27
*** jistr has joined #openstack-swift08:29
*** geaaru has joined #openstack-swift08:34
*** nakagawamsa has joined #openstack-swift08:46
*** nakagawamsa has quit IRC08:52
*** jordanP has joined #openstack-swift08:52
*** lpabon has joined #openstack-swift09:00
*** haomaiwa_ has quit IRC09:01
*** haomaiwa_ has joined #openstack-swift09:01
*** baojg has quit IRC09:04
*** mrmoje has joined #openstack-swift09:07
*** baojg has joined #openstack-swift09:07
*** admin0 has joined #openstack-swift09:09
*** Mingyu has quit IRC09:13
*** admin0 has quit IRC09:13
*** ChanServ sets mode: +v tdasilva09:14
*** Mingyu has joined #openstack-swift09:14
*** mrmoje has quit IRC09:15
*** jistr has quit IRC09:16
*** openstackgerrit has quit IRC09:17
*** mrmoje has joined #openstack-swift09:17
*** SkyRocknRoll has quit IRC09:17
*** openstackgerrit has joined #openstack-swift09:17
*** asettle has joined #openstack-swift09:18
*** asettle has quit IRC09:24
*** asettle has joined #openstack-swift09:25
*** admin0 has joined #openstack-swift09:26
*** asettle_ has joined #openstack-swift09:32
*** asettle has quit IRC09:32
*** lpabon has quit IRC09:32
tdasilvagood morning09:35
*** lpabon has joined #openstack-swift09:42
*** asettle_ is now known as asettle09:43
*** Jeffrey4l has quit IRC09:43
*** mrmoje has quit IRC09:47
*** mrmoje has joined #openstack-swift09:49
ntthi, I need to add a zone and a replica to a running swift cluster. Someone can help me please? I don't understand how can I add a replica09:52
nttActually I have only one node with one zone and replica = 109:52
*** lpabon has quit IRC09:56
*** ppai has joined #openstack-swift09:56
*** haomaiwa_ has quit IRC10:01
*** haomaiwang has joined #openstack-swift10:01
*** Jeffrey4l has joined #openstack-swift10:01
*** acoles_ is now known as acoles10:02
acoleseranrom: correct, delete creates a new10:06
*** dudi has joined #openstack-swift10:08
acoleseranrom: correct, delete creates a new row10:09
*** lpabon has joined #openstack-swift10:10
dudihello, can anybody tell me what should be the permissions for /etc/swift/ dir10:11
dudibecause its not creating /var/cache/swift folder when i start all swift services10:11
*** mingdang1 has joined #openstack-swift10:12
dudiaccount-server.conf : http://pastebin.com/y1tQq6AL10:12
*** lpabon has quit IRC10:16
acolesdudi /etc/swift should be owned by whatever user runs swift processes, in examples that is 'swift' user http://docs.openstack.org/developer/swift/development_saio.html#configuring-each-node10:20
acolesdudi: see also http://docs.openstack.org/developer/swift/development_saio.html#common-post-device-setup10:21
dudiswift creates it for me or should i create manually10:22
dudiok iys in ur link..thanks10:23
*** baojg_ has joined #openstack-swift10:24
*** baojg has quit IRC10:25
*** Jeffrey4l has quit IRC10:29
admin0ho wis the swift internal endpoint being used ?10:35
admin0* how is10:35
*** dudi has quit IRC10:36
*** baojg_ has quit IRC10:38
*** baojg has joined #openstack-swift10:45
eranromacoles: thanks10:50
acoleseranrom: hi! I just added further comment on patch 27096110:51
patchbotacoles: https://review.openstack.org/#/c/270961/ - swift - Container-Sync to perform HEAD before PUT object o...10:51
acoleseranrom: I have been trying to think of any downside to the change (wrt using row timestamp as the condition to sync or not) other than a delay10:52
*** baojg has quit IRC10:53
*** haomaiwang has quit IRC10:54
eranromacoles: looking11:02
*** dabukalam has joined #openstack-swift11:10
*** etienneme has joined #openstack-swift11:11
*** baojg has joined #openstack-swift11:13
openstackgerritvenkatamahesh proposed openstack/swift: Use uppercase 'S' in word "OpenStack"  https://review.openstack.org/27616411:18
* tdasilva wonders if there will be a pep rule on how to spell "OpenStack" correctly :P11:20
acolestdasilva: s/pep/PEP/ :)11:26
*** oshritf has joined #openstack-swift11:27
*** sanchitmalhotra has quit IRC11:29
tdasilvalol11:29
tdasilvasorry!11:29
eranromacoles: Reviewing your comment with oshritf we are not sure what is the bottom line - that is - do you think that the delete scenario exposes a correctness problem or merely an upoptimized order of replication11:29
acoleseranrom: no. my point is that as far as I can see the only change in "observed behaviour" with the patch is that some sync actions may be delayed until a container update occurs at the source, because the container's view of the latest object timestamp may be stale.11:33
acoleseranrom: but AFAICT the change would never cause data to be sync'd that would, on master, not be sync'd. i.e. even if a later delete has not yet updated the container, the sync process would still not actually transmit the older data to the destination. which is good!11:35
oshritfacoles: right, in the case of delete in t2, at t1 the object may be synced to remote (in case it was not synced before) and later deleted (since no get was performed for latest)11:36
*** haomaiwa_ has joined #openstack-swift11:37
acolestdasilva: more seriously, I am forming the view that with a project so large and with so many contributors, there is little point in fixing things that are not verified by a test of some kind. Particularly things that make no difference to the behaviour of the code or the correctness of the documentation.11:37
*** SkyRocknRoll has joined #openstack-swift11:39
tdasilvaacoles: yeah, that was sort of my point...this kinda of changes are only "valid" until the next contributor who has no idea of this "rule" writes some new doc and spells "Openstack"11:39
tdasilvaam I supposed to -1 that?? sounds dumb11:39
acolesoshritf: well I read it differently...in the case of delete at t2, when the sync process finds the row at t1, it will issue the GETs for the object, but the the GETs will return 404 (because the object has been deleted at t2), so no data gets sync'd (which is a good thing)11:39
acolestdasilva: it reminds me of the saying "tidying your house while the kids are growing is like clearing the drive while its still snowing"11:41
acolestdasilva: i know what you mean...-1, ignore, defer to notmyname ??11:41
tdasilvaacoles: yeah, i mean...i won't even think of looking for that..it's just a waste of time11:42
tdasilvaand i feel bad for whoever is sending the patch because he is sending for all projects11:42
oshritfacoles: so your suggestion is not to skip GET to "sync" local services before checking with remote?11:43
acolestdasilva: looks like its all in doc files so probably little risk of generating merge conflicts, but then I see "swift" and "Swift" in same docs...so if we really care...11:46
tdasilvahehe...oh boy..here we go11:46
eranromtdasilva,: How about -1 conditioned on adding a test?11:46
oshritfacoles: in phase 2 of container sync, where iterating over all objects, the "local sync" occurs #of services times. This is what we wanted to save - since they all check all objects, at least one will have the most updated data. However, "local sync" is better in cases where they are rapid changes, such as rapid updates or updates+deletes11:47
acoleseranrom: sounds very reasonable !)11:47
tdasilvaeranrom: adding a test on word spelling?11:47
*** jcook_ has quit IRC11:48
eranromtdasilva,: Is that such a bad idea? Wll not every word just - you know - OpenStack / Swift11:48
eranroms/Wll/Well11:48
eranromtdasilva,: PEP rule11:48
acoleseranrom: tdasilva the test would have to differentiate between text and urls11:48
*** bkumar has quit IRC11:50
tdasilvaeranrom: PEP rule would make sense so we don't have to deal with it again, but yeah, acoles has a good point11:50
acolesoshritf: ok, I am concerned that my comment has caused confusion! I think I am agreeing with you. "local sync" (i.e. GET to all local objects before comparing local time with remote time, i.e. master branch) will result in a local change sometimes being sync'd sooner. But, yes, it is costly. And I think it is worth the introducing the potential delay in order to save the GETs. But I wanted to make sure you , eranrom and I11:52
acoles had the same understanding of that trade off.11:52
acolestdasilva: eranrom I think it needs a PTL executive decision and we should wake him right now ;)11:53
eranrom:-)11:53
tdasilvalol11:53
tdasilvait's only 22:53 in melbourne, he should be around11:54
tdasilva:D11:54
mahatichehe yes. but a spelling correct *and* a test, wouldn't that add to the code churn11:54
mahaticcorrection*11:55
eranromaolces: Great, so we are on the same page, and continue to work on the patch with the current logic: Do not perform local GET at all times.11:55
*** jistr has joined #openstack-swift11:56
acoleseranrom: yep. of course I reserve the right to change my mind ;)11:57
oshritf:)11:57
eranrom:-)11:57
*** resker has joined #openstack-swift11:58
*** haomaiwa_ has quit IRC12:01
*** esker has quit IRC12:01
*** haomaiwang has joined #openstack-swift12:01
*** ppai has quit IRC12:04
*** silor has quit IRC12:05
*** Guest44793 has quit IRC12:07
*** mingdang1 has quit IRC12:09
openstackgerritMerged openstack/swift: Fixing typo in unit test  https://review.openstack.org/27591712:10
*** asettle has quit IRC12:27
*** baojg has quit IRC12:28
*** baojg has joined #openstack-swift12:31
*** dmorita has joined #openstack-swift12:39
*** Mingyu has quit IRC12:40
*** Mingyu has joined #openstack-swift12:41
*** dmorita has quit IRC12:44
*** admin0 has quit IRC12:44
*** daemontool_ has joined #openstack-swift12:48
*** natarej_ has joined #openstack-swift12:49
*** kaleta_ has joined #openstack-swift12:50
*** mrmoje_ has joined #openstack-swift12:51
*** rledisez1 has joined #openstack-swift12:52
*** kaleta has quit IRC12:53
*** mrmoje has quit IRC12:53
*** rledisez has quit IRC12:53
*** SkyRocknRoll has quit IRC12:53
*** daemontool has quit IRC12:53
*** natarej has quit IRC12:53
*** kaleta_ is now known as kaleta12:53
*** SkyRocknRoll has joined #openstack-swift12:56
openstackgerritAlistair Coles proposed openstack/python-swiftclient: Support --os-identity-api-version option  https://review.openstack.org/27571912:57
*** daemontool_ has quit IRC12:58
*** mingdang1 has joined #openstack-swift12:58
oshritfacoles: Does it make sense to upload patch set 2 to the timestamp fix with moving the headers and body setting lines to after the exception handling? it might be easier to follow the flow12:59
*** haomaiwang has quit IRC13:01
*** haomaiwa_ has joined #openstack-swift13:01
*** mingdang1 has quit IRC13:02
*** admin0 has joined #openstack-swift13:03
acolesoshritf: do you mean patch 275147? I'll take a look13:03
patchbotacoles: https://review.openstack.org/#/c/275147/ - swift - Fix time-shifting of objects PUT with container-sync13:03
*** [1]eranrom has joined #openstack-swift13:03
oshritfacoles: yes, it's minor, but relates to the change...# Populate with newest object data                 headers = source_obj_info                 body = source_obj_iter                 for key in ('date', 'last-modified'):13:04
*** eranrom has quit IRC13:05
*** [1]eranrom is now known as eranrom13:05
*** kei_yama has quit IRC13:16
*** jcook_ has joined #openstack-swift13:19
*** baojg has quit IRC13:27
*** baojg has joined #openstack-swift13:28
mahaticacoles: hi, could I bug for a min?13:29
*** petertr7_away is now known as petertr713:34
acolesmahatic: go ahead13:38
*** david-lyle has quit IRC13:38
mahaticacoles: thanks. for the incomplete read issue here: https://github.com/openstack/swift/blob/feature/crypto/swift/common/middleware/encrypter.py#L115-115 -> since a close method can't be called (because it is not an iterable), I was thinking could we check on the content length and use it the etag calculatations..13:40
mahaticacoles: i.e. only when we hit the last chunk (determined by using content length), do we calculate etag and the subsequent things we are doing now.13:40
openstackgerritAlistair Coles proposed openstack/swift: Fix time-shifting of objects PUT with container-sync  https://review.openstack.org/27514713:42
acolesoshritf: ^^ I think that is better than moving the lines13:42
*** Jeffrey4l has joined #openstack-swift13:48
acolesmahatic: looking13:49
mahaticokay13:50
oshritfacoles: much better! thanks13:51
*** lpabon has joined #openstack-swift13:55
*** links has quit IRC13:56
*** haomaiwa_ has quit IRC14:01
*** haomaiwa_ has joined #openstack-swift14:01
*** SkyRocknRoll has quit IRC14:02
*** barra204 has quit IRC14:04
*** shakamunyi has joined #openstack-swift14:06
*** daemontool has joined #openstack-swift14:09
*** peyton_ has joined #openstack-swift14:18
*** peyton has quit IRC14:20
*** acoles is now known as acoles_14:23
petertr7Hi acoles_ , could I get your thoughts on something?14:27
*** acoles_ is now known as acoles14:29
*** wshao has joined #openstack-swift14:29
*** wshao has left #openstack-swift14:29
*** admin0 has quit IRC14:33
*** resker has quit IRC14:36
acolesmahatic: sorry I got called to a meeting14:37
acolesmahatic: its not a big deal, just slightly more defensive coding. Its perhaps unlikely, but if the reader counts bytes until they read exactly what they expect, then the reader may never call read() for the case when there is no more data to be read. In which case the code as it is never calculates the etag etc.Then the reader calls the footers_callback14:39
mahaticacoles: no problem!14:39
acolesand no footers have been prepared. So i just wonder if its safer to prepare the footers in the footers callback14:39
acolesmahatic: and maybe have a check there that all the data got consumed14:40
acolespetertr7: sure14:40
tdasilvawbhuber: around?14:40
petertr7Thanks. I'm interested in working on a new feature for python-swiftclient. I prepared a blueprint-like/doc with my plan. Could you have a look?14:40
petertr7https://docs.google.com/document/d/12jAgzSuoa3n57edVLAIecA_KTiSvHwusQS4XWjRScwc/edit14:40
*** admin0 has joined #openstack-swift14:41
mahaticacoles: alright, thanks. (will test it out by moving the code accordingly)14:44
acolespetertr7: so is the cache file stored locally or sent to swift?14:46
petertr7sent to swift14:46
petertr7I'm open to either14:46
petertr7but I think the x-delete-after header would help keep things clean14:47
petertr7otherwise the user's workspace will start filling up with cache files14:47
*** taane is now known as tanee14:48
petertr7I'm not a huge fan of updating this cache file for each successful segment, as the default max # of segments is 100014:48
petertr7that's 1000 uploads each time a segment upload is complete14:48
petertr7perhaps it can be batched14:48
acolespetertr7: whats your plan if the local file has changed since the cache got created - so the cached state is invalid?14:49
petertr7I'm not sure yet. perhaps save the timestamp in the cache when uploading starts14:50
petertr7and compare that when the upload is "continued"14:50
petertr7rewrite/delete the cache accordingly and start segmenting from 014:50
acolesright. are you aware of recent features added to retry uploads ? (commit d4157ce5) its a little different but related14:52
petertr7No I'm not. Let me check it out14:52
acolespetertr7: i think timburke and joelwright may give better feedback than me.14:53
petertr7Thanks acoles14:55
acolespetertr7: in terms of process, i would point out that launchpad blueprints don't work too well. you could write a swift-spec https://specs.openstack.org/openstack/swift-specs/readme_link.html - I advise keeping it short and simple :)14:56
petertr7Thanks acoles, I will do that. Was the doc I created tmi?14:56
acolespetertr7: no not tmi. a spec is not a "must" but it can provide a place for discussion since it goes through the usual gerrit review process. If you have code already then you could just propose a patch and have the discussion there14:58
petertr7acoles: oh I see. Thank you. I haven't started coding it yet. I wasn't sure how people felt about creating an extra file that gets put on swift14:58
*** ppai has joined #openstack-swift14:59
acolespetertr7: one thought - maybe if the cache file were local, it could be less automatic - like a "recovery file" that can be used with a --recovery option - so user gets more visibility of what's happening. but thats a CLI feature use case I guess.14:59
petertr7acoles: hmmm that's a good idea. it would resolve the issue of the file changing after an initial upload has started15:00
*** haomaiwa_ has quit IRC15:01
petertr7as the user will be able to simply delete the recovery file15:01
*** haomaiwang has joined #openstack-swift15:01
acolespetertr7: i think you have already identified one issue with caching the file in swift which is needing to do a read/modify/write of that object for every successful segment upload.15:01
acolespetertr7: i'm away for a bit15:02
petertr7okay. Thanks so much for your feedback acoles, it is much appreciated!15:02
openstackgerritOndřej Nový proposed openstack/swift: Howto check sanity of manpage in devel guide  https://review.openstack.org/27628015:03
*** trifon has quit IRC15:04
tdasilvaonovy: cool, TIL: http://fpaste.org/318456/98540145/15:09
*** Mingyu has quit IRC15:11
*** Mingyu has joined #openstack-swift15:12
onovyhmm15:12
onovyhttps://review.openstack.org/#/c/275406/ fixing this :)15:13
tdasilvaonovy: mmm, i broke the file on purpose, just so i could see warnings15:17
openstackgerritOndřej Nový proposed openstack/swift: Fixed manpages errors.  https://review.openstack.org/27540615:21
onovytdasilva: ah! :)15:21
*** acoles is now known as acoles_15:23
*** eranrom has quit IRC15:23
*** acoles_ is now known as acoles15:24
openstackgerritOndřej Nový proposed openstack/swift: Howto check sanity of manpage in devel guide  https://review.openstack.org/27628015:24
*** mgarza has joined #openstack-swift15:29
*** esker has joined #openstack-swift15:32
*** baojg has quit IRC15:33
*** silor has joined #openstack-swift15:34
*** arch-nemesis has joined #openstack-swift15:35
*** baojg has joined #openstack-swift15:37
*** jcook_ has quit IRC15:37
*** baojg has quit IRC15:37
openstackgerritMerged openstack/swift: Stop nesting functions unnecessarily  https://review.openstack.org/27592015:43
*** eranrom has joined #openstack-swift15:43
*** silor1 has joined #openstack-swift15:45
*** bjkeller has joined #openstack-swift15:47
*** silor has quit IRC15:47
*** silor1 is now known as silor15:47
oshritfacoles: if-modified-since accepts only "%a, %d %b %Y %H:%M:%S GMT" format?15:54
*** garthb has joined #openstack-swift15:55
*** eranrom has quit IRC15:59
*** haomaiwang has quit IRC16:01
*** haomaiwa_ has joined #openstack-swift16:01
*** petertr7 is now known as petertr7_away16:01
*** admin6 has joined #openstack-swift16:02
*** mrmoje_ has quit IRC16:03
*** petertr7_away is now known as petertr716:03
*** ppai has quit IRC16:03
*** mrmoje has joined #openstack-swift16:05
admin6Hi chat. I got hundreds of message like this one when rebuilding an erasure coding ring : RingValidationWarning: The partition 524287 has been assigned to duplicate devices [18, 19, 5, 12, 10, 8, 9, 7, 11, 4, 12, 5]16:05
glangehow many devices do you have in your ring?16:06
cschwedei was wondering the same…16:06
admin6Currently, only 2016:06
glangeit might not work very well with that few devices16:06
glangeadmin6: you might want to talk to clayg when he gets on -- he's worked on that16:07
admin6glange: ok thanks. I’ll try to catch him.16:09
*** lpabon has quit IRC16:10
*** chsc has joined #openstack-swift16:12
*** ppai has joined #openstack-swift16:16
*** nadeem has joined #openstack-swift16:21
*** admin6 has quit IRC16:21
*** esker has quit IRC16:23
*** david-lyle has joined #openstack-swift16:24
*** esker has joined #openstack-swift16:24
*** admin0 has quit IRC16:25
openstackgerritShashirekha Gundur proposed openstack/swift: change default ports for servers  https://review.openstack.org/27484016:27
*** mrmoje has quit IRC16:35
*** mrmoje has joined #openstack-swift16:36
*** mvk_ has quit IRC16:37
*** baojg has joined #openstack-swift16:38
openstackgerritDonagh McCabe proposed openstack/swift: Added links to API reference and usage guides  https://review.openstack.org/27634216:42
*** baojg has quit IRC16:44
*** zaitcev has joined #openstack-swift16:44
*** ChanServ sets mode: +v zaitcev16:44
*** petertr7 is now known as petertr7_away16:46
*** petertr7_away is now known as petertr716:59
*** haomaiwa_ has quit IRC17:01
*** haomaiwang has joined #openstack-swift17:01
*** gyee has joined #openstack-swift17:02
*** jistr has quit IRC17:02
*** zhill has joined #openstack-swift17:03
*** silor has quit IRC17:04
*** jordanP has quit IRC17:06
*** nadeem has quit IRC17:09
*** nadeem has joined #openstack-swift17:10
*** cbartz has quit IRC17:13
*** petertr7 is now known as petertr7_away17:14
timburkeacoles: d4157ce5 wasn't a feature, it was a fix. it worked like a year ago :(17:16
*** jistr has joined #openstack-swift17:16
*** jistr has quit IRC17:18
timburkepetertr7_away: i'm not opposed. how much can we trust that the file hasn't changed, though? if we can trust both content *and* mtime, it might be worth heading the segment destinations and comparing etag vs actual md5, similar to what's done for --skip-identical17:19
*** ppai has quit IRC17:19
timburkebetter yet: container listing with --prefix so we can get all the segments at once17:19
wbhubertdsailva: i'm here17:27
*** mrmoje has quit IRC17:32
*** lyrrad has joined #openstack-swift17:34
*** esker has quit IRC17:37
sgunduranyone know of any reported delays in jenkins - gate checks ?17:38
*** esker has joined #openstack-swift17:38
*** ho_away has joined #openstack-swift17:39
*** dmorita has joined #openstack-swift17:43
*** rledisez1 has quit IRC17:45
*** klrmn has joined #openstack-swift17:47
*** baojg has joined #openstack-swift17:50
*** amit213 has joined #openstack-swift17:55
*** amit213 has quit IRC17:55
*** amit213 has joined #openstack-swift17:56
*** eranrom has joined #openstack-swift17:58
*** baojg has quit IRC17:59
*** oshritf has quit IRC18:00
*** haomaiwang has quit IRC18:01
*** haomaiwang has joined #openstack-swift18:01
*** esker has quit IRC18:04
*** arch-nemesis has quit IRC18:05
*** arch-nemesis has joined #openstack-swift18:06
openstackgerritRichard Hawkins proposed openstack/swift: Add option for label to static web listings  https://review.openstack.org/26712318:15
openstackgerritTim Burke proposed openstack/python-swiftclient: Add --json option to `swift capabilities` / `swift info`  https://review.openstack.org/27638218:29
*** tongli has joined #openstack-swift18:31
*** Jeffrey4l has quit IRC18:35
*** ChubYann has joined #openstack-swift18:38
*** mrmoje has joined #openstack-swift18:40
*** ho_away has quit IRC18:45
*** petertr7_away is now known as petertr718:47
petertr7Hi timburke - thanks for the feedback18:48
petertr7timburke: my one concern is that if you're uploading a 0.5TB file, doing md5 checks on segments will take forever18:48
*** mrmoje has quit IRC18:50
timburkethat's fair. i suppose if we're doing listings like that, we're already assuming same mtime and same size (and same chunk size). might be enough to assume that if we see a segment, it's correct18:50
petertr7timburke: Would be safe to assume, with proper documentation, that the user should know this "recovery" option is for the same file and that it would be invalid if the file has changed?18:52
petertr7i.e. user attempts to upload file a.py using the --recovery flag. goes home for the night and the next morning sees the upload did not complete18:52
petertr7then retries the upload on the same a.py18:52
petertr7and the user would be or should be aware if a.py has changed since the original attempt to upload18:53
timburkeso what all do we get in the cache object that we don't get in container listings? the chunk size & large-object type? how do we decide how long the .cache should hang around?18:54
*** esker has joined #openstack-swift18:54
petertr7well if you do a container listing you need to know the location of the segments, which a user may not know18:55
petertr7I'm not sure how long the .cache file should stay around. I'm open to suggestions18:55
petertr7I guess it would vary depending on the size of the file18:56
petertr7If a user is uploading an archived file that is multi GB or even 1 TB it could take a variable amount of time to complete the upload18:56
timburkeuser shouldn't need to know; during uploads, swiftclient decides it based on object attributes: https://github.com/openstack/python-swiftclient/blob/2.7.0/swiftclient/service.py#L1836-L184518:57
*** admin0 has joined #openstack-swift18:59
petertr7Hmm so I guess instead of creating and managing a cache file, a "--recovery" flag could to a listing for the segments18:59
petertr7and continue where it left off18:59
petertr7the manifest only needs location and etag which is available when you do a listing18:59
petertr7*and size18:59
timburkeyep. on the plus side, we'd be able to update the x-delete-at whenever we update the cache. but i think the delay we want (if we follow this approach) will be dominated by user convenience, not upload time19:00
*** haomaiwang has quit IRC19:01
petertr7thanks timburke19:01
petertr7So just to clarify from the user perspective19:01
*** haomaiwang has joined #openstack-swift19:01
petertr7user uploads a static large object, goes home for the night19:01
petertr7the next morning realizes the upload did not finish. runs the upload again with --recovery19:01
petertr7and python-swiftclient will do a listing and pick up where the file left off19:02
petertr7no cache file created locally19:02
timburkeor dlo. maybe leaves for the weekend, comes back to it Monday. but yeah, this all sounds like a good experience19:03
petertr7awesome, thanks for your feedback, it's much appreciated19:04
acolestimburke: petertr7 when listing the segments container, how would the recovery phase differentiate old segments from a previous (successful) upload vs missing segments form failed upload? can we use the modified time for that?19:05
timburkepetertr7: might be nice to display a warning if --recovery is passed and no segments are found (and we're only uploading one object). since it probably means the file has changed and there may be orphaned segments19:06
petertr7thanks timburke, I will make a not of that19:06
petertr7*note19:06
timburkeacoles: mtime gets baked into the segment object name19:06
acolesthe segments' x-timestamp may not be in segment order, so I'm not sure we can simply check for a chronological progression of segments19:06
acolestimburke: ah, right, that helps19:06
petertr7is the header "x-object-meta-mtime" the mtime of the segment upload or the timestamp of the file being segmented?19:08
timburkeso, if we're dealing with an actual file (so we can get & reasonably trust things like file size and mtime), and if we feel safe in assuming that the user would use the same segment size and large-object type, then we should be able to rely on just container listings19:09
petertr7yes , of course we can raise warnings if the segment size doesn't match19:10
*** petertr7 has left #openstack-swift19:10
*** david-lyle has quit IRC19:11
timburkepetertr7: the mtime from the file on disk, which will also be set as the x-object-meta-mtime for the manifest. i think (but need to confirm) that we don't bother to set x-object-meta-mtime for the segments. and it will have nothing to do with the x-timestamp for any of them19:11
*** petertr7 has joined #openstack-swift19:14
*** acoles is now known as acoles_19:14
petertr7Sorry timburke, anoles, I somehow deleted this channel from my irc bouncer and kicked myself out. I've missed any messages you sent in the last couple of minutes19:15
timburkei think just this: petertr7: the mtime from the file on disk, which will also be set as the x-object-meta-mtime for the manifest. i think (but need to confirm) that we don't bother to set x-object-meta-mtime for the segments. and it will have nothing to do with the x-timestamp for any of them19:16
petertr7Thanks19:16
petertr7right okay19:16
*** admin0 has quit IRC19:16
*** barker has joined #openstack-swift19:19
*** barker has quit IRC19:25
*** baojg has joined #openstack-swift19:29
*** geaaru has quit IRC19:40
MingyuIt seems that in some system, the environment markers don't support <, <= etc ?19:40
*** diazjf has joined #openstack-swift19:42
wbhuberhow does x-newest header work on containers?  i understand that x-newest makes sense when used - to get the latest version of an object by newest replica (out of two or three), but containers?  how?19:43
*** zhill has quit IRC19:46
*** mragupat has joined #openstack-swift19:48
*** admin0 has joined #openstack-swift19:48
*** admin0 has quit IRC19:49
*** admin0 has joined #openstack-swift19:49
openstackgerritMichael Barton proposed openstack/swift: go: make it compile on OSX  https://review.openstack.org/27641819:52
*** diazjf has quit IRC19:52
*** diazjf has joined #openstack-swift19:55
*** stevemar has quit IRC19:56
*** SkyRocknRoll has joined #openstack-swift19:56
*** zhill has joined #openstack-swift19:58
*** haomaiwang has quit IRC20:01
*** haomaiwang has joined #openstack-swift20:01
*** baojg has quit IRC20:03
*** gyee has quit IRC20:05
*** gordc has joined #openstack-swift20:14
gordchi folks, just curious, but is there an easy way to define an offset when running get_container?20:15
petertr7gordc: off by number?20:15
*** diazjf has quit IRC20:15
petertr7i.e. list objects in <container> starting after X objects?20:16
*** admin0 has quit IRC20:16
gordcpetertr7: correct20:16
petertr7atm I don't think so. the only thing close to that is using the marker which requires you to know the names in the listing which is not helpful if you want exactly X offset20:17
petertr7would be a really helpful feature for pagination though20:18
gordcpetertr7: yeah. that's what i'm trying to accomplish... sucks.20:18
gordcpetertr7: thanks for the help though20:18
petertr7gordc: your welcome20:19
petertr7gordc: I too was trying to figure out how to create pagination like feature20:19
petertr7gordc: and i ended up giving up cause I read stuff into memory, created a stack and used object names as markers. it was too much of a mess20:19
gordcyeah, i found the ML topic where they decided to use marker. i guess it was chosen to make repeatable queries possible.20:20
gordcsucks that i have the opposite requirement.20:21
*** diazjf has joined #openstack-swift20:31
*** fthiagogv_ has joined #openstack-swift20:37
*** eranrom has quit IRC20:37
*** trifon has joined #openstack-swift20:38
*** briancli1e has joined #openstack-swift20:41
*** wolsen_ has joined #openstack-swift20:41
*** briancurtin_ has joined #openstack-swift20:45
*** diazjf has quit IRC20:47
*** tdasilva has quit IRC20:47
*** briancurtin has quit IRC20:47
*** fthiagogv has quit IRC20:47
*** briancline has quit IRC20:47
*** rsFF has quit IRC20:47
*** wolsen has quit IRC20:47
*** pdardeau has quit IRC20:47
*** haomaiwang has quit IRC20:47
*** briancurtin_ is now known as briancurtin20:48
*** tdasilva has joined #openstack-swift20:49
*** diazjf has joined #openstack-swift20:49
*** pdardeau has joined #openstack-swift20:49
*** rsFF has joined #openstack-swift20:49
*** tdasilva has quit IRC20:49
*** tdasilva has joined #openstack-swift20:49
*** haomaiwang has joined #openstack-swift20:49
*** diazjf has quit IRC20:50
*** rsFF has quit IRC20:51
*** rsFF has joined #openstack-swift20:52
*** gordc has quit IRC20:52
*** dmorita has quit IRC20:58
*** haomaiwang has quit IRC21:01
*** haomaiwang has joined #openstack-swift21:01
*** baojg has joined #openstack-swift21:04
*** diazjf has joined #openstack-swift21:05
*** ChanServ sets mode: +v tdasilva21:05
*** lpabon has joined #openstack-swift21:05
*** SkyRocknRoll has quit IRC21:06
timburkepetertr7: the trouble with an absolute offset into container listings is that the objects in the container are *constantly* changing. if you get one page of, say, 50 items, when you go to get the next page at ?offset=50 you have *absolutely no idea* where that will be in relation to your original request. if enough writes came in (or if there was a partition, or if...) even the last object returned could come *before*  the first objec21:15
timburket from your previous listing21:15
timburkeso for the longest time, pagination was one-way. you could start at the beginning, click next, click next, but never go back. only recently did we get reverse listings, which you might be interested in: https://github.com/openstack/swift/blob/2.6.0/CHANGELOG#L14-L1921:17
*** dmorita has joined #openstack-swift21:18
*** admin0 has joined #openstack-swift21:21
tdasilvaacoles_: https://twitter.com/EmilienMacchi/status/69519435122438144021:22
*** mvk has joined #openstack-swift21:22
torgomaticFWIW, on a previous app I worked on, we had a large table (hundreds of millions of rows) that we'd iterate over piecewise, and we'd do it in pages of 10,000.21:23
*** dmorita has quit IRC21:23
torgomaticIt ended up using limit/offset queries to do it.21:23
torgomaticThe middle were always waaaay slower than the ends. The DB engine had to do a lot more work to get OFFSET 150000000 LIMIT 10000 than it did OFFSET 20000 LIMIT 10000. Orders of magnitude more work.21:24
torgomaticSo, I guess what I'm saying is supporting limit/offset queries in Swift is basically like adding a DoS-the-cluster button.21:26
timburkegood point! maybe solvable with order statistic trees, but that's really on the db engine21:27
torgomaticyep, and I'm not counting on sqlite to get that fancy any time soon :p21:28
*** dmorita has joined #openstack-swift21:29
*** dmorita has quit IRC21:30
*** dmorita has joined #openstack-swift21:31
torgomaticIt's not generally solvable given the ability to specify arbitrary WHERE clauses, but my old app was really just doing a bunch of "SELECT * FROM big_old_table ORDER BY id LIMIT <N> OFFSET <M>"21:32
*** baojg has quit IRC21:32
torgomaticand still, the DB churned mightily serving up the stuff in the middle21:32
torgomaticit got better toward the end, so it was able to use the index on id (the primary key) in reverse, which was nice21:33
*** zul has joined #openstack-swift21:42
*** Mingyu has quit IRC21:50
*** Mingyu has joined #openstack-swift21:50
*** lpabon has quit IRC21:51
*** Mingyu has quit IRC21:52
*** Mingyu has joined #openstack-swift21:52
*** trifon has quit IRC21:56
*** Mingyu has quit IRC21:59
*** Mingyu has joined #openstack-swift21:59
*** haomaiwang has quit IRC22:01
*** haomaiwa_ has joined #openstack-swift22:01
notmynamegood morning22:02
*** dmorita has quit IRC22:05
*** dmorita has joined #openstack-swift22:07
*** rickyrem has joined #openstack-swift22:09
*** jamielennox|away is now known as jamielennox22:10
*** admin0 has quit IRC22:12
*** ajiang has left #openstack-swift22:12
*** petertr7 is now known as petertr7_away22:15
*** trifon has joined #openstack-swift22:26
*** arch-nemesis has quit IRC22:43
*** david-lyle has joined #openstack-swift22:48
*** gyee has joined #openstack-swift22:48
*** bjkeller has left #openstack-swift22:51
*** david-lyle has quit IRC22:52
*** diazjf has quit IRC22:57
*** haomaiwa_ has quit IRC23:01
*** daemontool has quit IRC23:01
*** haomaiwang has joined #openstack-swift23:01
*** chsc has quit IRC23:18
*** nadeem has quit IRC23:18
*** km has joined #openstack-swift23:26
*** mgarza has quit IRC23:27
*** kei_yama has joined #openstack-swift23:29
*** chlong has quit IRC23:30
*** jamielennox is now known as jamielennox|away23:31
*** mragupat_ has joined #openstack-swift23:45
*** mragupat has quit IRC23:49
*** mragupat_ has quit IRC23:49

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