Tuesday, 2016-01-12

*** lcurtis has quit IRC00:00
mattoliverauho_: morning00:00
ho_mattoliverau: morning!00:00
openstackgerritJonathan Hinson proposed openstack/swift: Automatic refresh of memcache config settings  https://review.openstack.org/21849000:07
*** mragupat has quit IRC00:09
claygtimburke: fwiw I can confirm the object-auditor is in a sad state - did you open a bug already?00:09
timburkeclayg: not yet00:09
claygtimburke: well we better start there00:10
timburkeyep00:10
claygnotmyname: I marked lp bug #1533002 critical - but if timburke isn't able to stick with it up to the pending release you might bump it down to HIGH - I'll be sad, but not offended00:13
openstackLaunchpad bug 1533002 in OpenStack Object Storage (swift) "object-auditor skips EC fragments" [Critical,Confirmed] https://launchpad.net/bugs/153300200:13
*** badari has quit IRC00:15
notmynameclayg: ack. timburke, thanks for diving into that one!00:15
claygtimburke is the best!  three cheers for timburke!00:15
mattoliverauCheers! Cheers! Cheers!00:18
openstackgerritClay Gerrard proposed openstack/swift: functest for x-timestamp validation  https://review.openstack.org/26608500:26
*** km___ has joined #openstack-swift00:32
*** km_ has quit IRC00:32
*** shakamunyi has quit IRC00:35
*** shakamunyi has joined #openstack-swift00:35
*** diogogmt has quit IRC00:37
kota_good morning00:43
*** m_kazuhiro has joined #openstack-swift00:44
kota_clayg: thanks for reviewing my patch 265154 :)00:45
patchbotkota_: https://review.openstack.org/#/c/265154/ - Add note COPY with conditional headers00:45
mattoliveraukota_: morning00:54
*** gyee has quit IRC00:55
kota_mattoliverau: morning :)00:56
*** barra204 has joined #openstack-swift00:56
*** shakamunyi has quit IRC00:57
openstackgerritTim Burke proposed openstack/swift: Autovivify X-Versions-Location container  https://review.openstack.org/26501500:58
*** garthb__ has quit IRC01:09
*** natarej_ has quit IRC01:11
*** barra204 has quit IRC01:14
*** shakamunyi has joined #openstack-swift01:15
ho_kota_: morning!01:19
kota_ho: morning!01:20
takashigood morning01:23
kota_takashi: o/01:24
*** Jeffrey4l has quit IRC01:25
*** km___ has quit IRC01:26
*** km_ has joined #openstack-swift01:26
*** barra204 has joined #openstack-swift01:31
*** shakamunyi has quit IRC01:32
*** shakamunyi has joined #openstack-swift01:36
*** barra204 has quit IRC01:38
*** MVenesio has joined #openstack-swift01:38
*** barra204 has joined #openstack-swift01:38
*** asettle has quit IRC01:38
*** shakamunyi has quit IRC01:39
*** MVenesio has quit IRC01:42
*** shakamunyi has joined #openstack-swift01:44
*** barra204 has quit IRC01:45
*** haomaiwang has quit IRC01:48
*** shakamunyi has quit IRC01:48
*** 14WAAN277 has joined #openstack-swift01:48
*** shakamunyi has joined #openstack-swift01:48
*** asettle has joined #openstack-swift01:49
*** 14WAAN277 has quit IRC01:50
claygtimur: yay!  I owe you a beer and you owe one to mattoliverau !01:53
*** shakamunyi has quit IRC01:54
timurclayg: woot! thanks for the reviews02:02
timurand thanks mattoliverau -- happy to buy that beer :)02:03
*** sgundur has joined #openstack-swift02:05
*** sgundur has left #openstack-swift02:05
*** shakamunyi has joined #openstack-swift02:08
*** shakamunyi has quit IRC02:10
*** badari has joined #openstack-swift02:11
*** shakamunyi has joined #openstack-swift02:12
*** asettle has quit IRC02:16
*** asettle has joined #openstack-swift02:17
*** klrmn has quit IRC02:20
*** asettle has quit IRC02:22
*** shakamunyi has quit IRC02:22
*** shakamunyi has joined #openstack-swift02:23
mattoliveraukeep the cool patches comin02:24
*** mingdang1 has joined #openstack-swift02:28
*** shakamunyi has quit IRC02:32
*** diogogmt has joined #openstack-swift02:33
*** asettle has joined #openstack-swift02:47
*** sanchitmalhotra has joined #openstack-swift02:49
*** venkat has joined #openstack-swift03:14
*** mragupat has joined #openstack-swift03:18
*** janonymous has joined #openstack-swift03:20
openstackgerritvenkatesh proposed openstack/swift: check_object_creation: method call is redundant  https://review.openstack.org/26613103:23
*** klrmn has joined #openstack-swift03:25
*** dimasot has joined #openstack-swift03:28
*** badari_ has joined #openstack-swift03:36
*** MVenesio has joined #openstack-swift03:39
*** nadeem has joined #openstack-swift03:39
*** badari has quit IRC03:39
*** ppai has joined #openstack-swift03:39
*** MVenesio has quit IRC03:44
*** janonymous has quit IRC03:47
*** badari_ has quit IRC03:50
pdardeauclayg: thanks for review on dev id holes patch04:06
*** asettle has quit IRC04:15
*** dmorita has quit IRC04:25
*** dmorita has joined #openstack-swift04:26
*** links has joined #openstack-swift04:26
*** janonymous has joined #openstack-swift04:32
openstackgerritvenkatesh proposed openstack/swift: check_object_creation: method call is redundant  https://review.openstack.org/26613104:37
*** nadeem has quit IRC04:42
*** asettle has joined #openstack-swift04:46
*** janonymous_ has joined #openstack-swift04:48
*** janonymous has quit IRC04:50
*** asettle has quit IRC04:52
*** asettle has joined #openstack-swift04:52
*** itlinux has joined #openstack-swift05:04
*** itlinux has quit IRC05:04
*** klrmn has quit IRC05:29
*** trifon has joined #openstack-swift05:30
*** janonymous_ has quit IRC05:32
*** mragupat has quit IRC05:32
*** janonymous has joined #openstack-swift05:35
*** MVenesio has joined #openstack-swift05:39
*** MVenesio has quit IRC05:44
openstackgerritvenkatamahesh proposed openstack/swift: Improvements in python conditional code  https://review.openstack.org/26618505:49
openstackgerritHisashi Osanai proposed openstack/swift: Fix posting accounts behavior when half of account servers downed  https://review.openstack.org/26619005:57
openstackgerritHisashi Osanai proposed openstack/swift: Fix posting containers behavior when half of container servers downed  https://review.openstack.org/26619306:00
*** bkumar has joined #openstack-swift06:01
openstackgerritHisashi Osanai proposed openstack/swift: Fix putting containers behavior during migration of accounts  https://review.openstack.org/26619706:02
*** dmorita has quit IRC06:02
openstackgerritHisashi Osanai proposed openstack/swift: Fix deleting containers behavior  https://review.openstack.org/26619906:04
*** Jeffrey4l has joined #openstack-swift06:16
*** asettle has quit IRC06:17
*** 6A4ABMVDU has joined #openstack-swift06:26
*** dmorita has joined #openstack-swift06:26
*** dmorita has quit IRC06:28
*** dmorita has joined #openstack-swift06:28
*** ChubYann has quit IRC06:43
*** esker has joined #openstack-swift06:49
*** natarej has joined #openstack-swift06:49
*** esker has quit IRC06:53
*** dmorita has quit IRC06:58
*** silor has joined #openstack-swift06:59
*** 6A4ABMVDU has quit IRC07:03
*** haomaiwang has joined #openstack-swift07:05
*** dmorita has joined #openstack-swift07:07
*** zaitcev has quit IRC07:08
*** ntt has joined #openstack-swift07:25
*** haomaiwang has quit IRC07:25
*** haomaiwang has joined #openstack-swift07:26
*** SkyRocknRoll has joined #openstack-swift07:28
*** MVenesio has joined #openstack-swift07:40
takashiho_: are you available now?07:44
*** MVenesio has quit IRC07:44
openstackgerritReedip proposed openstack/swift-bench: Remove support for py33/py26  https://review.openstack.org/26448607:45
*** haomaiwang has quit IRC07:56
*** haomaiwa_ has joined #openstack-swift07:58
*** haomaiwa_ has quit IRC07:59
*** haomaiwa_ has joined #openstack-swift07:59
*** SkyRocknRoll has quit IRC08:00
*** haomaiwa_ has quit IRC08:01
*** ntt has quit IRC08:01
*** haomaiwa_ has joined #openstack-swift08:01
*** arnox has joined #openstack-swift08:03
*** jistr has joined #openstack-swift08:06
*** jistr is now known as jistr|doc08:07
openstackgerritjanonymous proposed openstack/swift: Added GreenAsyncPile txn_id logging  https://review.openstack.org/26623908:08
openstackgerritMerged openstack/swift: Fix IPv6 handling in MemcacheConnPool.  https://review.openstack.org/25870408:09
*** rledisez has joined #openstack-swift08:09
*** dmorita has quit IRC08:09
*** ntt has joined #openstack-swift08:11
*** esker has joined #openstack-swift08:12
*** SkyRocknRoll has joined #openstack-swift08:14
*** ntt has quit IRC08:15
*** esker has quit IRC08:17
*** dmorita has joined #openstack-swift08:23
*** haomaiwa_ has quit IRC08:26
*** dmorita has quit IRC08:32
*** asettle has joined #openstack-swift08:32
*** ntt has joined #openstack-swift08:32
*** haomaiwa_ has joined #openstack-swift08:33
*** venkat has quit IRC08:36
ho_takashi: yeah but i'm in meeting so quick response is difficult :)08:40
*** haomaiwa_ has quit IRC08:42
*** haomaiwa_ has joined #openstack-swift08:44
*** geaaru has joined #openstack-swift08:44
*** venkat has joined #openstack-swift08:47
*** jmccarthy has quit IRC08:48
*** jmccarthy has joined #openstack-swift08:50
takashiho_: OK. I posted a comment on patch 266197, so please check that.08:53
patchbottakashi: https://review.openstack.org/#/c/266197/ - Fix putting containers behavior during migration o...08:53
*** esker has joined #openstack-swift08:53
*** ppai_ has joined #openstack-swift08:56
*** esker has quit IRC08:58
*** ppai has quit IRC08:58
*** jistr|doc has quit IRC08:59
*** haomaiwa_ has quit IRC09:01
*** 77CAAI2UM has joined #openstack-swift09:01
ho_takashi: interesting! I couldn't read all the history but you already know current my concern behavior difference b/w put_object and put_container.09:05
*** jordanP has joined #openstack-swift09:08
*** daemontool has joined #openstack-swift09:11
*** joeljwright has joined #openstack-swift09:14
*** ChanServ sets mode: +v joeljwright09:14
takashiho_: yes. I think that behavior works was decided because swift in old version does not user handoff so actively for account/container,09:17
*** openstackgerrit has quit IRC09:17
takashis/user/use09:17
takashibut nowadays swift uses handoff effectively for account, container, based on request_node_count09:17
*** openstackgerrit has joined #openstack-swift09:18
takashiand I wondered if we should keep that behavior now, when writing that patch. (sorry for my inactivity...)09:18
*** jistr has joined #openstack-swift09:20
*** jordanP has quit IRC09:22
*** jordanP has joined #openstack-swift09:33
*** esker has joined #openstack-swift09:35
*** proteusguy has quit IRC09:35
*** aix has joined #openstack-swift09:37
*** esker has quit IRC09:40
*** km_ has quit IRC09:51
*** km_ has joined #openstack-swift09:51
*** proteusguy has joined #openstack-swift09:52
*** ho_ has quit IRC09:52
*** sileht has quit IRC09:52
*** venkat has quit IRC09:54
*** ho has joined #openstack-swift09:55
*** ho is now known as Guest4779509:55
*** SkyRocknRoll has quit IRC09:55
*** 77CAAI2UM has quit IRC10:01
*** sileht has joined #openstack-swift10:02
Guest47795takashi: i'm back.10:03
*** Guest47795 is now known as ho_10:03
ho_takashi: ^^^ ho_10:03
*** acoles_ is now known as acoles10:04
*** jordanP has quit IRC10:04
acolesgood morning10:06
ho_ho_: i will check more but current my thought is it's better to make a fix in proxy side rather than container-server. because each container-server doesn't have all account servers (some)10:06
*** venkat has joined #openstack-swift10:06
ho_takashi: :-)10:06
*** SkyRocknRoll has joined #openstack-swift10:07
*** haomaiwa_ has joined #openstack-swift10:07
ho_takashi: therefore container-server can not handle correct status for the account. i think it's a role for proxy-server.10:08
ho_takashi: i might have mis-understanding but container/server.py:L234 in your patch means "ERROR the account is missing on SOME account servers" i think.10:11
ho_acoles: morning!10:12
*** esker has joined #openstack-swift10:16
*** vinsh_ has joined #openstack-swift10:16
*** AbyssOne_ has joined #openstack-swift10:19
*** vinsh has quit IRC10:19
*** AbyssOne has quit IRC10:19
*** gmmaha has quit IRC10:19
*** haomaiwa_ has quit IRC10:20
*** gmmaha has joined #openstack-swift10:20
mahaticacoles: good morning10:21
*** esker has quit IRC10:21
*** SkyRocknRoll has quit IRC10:23
*** ntt has quit IRC10:26
takashiacoles: good morning10:26
takashiho_: you are right. I think I shoud change that message like this. ERROR the all account assigned to me is missing10:27
takashis/the all account/all the accounts/10:29
takashis/is/are10:29
*** aix has quit IRC10:32
takashiho_: If we determine to overwrite responses from container server based on the whole situation, I think we have to do that in proxy-server.10:33
ho_takashi: overrides works only split brain case.10:34
*** venkat has quit IRC10:35
*** jordanP has joined #openstack-swift10:35
takashiho_: I NOW understand. That's good!10:36
acolestakashi: are you Takashi Kajinami?10:36
takashiacoles: yes10:36
acolestakashi: i just saw that you registered for the hackathon :)10:37
takashiacoles: Yes! I'm now working with kota_, and he told me about the hackathon :-)10:39
acolestakashi: great10:39
kota_acoles, takashi: we will be in Bristol ;)10:40
takashikota_, acoles: yeah, and this is my first swift hackathon, and also my first visit to England. I'm very looking forward to it.10:43
acolestakashi: nice10:45
*** venkat has joined #openstack-swift10:48
*** aix has joined #openstack-swift10:53
*** esker has joined #openstack-swift10:58
ho_takashi: unn... difficult. both approaches are fine for me. my patch can handle migration state but you patch's behavior is same as object ...10:58
*** esker has quit IRC11:02
ho_takashi: do you have a plan to re-open the patch?11:13
*** bkumar has quit IRC11:14
takashiho_: I'll re-open it if necessory. I think I should rebase it.11:16
*** openstackgerrit has quit IRC11:17
ho_takashi: k, I put my +1 on your patch so I will abandoned my patch after you will re-open it.11:18
*** openstackgerrit has joined #openstack-swift11:18
takashiho_: Could you give me a time for that? I think I have to think more to decide which one is better.11:19
takashiho_: I think I can take some time for that tommorow11:20
ho_takashi: np! if you rebase your patch, please remove L233-234 in server.py. your approach doesn't need to care the case. this is the reason why i choose yours :-)11:21
takashiho_: thanks!11:22
*** ho_ has quit IRC11:24
*** takashi has quit IRC11:25
*** dmorita has joined #openstack-swift11:33
*** dmorita has quit IRC11:37
*** sanchitmalhotra has quit IRC11:42
*** venkat has quit IRC11:43
*** mingdang1 has quit IRC11:46
*** mingdang1 has joined #openstack-swift11:47
*** McMurlock has quit IRC11:51
*** mingdang1 has quit IRC11:51
*** venkat has joined #openstack-swift11:54
*** MVenesio has joined #openstack-swift11:57
*** McMurlock has joined #openstack-swift11:58
*** asettle has quit IRC12:03
*** asettle has joined #openstack-swift12:04
*** asettle has quit IRC12:08
*** kei_yama has quit IRC12:19
kota_am heading for my home12:22
*** ppai_ has quit IRC12:24
*** ho_away has joined #openstack-swift12:26
*** aix has quit IRC12:29
*** aix has joined #openstack-swift12:32
*** ppai_ has joined #openstack-swift12:38
*** mingdang1 has joined #openstack-swift12:39
*** ho_away has quit IRC12:39
*** d0ugal has quit IRC12:42
*** d0ugal has joined #openstack-swift12:43
*** d0ugal is now known as Guest5838512:43
*** Guest58385 is now known as d0ugal12:45
*** d0ugal has quit IRC12:45
*** d0ugal has joined #openstack-swift12:45
*** m_kazuhiro has quit IRC12:46
*** haomaiwang has joined #openstack-swift12:56
*** km_ has quit IRC12:57
*** haomaiwang has quit IRC13:01
*** ppai_ has quit IRC13:01
venkatHi all13:02
venkatwhat is the use of X-Backend-Obj-Multiphase-Commit header?13:02
venkatIn general, X-Backend-Obj-* headers ?13:02
venkatthese are passed from proxy right. not from the user??13:03
*** shakamunyi has joined #openstack-swift13:04
*** haomaiwang has joined #openstack-swift13:06
onovyclayg: hi. i replied to your comment for ionice/nice support. it's bit longer, sorry for it. I just want to explain everything correctly. That review is really long so i made summary.13:07
*** haomaiwang has quit IRC13:11
*** lpabon_ has joined #openstack-swift13:15
*** ppai_ has joined #openstack-swift13:15
*** venkatesh has joined #openstack-swift13:15
*** lpabon has quit IRC13:15
*** venkat has quit IRC13:15
*** john_b has left #openstack-swift13:17
*** ho_away has joined #openstack-swift13:21
*** haomaiwang has joined #openstack-swift13:23
*** mingdang_ has joined #openstack-swift13:23
*** mingdang1 has quit IRC13:24
*** diogogmt has quit IRC13:27
*** diogogmt has joined #openstack-swift13:27
*** haomaiwang has quit IRC13:28
*** bkumar has joined #openstack-swift13:32
*** bkumar has quit IRC13:34
*** dimasot has quit IRC13:34
*** bkumar has joined #openstack-swift13:35
*** john_bar has joined #openstack-swift13:36
*** ppai_ has quit IRC13:38
acolesvenkatesh: any header name starting X-Backend- is reserved for swift internal use and they are removed from any client request.13:43
*** diogogmt has quit IRC13:43
acolesvenkat: ^^ (same person, two nicks??)13:44
acolesX-Backend-Obj-Multiphase-Commit header is used in erasure coded object PUT to inform the object server that there are two phases to the put (send data, then commit)13:45
venkateshacoles: Thanks, just now I have seen gatekeeper is removing those headers13:45
venkateshthese headers will be saved with object??13:46
acolesvenkatesh: yes, removed by gatekeeper, no not saved with object.13:46
acolesvenkatesh: internal metadata that needs to be saved with object uses x-object-sysmeta-* which is also removed by gatekeeper13:47
venkateshacoles: ya, x-object-sysmeta-* it is removing13:48
acolesx-backend- headers are used proxy->backend but also between obj servers for example during replication13:48
venkateshacoles: Ok, Thanks13:49
*** bkumar has quit IRC13:49
venkateshHi13:54
venkateshwhat is the use of X-Obj-Metadata-Footer?13:54
openstackgerritMerged openstack/swift: Add note COPY with conditional headers  https://review.openstack.org/26515413:54
venkateshit seems custom-metata used object PUT13:54
*** bkumar has joined #openstack-swift13:55
*** haomaiwa_ has joined #openstack-swift13:59
*** haomaiwa_ has quit IRC14:01
*** haomaiwang has joined #openstack-swift14:01
*** venkatesh has quit IRC14:04
*** bkumar has quit IRC14:05
*** bkumar has joined #openstack-swift14:06
*** bkumar has quit IRC14:10
*** yatin has joined #openstack-swift14:16
*** tongli has joined #openstack-swift14:18
*** mingdang_ has quit IRC14:20
*** dimasot has joined #openstack-swift14:23
*** mingdang1 has joined #openstack-swift14:24
*** mrmoje has joined #openstack-swift14:26
acolessometimes the proxy needs to send the object server 'headers' after the object body as 'footers' -  X-Obj-Metadata-Footer is used by the obj server to let the proxy know that its ok to send footers.14:26
acolessometimes == for example during a erasure coded object put14:27
*** esker has joined #openstack-swift14:29
*** petertr7_away is now known as petertr714:30
*** esker has quit IRC14:32
*** aix has quit IRC14:33
*** esker has joined #openstack-swift14:33
*** aix has joined #openstack-swift14:33
*** esker has quit IRC14:38
*** lcurtis has joined #openstack-swift14:45
*** sgundur has joined #openstack-swift14:45
*** ho_away has quit IRC14:45
*** blmartin has joined #openstack-swift14:48
*** links has quit IRC14:50
*** yatin has quit IRC14:54
*** hseipp has joined #openstack-swift14:57
*** lpabon has joined #openstack-swift15:05
*** esker has joined #openstack-swift15:05
*** esker has quit IRC15:06
*** esker has joined #openstack-swift15:07
*** trifon has quit IRC15:08
*** petertr7 is now known as petertr7_away15:10
*** diazjf has joined #openstack-swift15:11
*** petertr7_away is now known as petertr715:18
*** mingdang1 has quit IRC15:20
*** haomaiwang has quit IRC15:24
*** diazjf has quit IRC15:27
*** breitz has quit IRC15:32
*** breitz has joined #openstack-swift15:32
*** mragupat has joined #openstack-swift15:37
*** diazjf has joined #openstack-swift15:38
*** yatin has joined #openstack-swift15:56
*** yatin_ has joined #openstack-swift15:57
*** yatin has quit IRC16:01
*** SkyRocknRoll has joined #openstack-swift16:03
*** aix has quit IRC16:07
*** garthb__ has joined #openstack-swift16:08
*** nadeem has joined #openstack-swift16:10
openstackgerritJonathan Hinson proposed openstack/swift: Automatic refresh of memcache config settings  https://review.openstack.org/21849016:14
*** asti has joined #openstack-swift16:18
*** diogogmt has joined #openstack-swift16:20
*** asti has left #openstack-swift16:23
*** badari has joined #openstack-swift16:23
*** diogogmt has quit IRC16:27
*** diazjf has quit IRC16:29
*** diogogmt has joined #openstack-swift16:29
*** badari has quit IRC16:33
*** badari has joined #openstack-swift16:33
*** jamielennox is now known as jamielennox|away16:37
*** diazjf has joined #openstack-swift16:38
notmynamegood morning16:40
*** petertr7 is now known as petertr7_away16:41
joeljwrightmorning16:41
pdardeaugood morning16:41
joeljwright(well, I wish it was still morning - then I might get everything done today!)16:41
notmynameheh16:41
notmynameinteresting ML discussion on bug 1512207 (and more generally about bugs/patches like that)16:42
openstackbug 1512207 in tuskar "Fix usage of assertions" [Undecided,In progress] https://launchpad.net/bugs/1512207 - Assigned to Swapnil Kulkarni (coolsvap)16:42
*** petertr7_away is now known as petertr716:42
*** jordanP has quit IRC16:43
*** jordanP has joined #openstack-swift16:43
notmynameseems to be a good bit of frustration. see the ML thread with the subject "spam of patches"16:44
*** nadeem has quit IRC16:48
*** nadeem has joined #openstack-swift16:49
mahaticnotmyname: morning!16:50
*** SkyRocknRoll has quit IRC16:53
*** zaitcev has joined #openstack-swift16:54
*** ChanServ sets mode: +v zaitcev16:54
*** CaioBrentano has joined #openstack-swift16:58
*** gyee has joined #openstack-swift17:01
acolesnotmyname: yeah, if pointless > 0: wont_fix = pointless17:01
*** Jeffrey4l has quit IRC17:02
acolesnotmyname: or should that be if pointless:  <slap>17:02
notmyname:-)17:05
*** tongli has quit IRC17:07
*** yatin has joined #openstack-swift17:12
notmynamegood point here. we really should be considering the implications of py4. http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/17:13
notmynameI know that's especially important to torgomatic_17:13
notmynamealso, why stop there. can we go ahead and make sure our code is py5 and py6 compatible?17:14
*** yatin_ has quit IRC17:16
*** daemontool has quit IRC17:22
*** bdrich has joined #openstack-swift17:25
timburkenotmyname: snark aside, it looks like swiftclient would stop printing *anything* if neither six.PY2 nor six.PY3 is True: https://github.com/openstack/python-swiftclient/blob/2.7.0/swiftclient/multithreading.py#L74-L8017:26
*** bdrich has left #openstack-swift17:27
*** yatin has quit IRC17:28
notmynameyeah, the advice int eh article isn't bad. it's just funny to see it presented like it was (Py4)17:28
*** dmorita has joined #openstack-swift17:34
*** geaaru has quit IRC17:35
*** dmorita has quit IRC17:35
pdardeaunotmyname: i created a couple of bps related to ring17:36
*** petertr7 is now known as petertr7_away17:37
*** esker has quit IRC17:39
*** dmorita has joined #openstack-swift17:39
*** garthb has joined #openstack-swift17:41
*** coreycb has joined #openstack-swift17:43
*** garthb__ has quit IRC17:43
coreycbis there a new swift release coming out anytime soon?17:43
*** rledisez has quit IRC17:47
*** jordanP has quit IRC17:48
onovynotmyname: ^ question for you i think :)17:49
clayg^ this is the burning question on everyones mind!17:49
onovyclayg: hi. can we continue with our discussion about ionice? or do you want to talk about it at meeting tomorrow?17:54
onovycoreycb: can i ask you why are you asking? :) you are on debian openstack channel, so is it related? :)17:55
coreycbonovy, nope not related I don't think.  we just have 2.5.0 in liberty and mitaka at this point and was wondering if there's a new version coming out soon that would correspond to mitaka.17:57
onovyah :) no mitaka swift release yet, thats right17:57
*** klrmn has joined #openstack-swift17:58
*** diazjf has quit IRC17:58
*** dmorita has quit IRC18:01
*** xzvk has quit IRC18:01
*** dmorita has joined #openstack-swift18:01
*** dmorita has quit IRC18:01
*** diogogmt has quit IRC18:02
*** jistr has quit IRC18:03
*** dmorita has joined #openstack-swift18:04
claygonovy: i was about to be afk - i will be at the meeting tmrw18:05
claygonovy: did you add some feedback for me to the review - i'm sure we can make progress async - although I'm happy to discuss higher bandwidth at some point too18:06
openstackgerritJonathan Hinson proposed openstack/swift: Functional tests for if-match with multiple etags  https://review.openstack.org/26651618:07
*** diogogmt has joined #openstack-swift18:07
claygonovy: FWIW, I think I can see why the feature might be "nice to have" but I probably rate the value lower and the cost higher than you do - it's a judgement call no doubt - i'm sure there exists a reasonable argument; i'm less sure there exists a fully objective quantification of it it "should" go in?18:08
*** dmorita has quit IRC18:08
claygonovy: maybe ML post to sample some other swift deployer/operator's "gut feel" would be the most direct route?18:08
*** dmorita has joined #openstack-swift18:10
claygonovy: well I just read your comments, and I'm not sure I follow some of the rebuttles you laid out.18:11
onovyrebuttles? what do you mean?18:13
claygonovy: one thing that might help me *greatly* is if you could point to some prior art?  What other software systems do you know of that have native ionice config options like this?  postgresql or something like that?18:14
openstackgerritOndřej Nový proposed openstack/swift: Change schedule priority of daemon/server in config  https://review.openstack.org/23879918:14
onovyclayg: what other systems you know that have something like swift-init? :)18:15
onovyif we don't have swift-init, i'm fine with ionice/nice inside init script18:15
onovybecause admin can't restart daemon with correct ionice18:15
onovybut we have18:15
onovyexcatly can, but it's possible to do it wrong with init script + swift-init combination18:16
onovyi'm ok with nice/ionice in init script, but that's means don't use swift-init in production at all18:16
claygonovy: that argument tells me we should just get rid of swift-init18:16
onovyclayg: that's one way18:17
onovyor just say: don't use it in production, use it for SAIO for example18:17
claygonovy: we recently worked on our systemd support and swift-init is basically imcompatible with all that best I can tell18:17
onovybut from other point, swift-init all restart <-- this is really helful18:17
onovyhmm18:17
onovyand another point: how we can do that "next" optimalization i mention?18:18
onovyfor example set header for account-reaper for all DEL reqs18:18
claygonovy: maybe alias swift-init or something, idk, yeah it's a useful tool - but if it's getting in the way of operations we should kick it to the curb18:18
claygonovy: i'm not really sure - ionice is a neat thing, but it seems like in the application itself we have access to better methods for applying ratelimiting and turning18:19
*** hseipp has quit IRC18:19
claygionice is blunt instrument to whack at a process like it's a black box - I think we could do better than that if we desire to18:20
onovyhmm, and nice?18:20
onovywhat should be better to tell kernel: prioritize this to this18:20
onovythan18:20
onovyratelimiting is fine, but it's another usecase18:21
onovyfor example: i want to do object-audit as fast as possible18:21
onovyBUT don't slow down our users18:21
onovythis is not possible on application level18:21
onovyexactly it's, but what is cost :)18:21
onovythere we have few lines of codes which can do it18:21
claygonovy: well, i need to sign off for a bit - but if you could please find a few other storage-ish system (perferably opensource) that do something like what you are proposing - and make me a list - it would go a good way to impress on me it's worth pursuing18:22
onovyclayg: ok, thank you18:22
*** dmorita has quit IRC18:22
claygonovy: and I don't nessecarily know why you say it's not possible at the application level - but current "army of independent processes" design in swift makes it's inconvient; and the fact that we have a distributed system makes co-ordination a non trivial problem always - but if we're sure this is the biggest problem - i'm sure we could put a dent in it18:24
*** badari has quit IRC18:26
claygonovy: the other way to demonstrate results would be with some benchmarks - taking the "convience" of having swift-init do the nicing aside for a moment - could you do an a/b comparisson of cluster with your suggest nice settings and w/o and show there's a big difference in how the system is able to respond to user iops while compeating with replication?18:26
*** badari has joined #openstack-swift18:27
claygif they're indeed significant and reproducible it may be very attractive indeed to support the feature in swift process management first class - but in my mind this is TBD18:27
*** joeljwright has quit IRC18:28
claygnotmyname: ahale: have you ever heard of a swift deployment where the operators are agressively tuning nice settings per process?18:28
*** badari has quit IRC18:29
blmartin:wq18:30
blmartinmaybe I should make an alias so that ':wq' in irc changes to 'Hello all!'18:30
blmartinso that it isn't so awkward for me18:31
onovyso compare object-server with object-replicator?18:32
onovyand metrick is "latency"?18:32
onovyclayg: http://engineering.spilgames.com/openstack-swift-lots-small-files/18:33
onovyso all of you already heard :)18:33
onovyi will graph object-server and object-auditor. It's much simpler (no rsync here)18:38
*** dmorita has joined #openstack-swift18:38
*** dmorita has quit IRC18:39
*** dmorita has joined #openstack-swift18:39
*** badari has joined #openstack-swift18:40
*** diazjf has joined #openstack-swift18:40
ahaleclayg: i have some vague recollection that we considered it sometimes ages ago but never bothered. didnt one of the comments say that ibm were doing it ?18:45
ahaleon that nice'ing processes change18:45
onovy21:34:45 <briancline> onovy: I actually asked our ops folks about this recently. we already control these in production through other means, so we're fine with this going in as long as its optional, which it certainly seems to be18:49
onovythis=nice/ionice?18:49
*** ChubYann has joined #openstack-swift18:49
onovy21:35:34 <briancline> i can see situations later where it'll help us to have it in config18:50
onovy(from swift meeting logs)18:50
*** petertr7_away is now known as petertr718:52
lcurtishello all....question on the ring and rebalancing...it is generally recommended to add weight slowly...will that mean that a partition gets moved twice as weight is brought up or that the weight just delays the chances of moving a partition18:52
notmynamegood morning (again)18:54
notmynameclayg: yeah, the ops feedback so far on the ionice thing is "seems reasonable". onovy's use case is more around cdn/streaming that a lot of the other use cases that are vocally represented in reviews18:56
notmynameas for releases, check https://bugs.launchpad.net/swift for critical bugs. yes, I want to do a release asap. but we've got a few worrisome bugs we shouldn't release without18:56
*** diazjf has quit IRC18:58
*** daemontool has joined #openstack-swift19:00
onovylcurtis: no19:01
onovyit mean that only few of partion will be moved19:01
onovyand then another few19:02
onovy(in ideal world :)19:02
onovyand hi19:02
notmynamehi onovy19:02
onovynotmyname: hi :)19:03
*** dmorita has quit IRC19:04
lcurtisthanks onovy19:04
onovylcurtis: np. if you have small cluster and adding capacity, always add weight slowly19:05
onovyadd, push to cluster, wait and then add more weight, push to cluster...19:05
*** trifon has joined #openstack-swift19:08
notmynamepatch 256306 is one I want to see land before a release (fixes one of those critical bugs listed)19:08
patchbotnotmyname: https://review.openstack.org/#/c/256306/ - Fix ClientException handling in Container Sync19:08
onovynotmyname: thanks for review19:08
onovybut after today discussion i think swift-init drop is near :)19:08
notmynametimburke: are you working on a patch for https://bugs.launchpad.net/swift/+bug/153300219:08
openstackLaunchpad bug 1533002 in OpenStack Object Storage (swift) "object-auditor skips EC fragments" [Critical,Confirmed]19:08
*** arnox has quit IRC19:11
notmyname(the in-person answer to that question was "yes, he's working on a patch today")19:12
notmynamethanks, timburke!19:12
*** gyee has quit IRC19:13
*** dmorita has joined #openstack-swift19:21
*** itlinux has joined #openstack-swift19:21
*** yarkot has joined #openstack-swift19:22
*** lpabon has quit IRC19:23
*** lpabon has joined #openstack-swift19:23
*** lpabon has quit IRC19:23
*** yarkot has quit IRC19:25
lcurtisall...what is genuine best way to tell when a cluster is finished rebalancing19:26
lcurtissomething in particular to look for in logs?19:26
notmynamelcurtis: the secret is that a "cluster" doesn't rebalance (or if it does, it never finishes). each individual storage node does, and that's what you track.19:27
*** acoles is now known as acoles_19:27
*** dmorita has quit IRC19:27
notmynamelcurtis: the replicators will log when they are done. I'll have to remind myself what the log line is19:27
onovyhttps://github.com/openstack/swift/blob/master/swift/obj/replicator.py#L785 this line19:28
onovyuse swift-recon for this19:28
notmynameonovy: thanks :-)19:29
onovylcurtis:19:29
onovyOldest completion was 2016-01-12 19:12:33 (16 minutes ago) by sdn-swift-store5.ng.seznam.cz:6000.19:29
onovyMost recent completion was 2016-01-12 19:28:20 (41 seconds ago) by sdn-swift-store4.ko.seznam.cz:6000.19:29
onovylcurtis: swift-recon :) you can see, that replication part was finished 41s <-> 15 minutes ago on all servers19:30
onovyso if i pushed ring more than 16 minutes ago, my cluster should be balanced19:30
onovybut be carefull, when you push ring, all replicator will restart (=finish in recon)19:31
lcurtiswow thank you very much onovy19:32
onovyyou are welcome19:32
onovyAND use swift-dispersion-report19:32
onovythis is really usefull when you adding new devices19:33
*** dmorita has joined #openstack-swift19:33
onovylcurtis: then you can have this nice graph: http://s14.postimg.org/nmuind7ep/staz_eny_soubor.png19:34
*** diazjf has joined #openstack-swift19:34
onovy100% = everything balanced19:34
notmynameonovy: what coverage percent are you using in the dispersion report?19:35
onovynotmyname: need to look19:35
notmynameplease be 100. please be 100. please be 10019:35
notmyname;-)19:35
claygtimburke: hit me up for a review when you think you're close on the ec-frag-audit bug19:35
onovycont_pct_found = round(data['container']['pct_found'], 2)19:36
onovycont_retries = data['container']['retries']19:36
onovycont_overlapping = data['container']['overlapping']19:36
onovyobj_pct_found = round(data['object']['pct_found'], 2)19:36
onovyobj_retries = data['object']['retries']19:36
onovyobj_overlapping = data['object']['overlapping']19:36
onovyfrom JSON: swift-dispersion-report -j19:36
onovyand coverage is 1-2 % i think19:37
notmynameah. some other deployers have found that it's a really good idea to have 100% of the partition space covered with the dispersion report19:38
onovyhmm, do you have any explaination for it? :)19:38
openstackgerritPeter Chng proposed openstack/swift: Ensure sysmeta is written/updated on (fast) POST  https://review.openstack.org/26654519:40
*** janonymous has quit IRC19:40
notmynameI'm sure there's a curve somewhere of probability of finding issues vs percent coverage you have in a cluster of a given size (drives and partitions). but basically it comes down to relatively small storage cost traded against the probability of finding errors19:40
ahaleyeah we run both 100% and default - cos sometimes its really important to really know. and other times who wants to wait that long to find out19:40
onovyahale: so you have two accounts for swift_mon?19:40
onovyone with 1 % and one with 100 %?19:40
ahaleyeah19:40
notmynamewould be interesting to do the math and figure out when you cross 50% or 95% or 99%19:40
onovyi don't want to touch/GET 524288 objects from swift every 5 minutes just for graph :)19:41
notmynameheh19:41
onovybut that solutions with two acc looks good19:42
onovyeven now i'm geting dispersion only every 15 minutes, because i don't want to bother swift with it19:42
notmynameahale: how often do you run the 100% one? every day? hour? week?19:43
onovywe are using disp-report only for monitoring of balance progress19:43
onovyis there anything more what can i get from it?19:43
ahalemanually notmyname19:43
notmynameonce-every-ahale19:44
onovy:]19:44
ahaleoh hell no, way more often than an ahale :)19:44
notmynameonovy: balance progress, yes. also you can see background failure issues with it if you have 100% coverage. eg if a drive fails, you'll see that get replicated to handoffs and back as the drive is replaced19:45
dimasothi all19:45
notmynamehello19:45
onovynotmyname: if drive fails, i can see it in swift-recon in drive-audit as umounted19:45
dimasotclayg: following our yesterday conversation - https://github.com/DmitrySot/data_mover19:46
onovybut exactly it's funny, we didn't have any disk failures yet :)19:46
ahale...today? :)19:46
notmynamelol19:46
onovyahale: hey! no.19:47
onovybut it's ok. i'm developer, not admin. not my problem19:47
*** dmorita has quit IRC19:47
ahale:D19:48
*** silor has quit IRC19:52
*** dmorita has joined #openstack-swift20:03
Zyric Good morning20:06
notmynamehello20:07
*** dmorita has quit IRC20:08
*** dmorita has joined #openstack-swift20:10
notmynamesarafraj: welcome!20:10
claygdimasot: I think it would be useful to udpate the docstring of build_moving_map with a literal sample of the structure of the return value20:11
claygdimasot: the key in particular seems confusing -> https://github.com/DmitrySot/data_mover/blob/master/data_mover.py#L11020:11
* notmyname needs to go pick up some lunch20:11
*** zhill has joined #openstack-swift20:12
dimasotclayg: agree I just wanted it to be unique - to allow fast check if a given device shoudl care about a given partition, or it will be done by anothe server/device20:19
*** dmorita has quit IRC20:19
dimasotclayg: so how you suggest to change it? - or you want me to add some comment that discribes how it would look like ?20:20
claygdimasot: honstly i'm looking at it now (moving_map_dump.txt) and it's not any more clear :P20:21
claygdimasot: the keys seem to be maybe... <replica>_<partnum> ?20:22
claygdimasot: nope that's not it - maybe <devid>_<partnum20:22
dimasot<device_id>_<partitions_id>20:23
claygdimasot: and the value is maybe [<part>, <old_dev_id>, <new_dev_id>] ?20:23
dimasotyep, now I got your comment, the variable names are really not self contein20:24
claygdimasot: in the common case as I understand it job['nodes'] is always a list of one in this impelemntation?20:24
*** john_bar has quit IRC20:24
blmartinmattoliverau: I found the other bug that was causing rsync to drop existing pivots. The pull request is setup against your repo.20:24
dimasotyep, this is the legacy from replicaton code - should be removed20:24
claygdimasot: hrmm... it seems like move spawns update, but then - oic if the spawned update fails it appends to the retrie_list and run_once will give it a few more shots20:27
clayg.. but all the work is expected to be handled by the time you return from move20:27
claygdimasot: yeah these data structure manipulation feels somewhat disorganized :\20:29
openstackgerritOndřej Nový proposed openstack/swift: Allow to change auditor sleep interval in config  https://review.openstack.org/26656120:29
openstackgerritJonathan Hinson proposed openstack/swift: Functional tests for if-match with multiple etags  https://review.openstack.org/26651620:30
onovycan someone look to https://review.openstack.org/#/c/251151/ pls?20:31
dimasotI added this retrie_list since I observed that at some cases I have ~10 out of ~40k partitions failed - so it was a path to catchup that failures20:33
dimasotagree it shoul dbe done in more accurate way20:33
claygdimasot: yeah that's fine, not really germaine20:34
claygdimasot: I think ignoring the sync with other primaries during rebalance is interesting, I think preseeding the new ring by over-replicating to a staging dir is interesting20:36
dimasotI am working now on a slide deck that represents the performance compare with replication based rebalancing20:36
dimasotso i wil lshare it with you too, when it will be ready20:37
claygdimasot: once the data_mover finishes how do you go about slaming the directory tree from data_mover into the regular datadir paths and publishing the new rings - what's your process?20:37
dimasotthis the part that I am working on - I am doing it by runnign an ansible20:38
*** trifon has quit IRC20:38
claygdimasot: well... I don't think it's really a fair "comparison" - well... I mean you can pitch it however you want - but I don't htink it's terribly interesting to discuss it in that context20:39
dimasotbut I plan to make a function that will run locally and check if there exists "mover" directory on swift device and move its content to "objects"20:39
dimasotregards the unfair comparison - what is another option if I what to add 25% capacity to my cluster? r20:40
claygdimasot: patience :P20:41
claygdimasot: i'm kidding - I understand the problem space and use case20:42
dimasot:)20:42
ahalei think there is a huge amount of value in having replication tools that are aware of previous rings :)20:42
claygok, that may be all the brain cells I can devote to it today - i'd encourage you to take another whack at the mover data structure to make it more obvious20:43
redbo_I'm not so sure.  We can tell what's not supposed to be on a drive pretty fast.20:43
dimasotok, will work on it :) thanks for you help20:44
claygredbo_: one idea that's in dimasot's poc that I hadn't consider is the possible value of not having to connect to or discuss a partition with other primaries while focusing on rebalancing20:44
dimasotwill ping you when I will make more progress20:44
redbo_Sounds a lot like "move handoffs first" mode20:45
claygredbo_: currently in the python replicator a handoff partition will skip the pre-flight REPLCIATION request (which is nice to avoid hash suffix recalc and listdir io) - but it still calls rsync agains the remote node20:45
dimasotany other comments except the styling/naming?20:45
redbo_Oh, I see what you're saying.20:45
claygredbo_: I feel pretty strongly it's a variation on that theme - and continue to have interest in patch 21586720:45
patchbotclayg: https://review.openstack.org/#/c/215867/ - Make handoffs_first a more useful "mode"20:45
redbo_So only sync to new locations for that partition for a little while20:46
claygredbo_: well that's one of the main ideas that I see dimasot exploring - and probably matches what ahale is thinking about20:47
claygI'm not entirely sure a richer replication protocol wouldn't be able to make it self-evident with some additional context beyond having to pre-calculate it or distribute old versions of the ring20:48
claygredbo_: maybe it's no so nuts - if rebalance shat out a move_map that you distributed with your rings - i could imagine that replicators might slurp that up and begin chewing on it (kickout out entries for freshly rehomed parts as it processes them) and once the file is consumed it returns to normal sync mode20:51
claygI don't want a crazy five step rebalance process - but a totally optional self managing handoff_first mode at the cost of distributing a new file is starting to sound like it may be on it's way to a not terrible idea20:51
*** daemontool has quit IRC20:52
onovygood night20:53
claygredbo_: yeah you might have to talk me out of this one - I think sending out new ring immediately means you could process the move map directly into the datadirs - which I like for avoiding dentry updates20:54
*** bsdkurt has quit IRC20:54
redbo_I'm not sure you'd want to distribute a new file.  The way it is as an outside controller right now, it prevents every drive in the cluster from trying to sync to the new drive.20:54
claygredbo_: YES!  +220:54
claygredbo_: handoffs_first sucks for that reason!20:54
ahaleoh yeah , i mean im talking vague unexplored ideas, not really dimascots specific thing.. if anything out-of-replication-band tools to brute force specific things to happen right-now20:54
ahaleand sidestep rsycd max connections etc etc20:55
claygredbo_: I've been bitter lately that replicators "restart" when a new ring comes out (intead of just continuing from the part they're currently syncing but you know - using the right nodes because rings already reload)20:55
claygredbo_: in move_map situation where replicators keep running you might let them drop into mover mode after the current cycle finishes - giving some amout of distribution20:56
claygredbo_: that plus max_connections (or getting in the datapath) might allow things to move along a little quicker without eating all the i/o on filling drives20:57
claygwell... new drives might just be hozed regardless20:57
*** dslevin has joined #openstack-swift21:03
*** dmorita has joined #openstack-swift21:03
*** zhill has quit IRC21:04
*** dslevin has quit IRC21:04
*** eranrom has joined #openstack-swift21:05
*** MVenesio has quit IRC21:07
*** nadeem has quit IRC21:13
*** eranrom has quit IRC21:15
*** MVenesio has joined #openstack-swift21:18
*** trifon has joined #openstack-swift21:19
*** zhill has joined #openstack-swift21:20
*** dmorita has quit IRC21:22
*** dmorita has joined #openstack-swift21:24
*** diazjf has quit IRC21:27
*** dslevin has joined #openstack-swift21:30
*** esker has joined #openstack-swift21:30
*** esker has quit IRC21:31
*** esker has joined #openstack-swift21:31
*** diazjf has joined #openstack-swift21:37
*** gyee has joined #openstack-swift21:44
*** petertr7 is now known as petertr7_away21:47
*** dmorita has quit IRC21:47
*** blmartin has quit IRC21:48
*** trifon has quit IRC21:55
mattoliveraumorning21:56
*** diogogmt has quit IRC21:56
pdardeauhi mattoliverau21:56
mattoliveraupdardeau: hey man!21:56
*** petertr7_away is now known as petertr721:57
*** dmorita has joined #openstack-swift21:58
*** dmorita has quit IRC21:58
*** dmorita has joined #openstack-swift21:58
*** bkmz_ has joined #openstack-swift22:03
*** bkmz has quit IRC22:06
*** dmorita has quit IRC22:09
*** zhill has quit IRC22:09
*** dmorita has joined #openstack-swift22:10
*** petertr7 is now known as petertr7_away22:11
dimasotclayg: some refactoring done, more comments added - so now I hope it will b emore clear22:14
dimasotso you can take a look when you have time for it22:15
*** jamielennox|away is now known as jamielennox22:17
*** diogogmt has joined #openstack-swift22:20
*** dmorita has quit IRC22:30
*** zhill has joined #openstack-swift22:30
openstackgerritTim Burke proposed openstack/swift: Make object-auditor storage-policy-aware  https://review.openstack.org/26659922:30
timburkeclayg: ^^22:30
*** mingdang1 has joined #openstack-swift22:32
*** dmorita has joined #openstack-swift22:32
*** dmorita has quit IRC22:34
*** dmorita has joined #openstack-swift22:42
*** sarafraj has left #openstack-swift22:53
*** dmorita has quit IRC22:53
*** nadeem has joined #openstack-swift22:53
*** dmorita has joined #openstack-swift22:54
*** dmorita has quit IRC22:54
*** dmorita has joined #openstack-swift22:55
*** km_ has joined #openstack-swift22:56
openstackgerritBill Huber proposed openstack/swift: Re-format the SLO manifest file on new multipart-manifest GET call  https://review.openstack.org/26390223:08
*** nadeem has quit IRC23:11
*** diazjf has quit IRC23:14
*** mragupat has quit IRC23:15
*** mrmoje has quit IRC23:16
*** dmorita has quit IRC23:19
*** mingdang1 has quit IRC23:22
*** kei_yama has joined #openstack-swift23:29
*** asettle has joined #openstack-swift23:30
openstackgerritTim Burke proposed openstack/python-swiftclient: Accept gzip-encoded API responses  https://review.openstack.org/18495623:40
*** logan2 has joined #openstack-swift23:42
openstackgerritTim Burke proposed openstack/python-swiftclient: Use bulk-delete middleware when available  https://review.openstack.org/19088723:42
*** logan2 is now known as logan-23:42
*** ho has joined #openstack-swift23:42
*** ho is now known as Guest5599423:43
*** dmorita has joined #openstack-swift23:44
*** dmorita has quit IRC23:45
openstackgerritTim Burke proposed openstack/python-swiftclient: Drop testtools from test-requirements.txt  https://review.openstack.org/25367823:47
*** dmorita has joined #openstack-swift23:48
*** Guest55994 is now known as ho_23:49
ho_good morning!23:53
notmynamehello23:59

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