*** openstackgerrit has quit IRC | 08:48 | |
*** openstackgerrit has joined #swift3 | 08:49 | |
*** Socket_0x03 has joined #swift3 | 09:31 | |
*** Socket_0x03 has joined #swift3 | 09:31 | |
*** Socket_0x03 has quit IRC | 09:35 | |
*** CrustY__ has joined #swift3 | 10:08 | |
*** CrustY__ is now known as CrustY_ | 10:13 | |
*** CrustY_ is now known as CrustY__ | 10:13 | |
*** CrustY__ is now known as CrustY___ | 10:13 | |
*** CrustY___ is now known as CrustY_ | 10:13 | |
*** CrustY_ is now known as _CrustY | 10:15 | |
*** _CrustY has quit IRC | 10:15 | |
*** _CrustY has joined #swift3 | 10:15 | |
*** _CrustY has quit IRC | 10:19 | |
*** _CrustY has joined #swift3 | 10:19 | |
*** _CrustY has quit IRC | 10:20 | |
*** _CrustY has joined #swift3 | 10:21 | |
*** i6x86 has joined #swift3 | 14:17 | |
*** acoles_ is now known as acoles | 16:21 | |
*** i6x86 has quit IRC | 16:48 | |
*** acoles is now known as acoles_ | 18:49 | |
*** i6x86 has joined #swift3 | 19:27 | |
*** cschwede has quit IRC | 20:57 | |
*** i6x86 has quit IRC | 21:07 | |
*** cschwede has joined #swift3 | 21:28 | |
openstackgerrit | Merged openstack/swift3: Fix error message https://review.openstack.org/368222 | 21:50 |
---|---|---|
kota_ | hello | 23:01 |
timburke | hi kota_! | 23:02 |
kota_ | hi timburke! | 23:03 |
kota_ | timburke: do you know if Simon will be? | 23:04 |
timburke | not sure. and not sure about bill_az either | 23:05 |
kota_ | k, let's start here, and will explain if they will be comming | 23:05 |
kota_ | wiki was updated, https://wiki.openstack.org/wiki/Meetings/swift3 | 23:06 |
kota_ | so on the first item | 23:07 |
kota_ | thanks for attending f2f meeting at barcelona | 23:08 |
kota_ | do you have any thought on that? | 23:08 |
timburke | not in particular; seems like we made a good bit of progress in the last cycle -- here's hoping for similar progress in Ocata! | 23:09 |
kota_ | timuburke: yeah and thanks for bringing up for a few of pending patches to me in the swift design session. | 23:11 |
kota_ | timburke: that conversation helps me to keep attention to swift3 | 23:12 |
timburke | yeah! and thanks for having another look at https://review.openstack.org/#/c/384659/ | 23:13 |
timburke | (v3 keystone patch) | 23:13 |
kota_ | yeah, sorry it's intermediate to the complete review to me. | 23:13 |
kota_ | i wanna do that but you know, I has been tied up to the ec thing :/ | 23:14 |
timburke | auth_version as a separate param isn't a bad idea. with all the deprecation stuff going on in auth_token, i didn't even notice that auth_version *isn't* deprecated | 23:14 |
timburke | yeah, i think everyone's a little distracted because of that | 23:15 |
kota_ | kk | 23:17 |
kota_ | timburke: quick confirmation | 23:17 |
kota_ | timburke: always keystone will make the path for s3token validation is ends with '/<version>/s3token'? | 23:18 |
kota_ | timburke: i mean, nothing inserted between version and s3token | 23:18 |
timburke | i'm not entirely sure. i think that gets defined at https://github.com/openstack/keystone/blob/10.0.0/keystone/contrib/s3/core.py#L43 ? | 23:20 |
timburke | no, wait, here: https://github.com/openstack/keystone/blob/10.0.0/keystone/contrib/s3/core.py#L63 | 23:21 |
timburke | so...hopefully they never change that on us? | 23:21 |
kota_ | it looks true | 23:21 |
kota_ | thanks. so that we can use the concat string with version and s3token | 23:22 |
timburke | that's part of why i want to move toward providing a complete path to the endpoint; then operators have the freedom to fix it. it's just the backwards compatibility that's a problem :-/ | 23:22 |
kota_ | indeed | 23:23 |
timburke | maybe it'd be better if i didn't have the elif block, and only tried to detect that we needed to add '/v2.0/s3tokens' | 23:24 |
kota_ | freedom operators sometimes makes devs hard to work for validations | 23:24 |
timburke | and if you want v3, you *have* to specify the whole path | 23:24 |
kota_ | sounds simple! | 23:25 |
timburke | the reason i hesitated originally was that the s3tokens endpoint isn't very easily discoverable -- you kinda have to already know it exists | 23:26 |
kota_ | true | 23:26 |
kota_ | ah, sorry | 23:32 |
kota_ | to make you waiting | 23:32 |
kota_ | timburke:^^ | 23:32 |
kota_ | so back to barcelona recap, i think it worked well and i think we can expect to progress in Ocata cycle to | 23:33 |
timburke | no worries :-) we've got liberasurecode release to worry about :-) | 23:33 |
kota_ | and go to the next topic. | 23:33 |
kota_ | timburke: yeah, need to BOTH of liberasurecode and swift3 | 23:34 |
kota_ | for us | 23:34 |
kota_ | important, i mean | 23:34 |
kota_ | k, | 23:34 |
kota_ | so from the conversation in barcelona, I'd like to hear which swift version we can bump for your distro. | 23:35 |
timburke | i think we'd be OK going to any version you like. we'll still have customers on old versions of swift, but i think i'll be comfortable telling them that if they want the latest and greatest swift3, they'll have to upgrade | 23:36 |
timburke | there'll be a bit of packaging pain for me, but that's going to happen no matter what version we choose | 23:36 |
kota_ | thanks | 23:37 |
kota_ | considering my company, it's ok for any version too. | 23:37 |
kota_ | and for my opinion, i like to use the newton if nothing problem to IBM | 23:38 |
kota_ | will ask via E-mail. | 23:38 |
timburke | sounds good | 23:39 |
kota_ | k, next | 23:40 |
kota_ | anything else for today? | 23:40 |
timburke | i already mentioned my concurrent HEAD patch for SLO -- i'm hoping that we can then actually support 10k parts for multipart uploads (with an appropriate proxy-server.conf) | 23:41 |
kota_ | yeah | 23:42 |
timburke | basically, set max_segments to 10000 and the slo concurrency factor to at least 10 | 23:42 |
kota_ | it's still in my priority scope with a gerrit star | 23:42 |
kota_ | ah, | 23:43 |
timburke | public cloud might not want to do that, but private could without having clients timing out all the time | 23:43 |
kota_ | sorry confused with SLO etag update in the swift container. | 23:43 |
timburke | ah, yeah! that's another fun one. trying to reconcile the swift vs S3 etags is proving...hairy | 23:44 |
kota_ | ok | 23:44 |
timburke | concurrent head is https://review.openstack.org/#/c/391682/ | 23:44 |
kota_ | thanks | 23:46 |
kota_ | add me to the reviews and make it my star. | 23:46 |
timburke | and i think storing etag in sysmeta in https://review.openstack.org/#/c/347538/ *might* be enough that i could move forward on https://review.openstack.org/#/c/302475/ -- the last few paragraphs in the commit message are still aspirational, unfortunately | 23:47 |
kota_ | exactly a tons of sequential HEAD may be problem. | 23:47 |
timburke | (at least, i think that's still not implemented. maybe i was thinking of some work-in-progress i had to actually match the S3-style etags?) | 23:48 |
kota_ | yeah | 23:48 |
kota_ | so cool | 23:49 |
kota_ | those all looks great. just i need to float up to api/application side from the deep sea of ec lower level c implementation to judge the review. | 23:50 |
timburke | another thing that might be good to land would be https://review.openstack.org/#/c/304367/ -- the i'd start looking at getting it into the gate jobs | 23:50 |
kota_ | on my head cleaning | 23:50 |
kota_ | ceph-s3? | 23:51 |
kota_ | ya, that one | 23:51 |
timburke | hehe i often feel like i need a good head cleaning | 23:51 |
timburke | yeah, the ceph tests. the nice thing is, it can't really break much. the main question is how invasive it is in run_test.sh (so thanks for the feedback!) | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!