| *** kei_yama_ has joined #openstack-swift | 00:01 | |
| *** kei_yama has quit IRC | 00:02 | |
| *** asettle has quit IRC | 00:04 | |
| *** ober37_ has joined #openstack-swift | 00:05 | |
| *** hosanai has joined #openstack-swift | 00:06 | |
| *** ChanServ sets mode: +v hosanai | 00:06 | |
| *** asettle has joined #openstack-swift | 00:06 | |
| *** ober37 has quit IRC | 00:07 | |
| *** ober37 has joined #openstack-swift | 00:18 | |
| *** ober37_ has quit IRC | 00:18 | |
| *** ober37 has left #openstack-swift | 00:18 | |
| *** asettle has quit IRC | 00:19 | |
| *** asettle has joined #openstack-swift | 00:21 | |
| *** ober37 has joined #openstack-swift | 00:28 | |
| *** ekarlso has quit IRC | 00:32 | |
| *** asettle has quit IRC | 00:32 | |
| *** asettle has joined #openstack-swift | 00:32 | |
| *** ober37 has quit IRC | 00:33 | |
| *** asettle has left #openstack-swift | 00:33 | |
| *** asettle has joined #openstack-swift | 00:33 | |
| *** ober37 has joined #openstack-swift | 00:34 | |
| *** ekarlso has joined #openstack-swift | 00:44 | |
| *** ober37 has quit IRC | 00:44 | |
| *** ober37 has joined #openstack-swift | 00:46 | |
| *** mingdang1 has joined #openstack-swift | 00:47 | |
| *** kota_ has joined #openstack-swift | 00:54 | |
| *** ChanServ sets mode: +v kota_ | 00:54 | |
| kota_ | good morning | 00:54 |
|---|---|---|
| *** kei_yama_ has quit IRC | 00:58 | |
| mattoliverau | kota_: morning! | 01:01 |
| *** ober37 has quit IRC | 01:04 | |
| kota_ | mattoliverau: \o/ | 01:05 |
| kota_ | mattoliverau: how's going? | 01:05 |
| mattoliverau | i'm back! well reading lots of email, but back | 01:05 |
| mattoliverau | kota_: its going well, I'm very tired, you parents are crazy, newborns don't sleep well at night :P | 01:06 |
| kota_ | great to hear, welcome to be back!!! | 01:06 |
| kota_ | mattoliverau: exactly, it's heavy work for everyone :) | 01:06 |
| *** asettle has quit IRC | 01:13 | |
| *** ober37 has joined #openstack-swift | 01:14 | |
| *** mingdang1 has quit IRC | 01:17 | |
| *** ober37_ has joined #openstack-swift | 01:17 | |
| *** ober37 has quit IRC | 01:18 | |
| *** kei_yama has joined #openstack-swift | 01:20 | |
| *** ober37_ has quit IRC | 01:22 | |
| *** ober37 has joined #openstack-swift | 01:22 | |
| *** asettle has joined #openstack-swift | 01:25 | |
| *** rchurch_ has quit IRC | 01:34 | |
| *** takashi has joined #openstack-swift | 01:34 | |
| *** rchurch has joined #openstack-swift | 01:34 | |
| takashi | good morning | 01:34 |
| *** asettle has quit IRC | 01:49 | |
| *** asettle has joined #openstack-swift | 01:50 | |
| *** ober37 has quit IRC | 01:54 | |
| *** ober37 has joined #openstack-swift | 01:54 | |
| *** ober37 has quit IRC | 01:59 | |
| *** rchurch has quit IRC | 01:59 | |
| notmyname | hello, world | 02:00 |
| *** asettle has quit IRC | 02:04 | |
| *** asettle has joined #openstack-swift | 02:04 | |
| kota_ | takashi, notmyname: hello | 02:11 |
| notmyname | http://lists.openstack.org/pipermail/openstack-dev/2016-April/092505.html is a very interesting email thread (and etherpad) | 02:11 |
| kota_ | looks interesting. | 02:12 |
| notmyname | the question of "what to do with global requirements" (if that's ever come up for you) seems to be addressed there | 02:14 |
| notmyname | including, "should swift merge global requirements updates or not?" | 02:15 |
| *** Jeffrey4l has joined #openstack-swift | 02:15 | |
| zaitcev | propose that we drop our requirement for co-installability of all services ... each project manage its own versions of dependencies ... by relying on containers for deployment | 02:16 |
| zaitcev | This guy is mad | 02:16 |
| notmyname | zaitcev: maybe. or maybe he's just in the whole new docker docker docker world an we havne't caught up yet ;-) | 02:17 |
| notmyname | my point being, it's good to talk about it | 02:17 |
| zaitcev | notmyname: yeah... | 02:17 |
| jrichli | mattoliverau: welcome back! Will you be at the summit, or spending time with baby that week? | 02:28 |
| *** asettle has quit IRC | 02:33 | |
| *** asettle has joined #openstack-swift | 02:34 | |
| *** haomaiwang has joined #openstack-swift | 02:45 | |
| mattoliverau | jrichli: I'll be in Austin :) | 02:53 |
| mattoliverau | takashi, notmyname, jrichli zaitcev: o/ | 02:53 |
| zaitcev | mattoliverau: sounds great, see you there | 02:54 |
| *** janonymous has joined #openstack-swift | 02:58 | |
| notmyname | Vinsh: someone just pointed this out to me (actually it was hugokuo) https://github.com/openstack/keystonemiddleware/blob/6e58f8620ae60eb4f26984258d15a9823345c310/releasenotes/notes/deprecate-caching-tokens-in-process-a412b0f1dea84cb9.yaml | 02:59 |
| *** haomaiwang has quit IRC | 03:01 | |
| *** haomaiwang has joined #openstack-swift | 03:01 | |
| takashi | kota_, mattoliverau: o/ | 03:17 |
| *** asettle has quit IRC | 03:20 | |
| *** takashi has quit IRC | 03:24 | |
| *** takashi has joined #openstack-swift | 03:31 | |
| *** haomaiwang has quit IRC | 03:41 | |
| *** haomaiwa_ has joined #openstack-swift | 03:41 | |
| *** garthb has joined #openstack-swift | 03:42 | |
| *** trifon has joined #openstack-swift | 03:52 | |
| *** haomaiwa_ has quit IRC | 04:01 | |
| *** haomaiwa_ has joined #openstack-swift | 04:01 | |
| *** haomaiwa_ has quit IRC | 04:01 | |
| *** asettle has joined #openstack-swift | 04:01 | |
| *** 7JTAAPGO1 has joined #openstack-swift | 04:01 | |
| *** garthb has quit IRC | 04:11 | |
| *** garthb has joined #openstack-swift | 04:11 | |
| mahatic | good morning | 04:14 |
| *** garthb has quit IRC | 04:14 | |
| *** garthb has joined #openstack-swift | 04:14 | |
| *** mingdang1 has joined #openstack-swift | 04:18 | |
| *** trifon has quit IRC | 04:18 | |
| mattoliverau | mahatic: morning | 04:18 |
| mahatic | mattoliverau: hello! welcome back :) | 04:18 |
| mattoliverau | mahatic: thanks :) | 04:19 |
| *** garthb has quit IRC | 04:21 | |
| *** mingdang1 has quit IRC | 04:22 | |
| *** ekarlso has quit IRC | 04:27 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 04:28 |
| *** ekarlso has joined #openstack-swift | 04:40 | |
| *** links has joined #openstack-swift | 04:41 | |
| *** ober37 has joined #openstack-swift | 04:56 | |
| *** trifon has joined #openstack-swift | 04:57 | |
| *** ober37 has quit IRC | 05:00 | |
| *** 7JTAAPGO1 has quit IRC | 05:01 | |
| *** haomaiwang has joined #openstack-swift | 05:01 | |
| *** rcernin has joined #openstack-swift | 05:04 | |
| *** citytiming has joined #openstack-swift | 05:15 | |
| *** arch-nemesis has joined #openstack-swift | 05:16 | |
| *** nadeem has joined #openstack-swift | 05:18 | |
| *** ppai has joined #openstack-swift | 05:25 | |
| *** citytiming has quit IRC | 05:25 | |
| *** haomaiwang has quit IRC | 05:28 | |
| *** trifon has quit IRC | 05:32 | |
| *** klrmn has quit IRC | 05:48 | |
| *** zaitcev has quit IRC | 05:50 | |
| *** ChubYann has quit IRC | 05:50 | |
| *** Jeffrey4l has quit IRC | 05:50 | |
| *** ober37 has joined #openstack-swift | 05:57 | |
| *** ober37 has quit IRC | 06:01 | |
| *** mingdang1 has joined #openstack-swift | 06:05 | |
| *** nadeem has quit IRC | 06:16 | |
| *** nadeem has joined #openstack-swift | 06:17 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Imported Translations from Zanata https://review.openstack.org/306924 | 06:31 |
| *** haomaiwang has joined #openstack-swift | 06:46 | |
| *** haomaiwang has quit IRC | 07:01 | |
| *** haomaiwang has joined #openstack-swift | 07:01 | |
| *** wuhg has joined #openstack-swift | 07:02 | |
| *** mingdang1 has quit IRC | 07:08 | |
| *** haomaiwang has quit IRC | 07:11 | |
| *** sw3 has quit IRC | 07:15 | |
| *** pcaruana has joined #openstack-swift | 07:15 | |
| *** rledisez has joined #openstack-swift | 07:16 | |
| *** mmcardle has joined #openstack-swift | 07:18 | |
| onovy | hi all. already read https://swiftstack.com/blog/2013/12/20/upgrade-openstack-swift-no-downtime/ and have a question :) | 07:20 |
| onovy | can i upgrade swift-store inside one region, then uprade all proxy inside one region and then go to another one region? | 07:20 |
| onovy | proxy is "forward" compatible, but are backward too? | 07:21 |
| onovy | so can proxy 2.5.0 communicate with 2.3.0 store? | 07:21 |
| onovy | i guess yes, but want to be sure :) | 07:21 |
| *** mmcardle1 has joined #openstack-swift | 07:22 | |
| openstackgerrit | Merged openstack/swift: Per container stat. report https://review.openstack.org/281814 | 07:23 |
| *** mmcardle has quit IRC | 07:23 | |
| *** arch-nemesis has quit IRC | 07:31 | |
| *** asettle has quit IRC | 07:52 | |
| *** geaaru has joined #openstack-swift | 07:53 | |
| *** oro has joined #openstack-swift | 07:58 | |
| *** ober37 has joined #openstack-swift | 07:59 | |
| *** asettle has joined #openstack-swift | 08:02 | |
| *** ober37 has quit IRC | 08:03 | |
| *** asettle has quit IRC | 08:07 | |
| *** siva_kri- has quit IRC | 08:12 | |
| *** siva_krishnan_ has joined #openstack-swift | 08:16 | |
| *** jmccarthy has quit IRC | 08:16 | |
| *** daemontool has quit IRC | 08:17 | |
| *** jmccarthy has joined #openstack-swift | 08:17 | |
| *** nadeem has quit IRC | 08:20 | |
| *** joeljwright has joined #openstack-swift | 08:20 | |
| *** ChanServ sets mode: +v joeljwright | 08:20 | |
| *** jistr has joined #openstack-swift | 08:21 | |
| openstackgerrit | Merged openstack/swift: Imported Translations from Zanata https://review.openstack.org/306924 | 08:34 |
| *** acoles_ is now known as acoles | 08:53 | |
| acoles | mattoliverau: welcome back! | 08:57 |
| *** tesseract has joined #openstack-swift | 09:03 | |
| *** tesseract is now known as Guest30394 | 09:03 | |
| *** oro has quit IRC | 09:04 | |
| *** jistr has quit IRC | 09:05 | |
| *** ozeri has joined #openstack-swift | 09:08 | |
| *** jistr has joined #openstack-swift | 09:12 | |
| *** sheel has joined #openstack-swift | 09:15 | |
| openstackgerrit | dharmendra kushwaha proposed openstack/swift-specs: Pass environment variables of proxy to tox https://review.openstack.org/264140 | 09:24 |
| *** asettle has joined #openstack-swift | 09:36 | |
| *** mingdang1 has joined #openstack-swift | 09:45 | |
| *** mingdang1 has quit IRC | 09:49 | |
| *** asettle has quit IRC | 10:03 | |
| *** ober37 has joined #openstack-swift | 10:13 | |
| *** hosanai has quit IRC | 10:17 | |
| *** mingdang1 has joined #openstack-swift | 10:17 | |
| *** ober37 has quit IRC | 10:20 | |
| alholano1a | I tested Swift a few months ago and now I tried usage of Storage Policies, but I met a few problems. I have 5 node configuration (2 proxy nodes, 3 storage nodes), I set rings to two replicas, but containers are stored still on all three storage nodes. I am not sure, if I should set Storage Policy in swift.conf on all nodes - proxy and storages nodes, or only some of them? | 10:22 |
| *** SkyRocknRoll has joined #openstack-swift | 10:30 | |
| *** daemontool has joined #openstack-swift | 10:38 | |
| *** asettle has joined #openstack-swift | 10:54 | |
| *** mahatic_ has joined #openstack-swift | 11:02 | |
| *** zhiyan_ has joined #openstack-swift | 11:02 | |
| *** marcusvrn__ has joined #openstack-swift | 11:02 | |
| *** Lickitysplitted_ has joined #openstack-swift | 11:02 | |
| *** cppforlife__ has joined #openstack-swift | 11:02 | |
| *** swiftfan_ has joined #openstack-swift | 11:04 | |
| *** dfg_ has joined #openstack-swift | 11:04 | |
| *** redbo_ has joined #openstack-swift | 11:04 | |
| *** tristanC_ has joined #openstack-swift | 11:04 | |
| *** BAKfr_ has joined #openstack-swift | 11:04 | |
| *** mariusv_ has joined #openstack-swift | 11:05 | |
| *** thurloat_ has joined #openstack-swift | 11:05 | |
| *** joearnold_ has joined #openstack-swift | 11:05 | |
| *** dmellado_ has joined #openstack-swift | 11:05 | |
| *** cschwede_ has joined #openstack-swift | 11:05 | |
| *** ChanServ sets mode: +v cschwede_ | 11:05 | |
| *** hugokuo_ has joined #openstack-swift | 11:05 | |
| *** cppforlife_ has quit IRC | 11:05 | |
| *** marcusvrn_ has quit IRC | 11:05 | |
| *** blair has quit IRC | 11:05 | |
| *** BAKfr has quit IRC | 11:05 | |
| *** mmotiani has quit IRC | 11:05 | |
| *** timburke has quit IRC | 11:05 | |
| *** hrou_ has quit IRC | 11:05 | |
| *** joearnold has quit IRC | 11:05 | |
| *** Lickitysplitted has quit IRC | 11:05 | |
| *** tdasilva has quit IRC | 11:05 | |
| *** swiftfan has quit IRC | 11:05 | |
| *** mathiasb_ has quit IRC | 11:05 | |
| *** thurloat has quit IRC | 11:05 | |
| *** pdardeau has quit IRC | 11:06 | |
| *** serverascode has quit IRC | 11:06 | |
| *** zhiyan has quit IRC | 11:06 | |
| *** rushiagr has quit IRC | 11:06 | |
| *** briancli1e has quit IRC | 11:06 | |
| *** hugokuo has quit IRC | 11:06 | |
| *** dmellado has quit IRC | 11:06 | |
| *** dfg has quit IRC | 11:06 | |
| *** mariusv has quit IRC | 11:06 | |
| *** saltsa has quit IRC | 11:06 | |
| *** tristanC has quit IRC | 11:06 | |
| *** redbo has quit IRC | 11:06 | |
| *** cschwede has quit IRC | 11:06 | |
| *** tanee has quit IRC | 11:06 | |
| *** sc has quit IRC | 11:06 | |
| *** jaakkos has quit IRC | 11:06 | |
| *** mahatic has quit IRC | 11:06 | |
| *** briancline has joined #openstack-swift | 11:06 | |
| *** jaakkos has joined #openstack-swift | 11:06 | |
| *** BAKfr_ is now known as BAKfr | 11:06 | |
| *** thurloat_ is now known as thurloat | 11:06 | |
| *** cschwede_ is now known as cschwede | 11:06 | |
| *** taneee has joined #openstack-swift | 11:06 | |
| *** hrou has joined #openstack-swift | 11:06 | |
| *** serverascode_ has joined #openstack-swift | 11:06 | |
| *** timburke has joined #openstack-swift | 11:06 | |
| *** ChanServ sets mode: +v timburke | 11:06 | |
| *** hugokuo_ is now known as hugokuo | 11:06 | |
| *** hrou has quit IRC | 11:06 | |
| *** hrou has joined #openstack-swift | 11:06 | |
| *** marcusvrn__ is now known as marcusvrn_ | 11:07 | |
| *** joearnold_ is now known as joearnold | 11:07 | |
| *** mmotiani has joined #openstack-swift | 11:07 | |
| *** cppforlife__ is now known as cppforlife_ | 11:10 | |
| *** zhiyan_ is now known as zhiyan | 11:10 | |
| *** saltsa has joined #openstack-swift | 11:11 | |
| *** rcernin has quit IRC | 11:12 | |
| *** mathiasb has joined #openstack-swift | 11:12 | |
| *** serverascode_ is now known as serverascode | 11:12 | |
| *** pdardeau has joined #openstack-swift | 11:14 | |
| *** tdasilva has joined #openstack-swift | 11:18 | |
| *** rcernin has joined #openstack-swift | 11:23 | |
| *** okdas has quit IRC | 11:25 | |
| *** ozeri has quit IRC | 11:25 | |
| *** sc has joined #openstack-swift | 11:26 | |
| *** okdas has joined #openstack-swift | 11:26 | |
| *** okdas has joined #openstack-swift | 11:26 | |
| *** sc is now known as Guest92477 | 11:26 | |
| *** oro has joined #openstack-swift | 11:28 | |
| *** blair has joined #openstack-swift | 11:29 | |
| *** oro has quit IRC | 11:30 | |
| *** ppai has quit IRC | 11:32 | |
| *** ozeri has joined #openstack-swift | 11:32 | |
| *** taneee is now known as tanee | 11:33 | |
| *** ozeri has quit IRC | 11:37 | |
| *** rushiagr has joined #openstack-swift | 11:39 | |
| *** mmcardle1 has quit IRC | 11:39 | |
| openstackgerrit | Alistair Coles proposed openstack/swift: Encrypt/decrypt etag in container listing https://review.openstack.org/275492 | 11:41 |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - add functional test to verify container listing detail https://review.openstack.org/307121 | 11:41 |
| *** ppai has joined #openstack-swift | 11:46 | |
| *** asettle has quit IRC | 11:50 | |
| *** asettle has joined #openstack-swift | 11:50 | |
| *** cdelatte has joined #openstack-swift | 11:52 | |
| *** takashi has quit IRC | 11:57 | |
| *** asettle has quit IRC | 12:03 | |
| *** mmcardle has joined #openstack-swift | 12:03 | |
| *** ppai has quit IRC | 12:03 | |
| *** mtreinish has joined #openstack-swift | 12:03 | |
| *** ozeri has joined #openstack-swift | 12:06 | |
| *** Guest23578 has quit IRC | 12:09 | |
| *** ppai has joined #openstack-swift | 12:19 | |
| *** christian has quit IRC | 12:23 | |
| *** wuhg has quit IRC | 12:30 | |
| *** oshritf has joined #openstack-swift | 12:34 | |
| *** oshritf has quit IRC | 12:34 | |
| *** ober37 has joined #openstack-swift | 12:39 | |
| *** ober37_ has joined #openstack-swift | 12:40 | |
| *** mwheckmann has joined #openstack-swift | 12:42 | |
| *** ober37 has quit IRC | 12:43 | |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - verify that x-object-meta-etag does not confuse https://review.openstack.org/305374 | 12:46 |
| *** pauloewerton has joined #openstack-swift | 12:55 | |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - only set body crypto meta if body is read and encrypted https://review.openstack.org/305794 | 12:56 |
| *** kei_yama has quit IRC | 12:56 | |
| Vinsh | notmyname: Interesting RE the keystone-middleware.. I have not been using in-process cache though. | 12:59 |
| *** klamath has joined #openstack-swift | 13:11 | |
| *** mingdang1 has quit IRC | 13:18 | |
| *** ppai has quit IRC | 13:34 | |
| *** rchurch has joined #openstack-swift | 13:40 | |
| *** BigWillie has joined #openstack-swift | 13:41 | |
| *** ChanServ sets mode: +v tdasilva | 13:47 | |
| *** sgundur1 has joined #openstack-swift | 13:48 | |
| *** ober37_ has left #openstack-swift | 13:49 | |
| *** ober37_ has joined #openstack-swift | 13:49 | |
| *** SkyRocknRoll has quit IRC | 13:54 | |
| *** SkyRocknRoll_ has joined #openstack-swift | 13:54 | |
| *** links has quit IRC | 13:57 | |
| *** bhakta has quit IRC | 13:58 | |
| *** ajiang has quit IRC | 13:58 | |
| *** ajiang has joined #openstack-swift | 13:59 | |
| *** bhakta has joined #openstack-swift | 13:59 | |
| *** bkeller` has quit IRC | 14:01 | |
| *** aj701_ has quit IRC | 14:01 | |
| *** zaitcev has joined #openstack-swift | 14:02 | |
| *** ChanServ sets mode: +v zaitcev | 14:02 | |
| *** ametts has joined #openstack-swift | 14:04 | |
| *** bkeller` has joined #openstack-swift | 14:04 | |
| *** aj701 has joined #openstack-swift | 14:05 | |
| *** arch-nemesis has joined #openstack-swift | 14:07 | |
| *** janonymous has quit IRC | 14:22 | |
| *** wasmum has quit IRC | 14:23 | |
| *** ober37_ has quit IRC | 14:26 | |
| *** ober37 has joined #openstack-swift | 14:28 | |
| *** wasmum has joined #openstack-swift | 14:32 | |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - only set body crypto meta if body is read and encrypted https://review.openstack.org/305794 | 14:36 |
| openstackgerrit | Alistair Coles proposed openstack/swift: Encrypt/decrypt etag in container listing https://review.openstack.org/275492 | 14:36 |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - verify that x-object-meta-etag does not confuse https://review.openstack.org/305374 | 14:36 |
| openstackgerrit | Alistair Coles proposed openstack/swift: crypto - cleanup decrypter exception handling https://review.openstack.org/304806 | 14:36 |
| *** dmsimard has quit IRC | 14:42 | |
| *** dmsimard has joined #openstack-swift | 14:43 | |
| *** ozeri has quit IRC | 14:55 | |
| *** asettle has joined #openstack-swift | 15:08 | |
| *** garthb has joined #openstack-swift | 15:12 | |
| *** asettle has quit IRC | 15:13 | |
| *** SkyRocknRoll_ has quit IRC | 15:14 | |
| *** ober37 has quit IRC | 15:15 | |
| *** ober37 has joined #openstack-swift | 15:16 | |
| pdardeau | mattoliverau: welcome back! | 15:17 |
| *** links has joined #openstack-swift | 15:19 | |
| *** ober37 has quit IRC | 15:20 | |
| gmmaha | mattoliverau: welcome back | 15:21 |
| *** m3m0 has joined #openstack-swift | 15:41 | |
| m3m0 | heys guys, is there a way to get notified if an object gets upload to swift? | 15:41 |
| *** hurricanerix has joined #openstack-swift | 15:43 | |
| *** gyee has joined #openstack-swift | 15:43 | |
| *** Guest67912 has joined #openstack-swift | 15:44 | |
| *** Guest67912 is now known as scotticus | 15:46 | |
| *** lakshmiS has joined #openstack-swift | 15:50 | |
| clayg | heyoh! | 15:57 |
| clayg | alholano1a: storage policies are for object rings only - the account & container rings are seperate configuration than from the policies defined in swift.conf | 15:58 |
| clayg | onovy: it's more commonly the case that a 2.3.0 proxy can communicate with 2.5.0 storage layer just fine | 15:59 |
| *** tqtran has joined #openstack-swift | 16:00 | |
| *** links has quit IRC | 16:01 | |
| *** Guest30394 has quit IRC | 16:05 | |
| timburke | good morning | 16:05 |
| *** raginbajin has quit IRC | 16:05 | |
| *** ober37 has joined #openstack-swift | 16:05 | |
| *** gyee has quit IRC | 16:06 | |
| *** ober37 has quit IRC | 16:07 | |
| *** ober37 has joined #openstack-swift | 16:07 | |
| *** raginbajin has joined #openstack-swift | 16:10 | |
| *** chsc has joined #openstack-swift | 16:10 | |
| *** lyrrad has joined #openstack-swift | 16:17 | |
| *** rledisez has quit IRC | 16:21 | |
| *** pcaruana has quit IRC | 16:21 | |
| notmyname | good morning | 16:31 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 16:35 |
| *** jistr has quit IRC | 16:39 | |
| *** tqtran has quit IRC | 16:40 | |
| *** itlinux has joined #openstack-swift | 16:42 | |
| *** rcernin has quit IRC | 16:43 | |
| *** dmorita has joined #openstack-swift | 16:56 | |
| *** joeljwright has quit IRC | 17:06 | |
| *** ozeri has joined #openstack-swift | 17:07 | |
| *** tqtran has joined #openstack-swift | 17:10 | |
| *** ozeri has quit IRC | 17:12 | |
| *** nadeem has joined #openstack-swift | 17:16 | |
| *** nadeem has quit IRC | 17:16 | |
| *** klrmn has joined #openstack-swift | 17:18 | |
| *** nadeem has joined #openstack-swift | 17:23 | |
| *** mmcardle has quit IRC | 17:26 | |
| *** jmccarthy1 has joined #openstack-swift | 17:34 | |
| *** ChubYann has joined #openstack-swift | 17:39 | |
| *** geaaru has quit IRC | 17:39 | |
| *** ober37 has left #openstack-swift | 17:41 | |
| *** stevemar has quit IRC | 17:41 | |
| *** stevemar has joined #openstack-swift | 17:44 | |
| *** joeljwright has joined #openstack-swift | 17:48 | |
| *** ChanServ sets mode: +v joeljwright | 17:48 | |
| *** joeljwright has quit IRC | 17:53 | |
| openstackgerrit | Eran Rom proposed openstack/swift: Add process level concurrency to container sync https://review.openstack.org/210099 | 17:54 |
| openstackgerrit | Tim Burke proposed openstack/python-swiftclient: Guard against post-as-copy flattening large objects https://review.openstack.org/303647 | 17:55 |
| notmyname | jrichli: I know the goal has been for a good, working crypto branch by the end of this week. where are we? | 18:07 |
| *** gyee has joined #openstack-swift | 18:07 | |
| notmyname | https://wiki.openstack.org/wiki/Swift/PriorityReviews only has 2 patches listed (that's great!), but the copy middleware still hasn't landed | 18:07 |
| jrichli | oh, good, acoles is still around for this answer :-) | 18:07 |
| notmyname | kota_ and timburke and tdasilva have been looking at copy middleware it seems | 18:08 |
| notmyname | :-) | 18:08 |
| tdasilva | notmyname: yep, kota_ left some comments, I need to get back to him | 18:08 |
| jrichli | acoles has been working like a beast the last couple weeks! A lot of improvements have been made. he has been creating one or two new patches for every one that gets merged ;-) | 18:08 |
| acoles | notmyname: i moved some of the less urgent crypto reviews off the priority review page and replaced with a link to gerrit | 18:09 |
| notmyname | ah, ok. makes sense | 18:09 |
| jrichli | but yes, COPY is still the thing missing | 18:09 |
| notmyname | jrichli: yeah, those high-productivity devs who are so hard to keep up with ;-) | 18:09 |
| jrichli | I know! since he is pretty much all crypto all the time now, it is even more clear how productive he is :-) | 18:10 |
| acoles | notmyname: this week jrichli and i are focussing on re-instating some of the key management stuff that got taken out to cope with missing support that is now in place | 18:10 |
| acoles | and prep for summit | 18:10 |
| notmyname | great | 18:11 |
| notmyname | please let me know asap if/how I can help with your summit talk | 18:11 |
| jrichli | I am also focusing on crypto explanations - especially with the etag scheme | 18:11 |
| notmyname | mahatic_: ^ you too | 18:11 |
| acoles | notmyname: thanks | 18:11 |
| notmyname | jrichli: this is how I normally feel about crypto explanations: https://s-media-cache-ak0.pinimg.com/736x/17/f3/95/17f395a4fe61b28a4efbd92002231848.jpg | 18:12 |
| jrichli | lol! I wont get too deep unless provoked ;-) | 18:14 |
| notmyname | tdasilva: with copy as post, who's been reviewing that? is it just kota_ and timburke? | 18:14 |
| acoles | notmyname: possibly stupid question... if we were to merge the 2 copy related patches on feature/crypto simply so we have something working and easy to manage (i.e. not having to cherry pick) how hard is it to then revert those when the equivalent patches land on master? would that be a bad way to go? i'm just after an easy life this week! | 18:14 |
| jrichli | but I do want to be able to get deep outside the talk as well | 18:14 |
| jrichli | we do have some concerns to bring to reaperhulk | 18:15 |
| tdasilva | notmyname: mattoliverau had also reviewed before his paternity leave | 18:15 |
| tdasilva | mattoliverau: welcome back!!! :) | 18:15 |
| notmyname | acoles: it all depends on if/how they change before landing on master. I *think* if they land as-is, then it should be pretty clean. however, I'd probably want to do a simulated test to actually verify that (eg build a small git repo and land a patch on both then try a merge and see what happens) | 18:16 |
| acoles | mattoliverau's memory will have been erased of everything BC (before child) | 18:16 |
| notmyname | heh | 18:16 |
| notmyname | yeah | 18:16 |
| tdasilva | lol | 18:16 |
| notmyname | ok, so we need mattoliverau to dive back into it then (and/or another core). kota_'s going to be mostly unavailable this week | 18:16 |
| notmyname | acoles: which means it might be good to try the early merge to crypto | 18:17 |
| tdasilva | notmyname: oh, ok | 18:17 |
| kota_ | Sorry | 18:17 |
| notmyname | kota_: no worries! | 18:17 |
| acoles | notmyname: k, i'll ponder it some more | 18:18 |
| notmyname | kota_: if I remember your most recent review on it, there was just a minor thing. tdasilva, if that's the case, then it would probably be ok for 1 +2 after addressing it (depending on the scope of change) | 18:18 |
| notmyname | does that make sense? or make anyone extra nervous? | 18:19 |
| kota_ | K | 18:20 |
| kota_ | So, Maybe merge able | 18:22 |
| kota_ | Wait, boot on laptop | 18:22 |
| clayg | whooooo! Is everyone having fun!? OSD is right around the corner! | 18:23 |
| kota_ | back with laptop keyboad. | 18:25 |
| kota_ | tdasilva: the last peice I'm wondering in the versioned_writes patch is if swift can return EntityTooLarge when the source response has no content-length. | 18:26 |
| kota_ | probably, it keeps current Swift behavior because handle_copy_request in proxy app looks to have similar code. | 18:27 |
| kota_ | but I had an idea how it works in transfer-encoding: chunked response (storlets things might get nervous). | 18:28 |
| kota_ | not sure, for now, but... it might be ok we can consider around there *after* landed. | 18:30 |
| kota_ | so, sorry I'm waffling. | 18:33 |
| kota_ | anyways, it looks to get good shape for the scope definately. | 18:34 |
| timburke | kota_: i'm reasonably confident that swift will properly 413; the existing content_length is None check is an attempt to save us some bandwidth for a request that would *probably* fail | 18:34 |
| tdasilva | kota_: no worries, but you are right, the code is very similar to what was already done in handle_copy_request and also in the copy middleware | 18:34 |
| timburke | kota_: also, you should be asleep right now. go sleep. | 18:34 |
| * tdasilva was wondering if kota_ is already in the US.... | 18:35 | |
| kota_ | timburke: yup, it's *probably* fail... | 18:37 |
| kota_ | tdasilva: I'm in JST :) | 18:37 |
| tdasilva | kota_: have to agree with timburke, go sleep ;) | 18:38 |
| *** silor has joined #openstack-swift | 18:39 | |
| kota_ | tdasilva, timburke: thanks | 18:41 |
| *** silor1 has joined #openstack-swift | 18:44 | |
| *** silor has quit IRC | 18:44 | |
| *** silor1 is now known as silor | 18:44 | |
| *** jmccarthy1 has quit IRC | 18:49 | |
| *** StraubTW has joined #openstack-swift | 18:51 | |
| *** ametts has quit IRC | 19:00 | |
| *** bkeller^ has joined #openstack-swift | 19:04 | |
| *** bkeller^ has quit IRC | 19:04 | |
| *** ober37 has joined #openstack-swift | 19:08 | |
| *** ober37 has quit IRC | 19:08 | |
| *** ober37 has joined #openstack-swift | 19:08 | |
| *** bkeller^ has joined #openstack-swift | 19:09 | |
| *** sheel has quit IRC | 19:15 | |
| *** raginbajin has quit IRC | 19:16 | |
| *** bkeller`- has joined #openstack-swift | 19:16 | |
| *** ametts has joined #openstack-swift | 19:17 | |
| *** acoles is now known as acoles_ | 19:17 | |
| *** raginbajin has joined #openstack-swift | 19:21 | |
| *** bkeller`- has quit IRC | 19:23 | |
| *** bkeller^ has quit IRC | 19:23 | |
| *** bkeller^ has joined #openstack-swift | 19:23 | |
| *** bkeller` has quit IRC | 19:24 | |
| *** bkeller^ is now known as bkeller` | 19:24 | |
| *** ober37` has joined #openstack-swift | 19:25 | |
| *** mminesh has joined #openstack-swift | 19:27 | |
| *** chsc has quit IRC | 19:35 | |
| *** _erick0zcr has joined #openstack-swift | 19:35 | |
| *** mmcardle has joined #openstack-swift | 19:37 | |
| *** mmcardle has quit IRC | 19:56 | |
| *** delattec has joined #openstack-swift | 19:57 | |
| *** lakshmiS has quit IRC | 19:59 | |
| *** lakshmiS_ has joined #openstack-swift | 19:59 | |
| *** cdelatte has quit IRC | 19:59 | |
| openstackgerrit | Merged openstack/swift: Removing unused clause https://review.openstack.org/254278 | 20:01 |
| *** delattec has quit IRC | 20:02 | |
| *** delattec has joined #openstack-swift | 20:07 | |
| *** diazjf has joined #openstack-swift | 20:20 | |
| *** diazjf has quit IRC | 20:23 | |
| *** ober37 has quit IRC | 20:27 | |
| *** ober37` is now known as ober37 | 20:27 | |
| *** zaitcev has quit IRC | 20:29 | |
| *** zaitcev has joined #openstack-swift | 20:30 | |
| *** ChanServ sets mode: +v zaitcev | 20:30 | |
| MooingLemur | is there any process written that could look for leaked/orphaned objects? I suspect they'd be rare, but I suppose it could happen if you introduced a node that had been gone beyond the maximum age of a tombstone. Unlike some other forms of stale data (such as rsync dotfiles), it would apparently persist due to replication because there's no interaction with container listings for any of the | 20:30 |
| MooingLemur | object auditing code that I can find. | 20:30 |
| notmyname | no | 20:31 |
| MooingLemur | I suppose looking for and acting upon such things could be racelike though anyway | 20:31 |
| notmyname | what you'd need to do is sync the objects against the container DBs. and yeah. there are still some races there too | 20:31 |
| *** alholano1a has quit IRC | 20:32 | |
| *** ober37_ has joined #openstack-swift | 20:32 | |
| notmyname | (like is the delete=true row still in the container db; what about differences between replicas of a container db; etc) | 20:32 |
| clayg | leaking stale datafiles from old nodes over reclaimed tombstones is definately something that happens - we should evanglize being more careful with devices that have been "out of the cluster" for longer than reclaim age | 20:33 |
| MooingLemur | I saw somewhere someone referred to stale object files as "dark matter". | 20:33 |
| clayg | MooingLemur: you really have to audit from the disk's back up to the container listings - it's a real hozer | 20:33 |
| MooingLemur | thought that was a good description :) | 20:33 |
| clayg | "dark *data*" | 20:34 |
| clayg | it's like big data - but less well understood by scientists - we know it exists tho - but there theoretical models math doesn't always work out in practice ;) | 20:34 |
| notmyname | lol | 20:34 |
| MooingLemur | :) | 20:34 |
| *** BigWillie has quit IRC | 20:34 | |
| clayg | MooingLemur: this one time someone had a brilliant idea of making the object-auditor look into this sort of thing and it ended up being way to agressive to beat on the container layer like that :\ | 20:36 |
| *** asettle has joined #openstack-swift | 20:37 | |
| *** rickflare has quit IRC | 20:40 | |
| MooingLemur | clayg: This seems like one of the only types of space-claiming cruft that won't decay over time with disk replacements. Maybe there's a middle ground where object-auditor could take on this role but not beat up the container dbs so much. Most of the ideas that are floating in my head don't seem all that good and are at best kludges. | 20:41 |
| *** rickflare has joined #openstack-swift | 20:41 | |
| *** silor has quit IRC | 20:44 | |
| MooingLemur | but I think the best solution for me might be a standalone one, audit like zbf but hit the container db for each one (maybe only objects older than reclaim_age), log something if it isn't found, and recheck those objects all at a later time. | 20:44 |
| MooingLemur | I'll keep thinking about it though. Thanks :) | 20:45 |
| clayg | MooingLemur: yeah I think it'll be more queries up to the conainer layer that you're really going to want to see to run it all the time :\ | 20:52 |
| ahale_ | i advise just trying not to think about stuff like that | 20:54 |
| clayg | ahale_: didn't redbo have an idea with a bloom filter or something one time? | 20:56 |
| *** ober37_ has quit IRC | 20:56 | |
| ahale_ | oh maybe, he has lots of ideas | 20:57 |
| notmyname | ahale_: I know, right? hard drives are just getting bigger--just buy more of them | 20:57 |
| clayg | if you could manage to iter every page of every container in some sort of reasonable time perioid (less that reclaim age) it seems like you could build up a collection of bloomfilters on the cardinality of container servers | 20:57 |
| clayg | ... that should be too big (that's kind of the key thing with bloom filters) | 20:58 |
| clayg | then you just ship them out to the object servers anything that older than reclaim age and not in any of the container layer bloom filters should be dark data | 20:58 |
| clayg | MooingLemur: ^ | 20:58 |
| MooingLemur | oh, interesting thought | 20:58 |
| clayg | the "iter every page of every container" is *very* much dependent on your containers - a few monsters and you're maybe doing as much harm as good :\ | 20:59 |
| clayg | idk, a week or two is a long time - you can fit a lot of i/o in a week - if you maybe keep track of where you're at and do 10K rows a time or something you could just keep sweeping with a little sleep w/o beating on any one container for too long (maybe?) | 21:00 |
| clayg | redbo_: how was that all supposed to work again? | 21:00 |
| redbo_ | clayg: that's basically what we're working on, yeah. Still in the "seeing how long it'll take and how big it'll get" stage. | 21:00 |
| MooingLemur | clayg: true, but there could still be some hash size that would be small enough to be reasonable for the object-auditor to know about | 21:01 |
| notmyname | clayg: keep track of where you're at? like have some table in the container that has a set of high-water marks for various background processes? sounds like a neat idea ;-) | 21:01 |
| clayg | MooingLemur: that's the hope | 21:01 |
| clayg | notmyname: ROFL - i didn't even think of that | 21:01 |
| clayg | notmyname: but you also need to reap out tombstone rows - i had assumed they would expire - like you'd constantly be resetting your high-water marks - I don't think you just keep the same bloomfilter's going forever - your false hit rates would keep getting wrose and worse the longer you use them | 21:02 |
| clayg | notmyname: but still - you could keep track where your at for a time, and once your cycles start looking "done-ish" you ship 'em out the object servers and start a fresh run over the containers (reset the sync points) | 21:03 |
| *** _erick0zcr has quit IRC | 21:03 | |
| clayg | notmyname: but there's not a really terribly compelling arugument for keeping this information in the container db's themselves except that maybe it'd be more robust to rebalances... acctually that might be a somewhat compelling argument :) | 21:03 |
| clayg | notmyname: either way you start with some scripts - it's all going to be highly manual for ages anyways - sort of like our approach to part-power adustment | 21:04 |
| MooingLemur | Either I'm not thinking of it correctly or... the watermarks being in the container db won't necessarily help if you introduce a ridiculously old set of objects after the process has already begun though | 21:04 |
| clayg | just build up the core support in swift - let ops figure out best practices before trying to automate a disaster waiting to happen | 21:04 |
| redbo_ | But basically what we're going to do is pick a date at least relcaim_age old, and old enough that there can't be any async pending files laying around from before that date, and only clean up object files older than that date. | 21:05 |
| clayg | redbo_: +2 | 21:05 |
| *** redbo_ is now known as redbo | 21:05 | |
| *** ChanServ sets mode: +v redbo | 21:06 | |
| clayg | MooingLemur: yeah I think your goal is to sweep out everything older than... 4 months or something - if you've been running the cluster for years that's still a ton of unique hashes that need to be checked tho | 21:06 |
| MooingLemur | or perhaps we can also do something to the process to help ensure old data doesn't get replicated out in the first place | 21:06 |
| clayg | MooingLemur: if there's some newish stuff (that's acctually still dark data) you just have to catch it on the next go round | 21:06 |
| redbo | Then we currently use xfs bulkstat to scan object files. | 21:07 |
| clayg | MooingLemur: yeah - normally if we have a node out for a couple of days those devices get pulled from the ring - and before the old dead boy comes back in he's just wiped and added in as fresh capacity (new swift drive id's) | 21:07 |
| clayg | redbo: how currently uses xfs bulkstat to scan for object files?! | 21:07 |
| clayg | *who | 21:08 |
| redbo | That's what our dark data cleanup script uses | 21:08 |
| clayg | oh... how do you know they're dark? | 21:08 |
| *** ametts has quit IRC | 21:08 | |
| redbo | We bulkstat, read the metadata for each .data file, then compare it to the bloom filter. | 21:08 |
| clayg | OH! so you *have* already done this! well then... how long will it take and how big do they get!? | 21:09 |
| MooingLemur | clayg: yeah, that's usually the process.. but in my case where I suspect I may have introduced dark data, I had messed up some permissions for a couple months by rsyncing some partitions manually off drives I was removing, so they ended up as root:root rather than swift:swift. So replicator couldn't get at them, and I didn't notice. I fixed the permissions but didn't consider there was proba | 21:09 |
| MooingLemur | bly old data (that couldn't be deleted) | 21:09 |
| MooingLemur | Granted, this is likely a tiny drop in the bucket with respect to space on the cluster, but I can't easily verify that that's the case :) | 21:11 |
| *** asettle has quit IRC | 21:11 | |
| clayg | yeah... I mean depending on your situation you may just be able to get away with a script that rolls over the objects dirs and uses internal_clint to start paging container queries into memory? | 21:11 |
| redbo | Well, on our biggest cluster with I don't know how many tens of billions of objects, with an acceptable error rate, the bloom filters are too big. So we're having to build them with some partitioning. | 21:11 |
| clayg | MooingLemur: I was sorta hoping something simple and ad-hoc like that might already be floating around the operations toolboxes out there somewhere? | 21:12 |
| clayg | MooingLemur: I think we have something like - but it's baked into some other tools that might not be appropriate for the public domain :\ | 21:12 |
| notmyname | redbo: have you considered writing it in go? | 21:12 |
| redbo | Then getting the names of all the objects on a healthy drive takes about 30 minutes (but we find a lot of drives aren't healthy and take some hours). And checking those objects against the bloom filter takes a few minutes. | 21:12 |
| clayg | redbo: great info! | 21:13 |
| redbo | How do you know it isn't already written in go?? And no, I don't think it would help this very much. | 21:13 |
| notmyname | just messing with you ;-) | 21:14 |
| *** StraubTW has quit IRC | 21:15 | |
| *** gyee has quit IRC | 21:17 | |
| *** ametts has joined #openstack-swift | 21:17 | |
| MooingLemur | I think I'll do what clayg suggested, run this against the objects on one drive, query the container for every qualified object using internal_client, and see what it looks like | 21:17 |
| *** StraubTW has joined #openstack-swift | 21:18 | |
| *** StraubTW has quit IRC | 21:18 | |
| *** StraubTW has joined #openstack-swift | 21:18 | |
| redbo | We have a script that does that and it helps, but it's so slow we filter it to only check containers for objects above a certain size. | 21:19 |
| MooingLemur | even if I run it sequentially on one host and one drive at a time, and it takes a year for a single pass, it's way better than no audit at all. | 21:19 |
| clayg | redbo: nice! there's dark data - then there's *big* dark data ;) | 21:21 |
| MooingLemur | and then there's dark big data | 21:21 |
| MooingLemur | surveillance :) | 21:22 |
| notmyname | it's a reverse ZBF auditor. you know that most of the data in the cluster is from large objects. so just scan those | 21:22 |
| notmyname | (as opposed to most of the objects in the cluster being small) | 21:22 |
| clayg | MooingLemur: I'm trying to think how you could have the walker feed a worker container names as it finds them - then he pages a container listing into an in-memory set - and only after listing the whole container does the check to see if the name is in the container's set | 21:22 |
| notmyname | redbo: also, if that script is slow, have you considered writing it in go? | 21:23 |
| *** mwheckmann has quit IRC | 21:23 | |
| clayg | MooingLemur: there's lots of trade offs that have to do with how many containers you have and how big they are :\ | 21:23 |
| MooingLemur | clayg: yeah, I think we no longer have the customer that had 100 million objects in a single container :) | 21:23 |
| *** asettle has joined #openstack-swift | 21:23 | |
| notmyname | MooingLemur: no longer have the customer? or that customer no longer has those containers? ;-) | 21:23 |
| * notmyname hopes the latter | 21:24 | |
| MooingLemur | both, heh. | 21:24 |
| MooingLemur | (oh well) | 21:24 |
| notmyname | problem solved! | 21:24 |
| clayg | MooingLemur: you know it's funny - but even 100 million objects fits in a python set somewhat manaageably! I mean I wouldn't want it sitting their in memory for all time... but... well YMMV | 21:24 |
| redbo | Well to really speed it up, I'd have to write the container server in go too. | 21:25 |
| notmyname | heh | 21:25 |
| clayg | BOOM! | 21:25 |
| notmyname | you haven't already?! | 21:25 |
| clayg | notmyname: you're on fire today? | 21:25 |
| *** asettle has quit IRC | 21:27 | |
| redbo | I mean, I have some prototypes.. trying out leveldb and rocksdb and some others. But I haven't worked on them in a while. | 21:27 |
| notmyname | redbo: I hear mongodb might be a good idea in hummingbird | 21:28 |
| *** lakshmiS_ has quit IRC | 21:28 | |
| redbo | If you put everything in mongo, you don't need all these other servers. | 21:29 |
| redbo | Then you only have one problem. Unfortunately it's mongo. | 21:30 |
| notmyname | lol | 21:30 |
| *** pauloewerton has quit IRC | 21:33 | |
| *** nadeem has quit IRC | 21:35 | |
| *** _JZ_ has joined #openstack-swift | 21:39 | |
| *** gyee has joined #openstack-swift | 21:43 | |
| *** wer has joined #openstack-swift | 21:45 | |
| clayg | redbo: boltdb maybe? https://github.com/boltdb/bolt | 21:47 |
| clayg | redbo: honestly it's not super clear to me how a generic k/v db replaces a container db - i mean I get that at some level everything is k/v (it's all block address down there somewhere) - but it seems like you'd have to write a bunch of stuff sqlite already gets right to really have the indexes on name work the way we want? | 21:48 |
| *** wasmum has quit IRC | 21:48 | |
| redbo | clayg: Yeah it would be more complex, you'd need to add indexes as separate keys and stuff, which sucks and is why I have a bunch of half-finished prototypes sitting around. The only appeal is if it ends up way faster. | 21:52 |
| clayg | redbo: faster on insert I guess is your primary metric? I feel like indexes gunna be indexes - if you want to keep 'em lean and mean we just gotta shard :\ | 21:54 |
| redbo | I wonder if sqlite4 is dead. They were basing it on an LSM tree k/v backend similar to those newere databases. | 21:57 |
| clayg | whoa | 21:57 |
| notmyname | zigo: I really enjoy reading your emails | 22:30 |
| zigo | notmyname: About the global-reqs ? | 22:30 |
| notmyname | all of them :-) | 22:31 |
| notmyname | but yeah | 22:31 |
| notmyname | zigo: and I think most of them are summarized with "look, packaging is hard, nobody is working on it, please stop making my job harder" | 22:31 |
| zigo | :) | 22:31 |
| notmyname | and bringing some degree of ops sanity/perspective to how software is actually consumed | 22:31 |
| notmyname | zigo: like you, I'm very interested and curious about the outcome of these global reqs discussions | 22:32 |
| zigo | notmyname: Well, I agreed to attempt giving less work on the global-reqs management. | 22:32 |
| zigo | I do believe a lot of it can be just not done. | 22:33 |
| notmyname | I don't have a particularly strong opinion one way or the other. except that ops people who deploy swift tell me that they don't want to keep redoing all their packaging every time some other openstack project decides they need to upgrade some dependency | 22:33 |
| notmyname | so as long as people who deploy swift are happy, I really don't care what the outcome is :-) | 22:34 |
| zigo | Yup, that too ! | 22:34 |
| notmyname | (ie it's really easy for me to +2 or -2 a global requirements patch. really! takes about 3 seconds!) | 22:34 |
| zigo | If we could test the lower bounds of dependencies for each and every project, we wouldn't have any issue, it'd be fully tested and automated. | 22:34 |
| notmyname | yes! I like that idea | 22:35 |
| notmyname | from time to time I run my swift all in one with all the minimum versions allowed in our dependencies | 22:35 |
| notmyname | and sometimes I find stuff we need to bump up | 22:35 |
| zigo | Oh, really? Thanks, that's really helpful. | 22:35 |
| clarkb | notmyname: zigo please remember anyone including you can write that test and have it run against openstack, either on every patchset or periodically or after merges or whatever makes sense | 22:36 |
| notmyname | FWIW I'm not doing that currently, so I couldn't tell you what the current state is. I think I ended up upgrading everything a few months ago | 22:36 |
| clarkb | it doesn't have to be a special "oh I do this for swift locally to catch bugs" | 22:37 |
| notmyname | clarkb: right! I think the reason I haven't is lack of knowledge (or comfort) with how to modify devstack dependencies to be something different to run tests. my understanding is that devstack just slams in global requirements regardless of anything else | 22:38 |
| clarkb | especially now that pip honors constraints (it was hard to actually enforce the lower bounds previously) | 22:38 |
| clarkb | notmyname: sort of, it uses pip's upper constraints today. But you could add in lower constraints and everything else would be the same | 22:38 |
| notmyname | zigo: separate question: how are projects supposed to identify dependencies that aren't in requirements.txt? (ie stuff that can't be installed from pypi)? | 22:39 |
| clarkb | its just a matter of generating the constraints file with the correct contraints and feeding that into devstack/pip | 22:39 |
| clarkb | notmyname: bindep | 22:39 |
| clarkb | notmyname: you can have an other-requirements.txt file that uses bindeps specification format to specify system deps | 22:39 |
| * clarkb looks for an example | 22:40 | |
| notmyname | whew | 22:40 |
| zigo | notmyname: I'm not sure I understand your question ... | 22:41 |
| zigo | notmyname: Will it work if something is missing? | 22:42 |
| zigo | Most likely, it will just break hard, no? | 22:42 |
| clarkb | notmyname: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/data/bindep-fallback.txt this is the fallback list we use if projects do not have an other-requirements.txt file | 22:42 |
| clarkb | notmyname: it is fairly comprehensive of all the various things various projects need, but if you add one to say swift you can make it the minimal set that only swift needs | 22:42 |
| notmyname | clarkb: meta comment, thanks for jumping in recently to conversations with "hey instead of doing your own thing, why don't you help the community...here's how". personally, I don't know how most of the -infra stuff works or what's available to me. so these things help :-) | 22:43 |
| notmyname | clarkb: so if we have a root-level "other-requirements.txt" then that's what will get picked up instead of this one? | 22:43 |
| clarkb | notmyname: ok :) I find that generally things get better when we do them upstream like this. Because then not only swift can have tests that do that but the other projects as well | 22:44 |
| clarkb | notmyname: correct | 22:44 |
| zigo | clarkb: Clearly, what I can do to help the community, is get this packaging-deb project up and running... | 22:44 |
| clarkb | notmyname: I don't think devstack is using it yet but for all of the non devstack stuff we rely on either the in project list or the fallback list | 22:44 |
| zigo | clarkb: Though, as you know, it's currently stuck with this sbuild issue... :( | 22:44 |
| clarkb | zigo: yes and I tried to help you earlier today but you ignored my advice | 22:44 |
| clarkb | zigo: so I am not sure what else I can do | 22:45 |
| zigo | clarkb: What advice was that? | 22:45 |
| zigo | To use bash --login ? | 22:45 |
| notmyname | clarkb: and then the installed dependencies are the union of other-requirments.txt and requirements.txt and test-requirments.txt? (with versions specified for each listed dependency as defined by upper-constraints?) | 22:45 |
| zigo | I tried... | 22:45 |
| clarkb | zigo: to try su and to make sure the group is being installed properly | 22:45 |
| zigo | clarkb: *IT IS* installed properly in /etc/group, I checked ... | 22:45 |
| clarkb | notmyname: yes, other-requirements ets intsalled out of the system package manager (you will see platform:dpkg and similar in the fallback file), and the requirements.txt and test-requirements.txt via pi | 22:46 |
| zigo | (not in infra, but I know the script, and ran it on an image...) | 22:46 |
| clarkb | *via pip | 22:46 |
| notmyname | clarkb: this is great info | 22:46 |
| m3m0 | hey guys is there a way to get notified when an object gets uploaded to swift? | 22:48 |
| clayg | timur: ^ cc :D | 22:49 |
| clarkb | notmyname: the goal is that each project can have better control over that stuff both for documentation purposes and for easier management of test deps | 22:50 |
| notmyname | m3m0: short answer is "not yet" | 22:50 |
| notmyname | m3m0: longer answer is that there are some good ideas out there, it's an area of active discussion (including a topic for next week's summit) | 22:51 |
| *** StraubTW has quit IRC | 22:51 | |
| notmyname | m3m0: but it's definitely possible, if you include "write code" in your scope of what's possible | 22:53 |
| mattoliverau | morning y'all | 22:53 |
| notmyname | hey mattoliverau! | 22:53 |
| mattoliverau | notmyname: hey! | 22:53 |
| timburke | good morning mattoliverau! | 22:53 |
| notmyname | mattoliverau: are you getting any sleep? | 22:53 |
| mattoliverau | notmyname: pfft sleep, its overrated (says someone not getting any) | 22:53 |
| notmyname | heh | 22:54 |
| notmyname | it will get better :-) | 22:54 |
| mattoliverau | for the first time in my life I'm looking forward to the long flight to the US :P | 22:54 |
| notmyname | lol | 22:54 |
| mattoliverau | timburke: hey man, and congrats on core-ifying some more. | 22:54 |
| mattoliverau | notmyname: new borns are hard, they're so cute during the day.. and turn into gremlims at night. | 22:55 |
| timburke | mattoliverau: i have so much more to do and worry about now :-( | 22:56 |
| timburke | i'm sure you can relate ;-) | 22:56 |
| zigo | m3m0: You can pay an employee to look at the logs? :) | 22:56 |
| mattoliverau | timburke: lol, yup | 22:56 |
| mattoliverau | timburke: no pressure :P | 22:56 |
| * zigo hides after this bad joke | 22:56 | |
| clarkb | mattoliverau: now imagine having two at the same time :) | 22:57 |
| notmyname | clarkb: twins? | 22:57 |
| clarkb | notmyname: ya I have 10 month old twins | 22:57 |
| *** wasmum has joined #openstack-swift | 22:57 | |
| mattoliverau | clarkb: that is just rediculous.. I think parents who go back are extra times are crazy :P (but apparently you forget about that in the future). | 22:58 |
| notmyname | I gotta admit, I don't envy you (or clayg) ;-) | 22:58 |
| mattoliverau | clarkb: wow, you poor poor man, I'll never complain (around you) again :P | 22:58 |
| *** km__ has joined #openstack-swift | 23:00 | |
| *** km__ is now known as Guest47358 | 23:01 | |
| pdardeau | hey mattoliverau! welcome back | 23:06 |
| mattoliverau | pdardeau: hey man! thanks | 23:07 |
| *** rickyrem has left #openstack-swift | 23:08 | |
| mattoliverau | So it turns out the world doesn't stop when your away, people keep on emailing. | 23:08 |
| notmyname | mattoliverau: mark all as read. if it's important, then you'll probably get fired for not responding. good luck | 23:10 |
| mattoliverau | notmyname: lol, great, job done :P | 23:11 |
| *** asettle has joined #openstack-swift | 23:13 | |
| mattoliverau | notmyname: it's what most my yesterday was. that and rebasing sharding code and now trying to debug it post fastpost world (which involved alot of rewording). | 23:13 |
| *** MrsWr0ng has joined #openstack-swift | 23:16 | |
| MrsWr0ng | hi | 23:16 |
| notmyname | hello MrsWr0ng | 23:20 |
| MrsWr0ng | hi are you bot | 23:20 |
| gmmaha | howdy mattoliverau .. welcome back!! | 23:22 |
| mattoliverau | gmmaha: hey! | 23:23 |
| *** kei_yama has joined #openstack-swift | 23:35 | |
| *** MrsWr0ng has quit IRC | 23:36 | |
| *** klamath has quit IRC | 23:38 | |
| openstackgerrit | Merged openstack/swift: Encrypt/decrypt etag in container listing https://review.openstack.org/275492 | 23:55 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
