| *** dmorita has joined #openstack-swift | 00:26 | |
| *** matsuhashi has joined #openstack-swift | 00:31 | |
| *** kota_ has joined #openstack-swift | 00:58 | |
| *** mitz has quit IRC | 01:11 | |
| *** mitz has joined #openstack-swift | 01:25 | |
| *** mitz has quit IRC | 01:28 | |
| *** mitz has joined #openstack-swift | 01:28 | |
| *** nosnos has joined #openstack-swift | 01:39 | |
| *** mitz has quit IRC | 01:57 | |
| *** mitz has joined #openstack-swift | 02:01 | |
| *** AbyssOne__ has joined #openstack-swift | 02:16 | |
| *** AbyssOne_ has quit IRC | 02:17 | |
| *** bvandenh has quit IRC | 02:18 | |
| *** annegentle_ has quit IRC | 02:25 | |
| *** annegentle has joined #openstack-swift | 02:35 | |
| *** yuan has quit IRC | 02:36 | |
| *** yuan has joined #openstack-swift | 02:37 | |
| *** mlipchuk has quit IRC | 02:37 | |
| *** charz has joined #openstack-swift | 02:41 | |
| *** bkopilov has quit IRC | 02:42 | |
| *** mitz has quit IRC | 02:48 | |
| *** mitz has joined #openstack-swift | 02:50 | |
| *** mitz has quit IRC | 02:52 | |
| *** mitz has joined #openstack-swift | 02:54 | |
| *** zhiyan_ is now known as zhiyan | 03:04 | |
| *** dmorita has quit IRC | 03:16 | |
| notmyname | hello, world. | 03:19 |
|---|---|---|
| notmyname | zaitcev isn't here, but it looks like the upstream links are all there now | 03:20 |
| notmyname | I'll be doing launchpad busywork to make it look vaguely similar to reality this week | 03:21 |
| notmyname | peluse_: I may not be able to make the pyeclib meeting in the morning. I've got a ptl webinar to give tomorrow afternoon and have to prep for. depends on how timing goes with dropping kids off in the morning | 03:26 |
| *** matsuhashi has quit IRC | 03:39 | |
| *** mlipchuk has joined #openstack-swift | 03:41 | |
| *** mlipchuk has quit IRC | 03:51 | |
| *** nosnos has quit IRC | 03:54 | |
| notmyname | 2.0 RC announce email http://lists.openstack.org/pipermail/openstack-dev/2014-June/038357.html | 03:57 |
| *** fifieldt has joined #openstack-swift | 04:00 | |
| kota_ | notmyname: great! I'm happy to hear the news :) | 04:08 |
| *** charz has quit IRC | 04:08 | |
| *** bkopilov has joined #openstack-swift | 04:13 | |
| *** bkopilov_ has joined #openstack-swift | 04:19 | |
| goodes | good morning all | 04:36 |
| *** haomaiwang has joined #openstack-swift | 04:36 | |
| notmyname | peluse_: ah. my PTL update is on tuesday. got my invites out of order. chances looking better to be at pyeclib tomorrow am ;-) | 04:38 |
| notmyname | goodes: hi | 04:38 |
| *** matsuhashi has joined #openstack-swift | 04:39 | |
| *** nosnos has joined #openstack-swift | 04:41 | |
| goodes | notmyname: hi | 04:44 |
| notmyname | and goodnight to you :-) | 04:44 |
| notmyname | I've got to turn in early tonight. my wife is traveling and I've got to get up early with the kids tomorrow. and I'll need my sleep | 04:45 |
| notmyname | I'll probably be online again in about 12 hours (after I drop off kids) | 04:45 |
| kota_ | peluse: Hi, peluse. Can I get the log of the pyeclib meeting or join it? | 04:45 |
| notmyname | kota_: I'll forward you the invite | 04:46 |
| *** kopparam has joined #openstack-swift | 04:46 | |
| *** nosnos has quit IRC | 04:46 | |
| kota_ | notmyname: Thanks! | 04:46 |
| notmyname | kota_: done | 04:47 |
| *** nosnos has joined #openstack-swift | 04:47 | |
| kota_ | notmyname: got it | 04:47 |
| *** ChanServ changes topic to "Currently in Swift 2.0 RC phase -- read all about it at http://lists.openstack.org/pipermail/openstack-dev/2014-June/038357.html" | 04:48 | |
| notmyname | ok, good night all | 04:48 |
| *** nshaikh has joined #openstack-swift | 04:52 | |
| StevenK | notmyname: When you're back, congrats on 2.0 rc1 | 04:58 |
| goodes | notmyname: there seems to be a issue with the link you have to overview_policies - the trailing dot is included which renders a 404. | 05:08 |
| goodes | Congrats all on 2.0RC1 | 05:08 |
| *** fifieldt has quit IRC | 05:12 | |
| *** navid__ has joined #openstack-swift | 05:12 | |
| *** chandan_kumar_ has joined #openstack-swift | 05:13 | |
| *** jyoti_ranjan has joined #openstack-swift | 05:13 | |
| *** fifieldt has joined #openstack-swift | 05:14 | |
| *** chandan_kumar has quit IRC | 05:16 | |
| *** nshaikh has quit IRC | 05:16 | |
| *** chandan_kumar_ is now known as chandan_kumar | 05:17 | |
| *** ppai has joined #openstack-swift | 05:20 | |
| *** navid__ has quit IRC | 05:29 | |
| *** ajc_ has joined #openstack-swift | 05:29 | |
| *** kopparam has quit IRC | 05:32 | |
| mattoliverau | Wow, there is action in the channel!! I go away for... ahem.. a long lunch break (but means I now have a car) and.. boom everyones awake :) Welcome to Monday people!! | 05:33 |
| *** nosnos has quit IRC | 05:35 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 05:35 |
| *** nosnos has joined #openstack-swift | 05:37 | |
| *** psharma has joined #openstack-swift | 05:38 | |
| *** kajinamit has joined #openstack-swift | 05:39 | |
| * portante folks are just sleep walking ... ;) | 05:41 | |
| mattoliverau | portante: lol, probably :P | 05:45 |
| *** nshaikh has joined #openstack-swift | 05:48 | |
| *** matsuhashi has quit IRC | 06:05 | |
| *** matsuhashi has joined #openstack-swift | 06:06 | |
| *** kopparam has joined #openstack-swift | 06:07 | |
| *** matsuhashi has quit IRC | 06:11 | |
| *** grapsus_ has joined #openstack-swift | 06:11 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:12 | |
| *** kota_ has quit IRC | 06:13 | |
| *** matsuhashi has joined #openstack-swift | 06:13 | |
| *** kopparam has quit IRC | 06:15 | |
| *** kopparam has joined #openstack-swift | 06:15 | |
| openstackgerrit | Kota Tsuyuzaki proposed a change to openstack/swift: Efficient Replication for Distributed Regions https://review.openstack.org/99824 | 06:16 |
| *** kopparam_ has joined #openstack-swift | 06:19 | |
| *** matsuhashi has quit IRC | 06:19 | |
| *** matsuhashi has joined #openstack-swift | 06:19 | |
| *** kopparam has quit IRC | 06:20 | |
| *** kota_ has joined #openstack-swift | 06:20 | |
| *** ktsuyuzaki has quit IRC | 06:22 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:23 | |
| *** MooingLemur has quit IRC | 06:23 | |
| *** MooingLemur has joined #openstack-swift | 06:23 | |
| *** kota_ has quit IRC | 06:25 | |
| *** kopparam_ has quit IRC | 06:26 | |
| *** pconstantine_ has joined #openstack-swift | 06:26 | |
| *** kopparam has joined #openstack-swift | 06:26 | |
| *** openstackstatus has quit IRC | 06:27 | |
| *** acorwin has quit IRC | 06:27 | |
| *** kota_ has joined #openstack-swift | 06:29 | |
| *** acorwin has joined #openstack-swift | 06:30 | |
| *** ktsuyuzaki has quit IRC | 06:31 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:34 | |
| *** jamiehannaford has joined #openstack-swift | 06:34 | |
| *** kota_ has quit IRC | 06:36 | |
| *** kota_ has joined #openstack-swift | 06:41 | |
| *** ktsuyuzaki has quit IRC | 06:43 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:43 | |
| *** haomaiwang has quit IRC | 06:45 | |
| *** kota_ has quit IRC | 06:45 | |
| *** kota_ has joined #openstack-swift | 06:46 | |
| *** mkollaro has joined #openstack-swift | 06:47 | |
| *** ktsuyuzaki has quit IRC | 06:48 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:48 | |
| *** ktsuyuza_ has joined #openstack-swift | 06:51 | |
| *** kota_ has quit IRC | 06:51 | |
| *** kota_ has joined #openstack-swift | 06:53 | |
| *** ktsuyuzaki has quit IRC | 06:53 | |
| *** matsuhashi has quit IRC | 06:55 | |
| *** ktsuyuza_ has quit IRC | 06:55 | |
| *** matsuhashi has joined #openstack-swift | 06:56 | |
| *** ktsuyuzaki has joined #openstack-swift | 06:56 | |
| *** kota_ has quit IRC | 06:58 | |
| *** kota_ has joined #openstack-swift | 06:58 | |
| *** ktsuyuzaki has quit IRC | 07:01 | |
| *** ktsuyuzaki has joined #openstack-swift | 07:01 | |
| *** kota_ has quit IRC | 07:03 | |
| *** kota_ has joined #openstack-swift | 07:03 | |
| *** bkopilov has quit IRC | 07:04 | |
| *** bkopilov_ has quit IRC | 07:05 | |
| *** ktsuyuzaki has quit IRC | 07:05 | |
| *** pconstantine_ has quit IRC | 07:06 | |
| ppai | Does anyone know what role reseller_prefix has in account name ? | 07:07 |
| *** kopparam has quit IRC | 07:10 | |
| *** ktsuyuzaki has joined #openstack-swift | 07:10 | |
| *** kota_ has quit IRC | 07:12 | |
| *** jamiehannaford has quit IRC | 07:12 | |
| *** jamiehannaford has joined #openstack-swift | 07:12 | |
| *** kota_ has joined #openstack-swift | 07:14 | |
| *** ktsuyuzaki has quit IRC | 07:16 | |
| *** bkopilov_ has joined #openstack-swift | 07:20 | |
| *** bkopilov has joined #openstack-swift | 07:20 | |
| *** jamiehannaford has quit IRC | 07:22 | |
| *** jamiehannaford has joined #openstack-swift | 07:25 | |
| *** joeljwright has joined #openstack-swift | 07:25 | |
| *** sileht has quit IRC | 07:35 | |
| *** pconstantine_ has joined #openstack-swift | 07:35 | |
| *** pconstantine_ has quit IRC | 07:46 | |
| mattoliverau | Hi ppai, the authentication middleware I think appends the reseller_prefix to the account name so it knows which authenticator was and is used to authnticate it. The token is also appended with it. The default prefix is AUTH. | 07:52 |
| *** nacim has joined #openstack-swift | 07:52 | |
| *** kopparam has joined #openstack-swift | 07:53 | |
| mattoliverau | or what authenitcator an account is apart of. | 07:54 |
| ppai | <mattoliverau> I understand...the entry in account DBs also has this prefix | 07:54 |
| ppai | So I guess, if i change my reseller_prefix, then I can't access those accounts that were PUT earlier using a different reseller_prefix | 07:55 |
| mattoliverau | ppai: its possible with swift to use multiple authentication middle ware, so that makes sense to store it in the dbs. | 07:56 |
| mattoliverau | ppai: hmm, yeah good question. I'll do some digging :) | 07:56 |
| ppai | the only doc I could find about the purpose of reseller_prefix is this: http://manpages.ubuntu.com/manpages/raring/man5/proxy-server.conf.5.html | 07:57 |
| *** ahale has joined #openstack-swift | 08:01 | |
| *** ahale has quit IRC | 08:01 | |
| *** ahale has joined #openstack-swift | 08:01 | |
| *** ppai has quit IRC | 08:02 | |
| *** foexle has joined #openstack-swift | 08:07 | |
| *** ppai has joined #openstack-swift | 08:08 | |
| *** kopparam has quit IRC | 08:14 | |
| *** mmcardle has joined #openstack-swift | 08:14 | |
| *** kopparam_ has joined #openstack-swift | 08:19 | |
| *** kopparam_ has quit IRC | 08:20 | |
| *** kopparam has joined #openstack-swift | 08:23 | |
| *** jyoti_ranjan has quit IRC | 08:24 | |
| *** jyoti_ranjan has joined #openstack-swift | 08:25 | |
| *** rieglflo has joined #openstack-swift | 08:29 | |
| *** sileht has joined #openstack-swift | 08:41 | |
| mattoliverau | ppai: hmm, I'm a little stuck, it looks like there used to be a tool that updated the reseller-prefix: http://is.gd/4Woz2M But this is old and doens't seem to exist anymore. You will have to ask your question during US day time when there are more devs online. Maybe its built into swift somewhere new, maybe they assume to migrate away you need to use mixed | 08:44 |
| mattoliverau | reseller_prefixes (ie load the middleware twice with different prefixs) and move everything. I'm stumped, I'm new to the project so isn't something I've faced. So please don't take the previous suggestions (load middleware twice, etc) and play in production.. instead I think the question needs to be raised to a core. But now I want to know, so I'll definitely be asking the other devs when they're | 08:44 |
| mattoliverau | online (tomorrow morning for me). If you can't be around during the US day time, hopefully I can answer you question tomorrow :) | 08:44 |
| mattoliverau | On that note, it's getting later into the evening here and I need dinner. | 08:44 |
| mattoliverau | Night all. | 08:44 |
| mattoliverau | ppai: sorry I couldn't help further | 08:45 |
| rieglflo | hi everyone, is it possible to create a container as admin and give exactly one (non admin nor swiftoperator ) user within that tenant read, write, listing permissions for that container? the user shall not be able to make the objects within that container public accessable but shall be able to list it's objects as well as add/remove objects. .rlistings seems to make the container public readable .... | 08:46 |
| rieglflo | please advise | 08:46 |
| *** nshaikh has quit IRC | 08:47 | |
| *** charz has joined #openstack-swift | 08:58 | |
| *** ujjain has quit IRC | 09:01 | |
| ppai | mattoliverau, thanks :) | 09:06 |
| *** mkerrin has quit IRC | 09:15 | |
| *** jyoti_ranjan has quit IRC | 09:16 | |
| *** mkerrin has joined #openstack-swift | 09:18 | |
| *** pberis has quit IRC | 09:19 | |
| *** jyoti_ranjan has joined #openstack-swift | 09:20 | |
| *** pberis has joined #openstack-swift | 09:21 | |
| *** kopparam has quit IRC | 09:23 | |
| *** kopparam_ has joined #openstack-swift | 09:23 | |
| *** kopparam_ has quit IRC | 09:26 | |
| acoles | riegflo: assuming you are using keystone, use X-Container-[Read|Write] ACL *:user_id where user_id is the keystone id of the user you want to grant container access to | 09:26 |
| *** kopparam has joined #openstack-swift | 09:28 | |
| *** haomaiwa_ has joined #openstack-swift | 09:34 | |
| *** kopparam has quit IRC | 09:36 | |
| *** RockKuo_Office has joined #openstack-swift | 09:37 | |
| *** RockKuo_Office has joined #openstack-swift | 09:37 | |
| *** RockKuo_ has joined #openstack-swift | 09:37 | |
| *** RockKuo_Office has quit IRC | 09:37 | |
| *** RockKuo_ has quit IRC | 09:37 | |
| *** RockKuo_Office has joined #openstack-swift | 09:38 | |
| *** haomaiwa_ has quit IRC | 09:39 | |
| *** toolslive has joined #openstack-swift | 09:40 | |
| *** kota_ has quit IRC | 09:43 | |
| *** jyoti_ranjan has quit IRC | 09:47 | |
| *** kopparam has joined #openstack-swift | 09:50 | |
| *** nsquare has quit IRC | 10:07 | |
| *** nsquare has joined #openstack-swift | 10:09 | |
| *** nsquare has quit IRC | 10:09 | |
| *** mlipchuk has joined #openstack-swift | 10:11 | |
| *** bkopilov has quit IRC | 10:15 | |
| *** bkopilov_ has quit IRC | 10:16 | |
| *** mmcardle has quit IRC | 10:20 | |
| *** mlipchuk has quit IRC | 10:22 | |
| *** haomaiwa_ has joined #openstack-swift | 10:23 | |
| *** haomaiwa_ has quit IRC | 10:28 | |
| *** AbyssOne is now known as a1|away | 10:28 | |
| *** jyoti_ranjan has joined #openstack-swift | 10:31 | |
| *** zhiyan is now known as zhiyan_ | 10:32 | |
| *** haomaiwang has joined #openstack-swift | 10:34 | |
| *** haomaiw__ has joined #openstack-swift | 10:47 | |
| *** haomaiwang has quit IRC | 10:49 | |
| *** bkopilov has joined #openstack-swift | 10:54 | |
| *** bkopilov_ has joined #openstack-swift | 10:54 | |
| *** bkopilov_ has quit IRC | 11:00 | |
| rieglflo | acoles: thank you, but is that somewhere documented? http://docs.openstack.org/developer/swift/misc.html#acls ....? | 11:01 |
| *** bkopilov has quit IRC | 11:03 | |
| *** tdasilva has joined #openstack-swift | 11:04 | |
| *** ppai has quit IRC | 11:07 | |
| *** bkopilov has joined #openstack-swift | 11:13 | |
| *** jyoti_ranjan has quit IRC | 11:14 | |
| acoles | rieglflo: its a variant of the example 'sues_account:sue'. sues_account can be replaced with wildcard *. but i agree its not too clear. | 11:18 |
| acoles | rieglflo: and i recommend that you use keystone user ID not name - user names are not guaranteed to remain globally unique in keystone (they are unique within domains), id's will always be globally unique. | 11:19 |
| *** bkopilov has quit IRC | 11:19 | |
| *** dmsimard_away is now known as dmsimard | 11:19 | |
| rieglflo | acoles: thank you very much for that clarification! | 11:21 |
| acoles | rieglflo: no problem | 11:21 |
| *** charz has quit IRC | 11:21 | |
| *** ppai has joined #openstack-swift | 11:24 | |
| *** chandan_kumar is now known as chkumar246 | 11:35 | |
| *** RockKuo_Office has quit IRC | 11:38 | |
| *** chkumar246 has quit IRC | 11:45 | |
| *** chandan_kumar has joined #openstack-swift | 11:46 | |
| *** jyoti_ranjan has joined #openstack-swift | 11:48 | |
| *** a1|away is now known as AbyssOne | 11:52 | |
| *** mmcardle has joined #openstack-swift | 11:55 | |
| *** Ju_ has joined #openstack-swift | 11:55 | |
| *** kopparam has quit IRC | 12:03 | |
| *** mmcardle has quit IRC | 12:06 | |
| dmsimard | notmyname, chmouel: Debating wether or not to open a bug for this.. python-swiftclient doesn't seem to support TLS SNI but it's not exactly it's fault, it's more because the underlying libraries do not. What do you guys think ? | 12:06 |
| dmsimard | A bug would at least allow to track the progress towards SNI support ? | 12:06 |
| pconstantine | fresh saio: TypeError: list_objects_iter() got an unexpected keyword argument 'storage_policy_index' | 12:07 |
| *** kopparam has joined #openstack-swift | 12:11 | |
| *** CaioBrentano has joined #openstack-swift | 12:16 | |
| *** jamiehannaford has quit IRC | 12:20 | |
| *** tdasilva_ has joined #openstack-swift | 12:20 | |
| *** tdasilva has quit IRC | 12:20 | |
| *** jamiehannaford has joined #openstack-swift | 12:21 | |
| *** jamiehannaford has quit IRC | 12:22 | |
| *** matsuhashi has quit IRC | 12:23 | |
| *** ppai has quit IRC | 12:23 | |
| *** matsuhashi has joined #openstack-swift | 12:23 | |
| *** jamiehannaford has joined #openstack-swift | 12:23 | |
| *** jamiehannaford has quit IRC | 12:23 | |
| *** jamiehannaford has joined #openstack-swift | 12:26 | |
| *** matsuhashi has quit IRC | 12:28 | |
| chmouel | dmsimard: i think it may be easier to add that to requests/urllib3 than swiftclient | 12:28 |
| *** matsuhashi has joined #openstack-swift | 12:28 | |
| dmsimard | chmouel: *nod*, like I said, it's more of a bug/missing feature in requests/urllib3 | 12:28 |
| dmsimard | But we should probably document somewhere that this means python-swiftclient doesn't support SNI | 12:28 |
| dmsimard | Took me a while to find out this particular issue in an implementation :) | 12:29 |
| chmouel | dmsimard: sorry about that, is that something that was supported with the homegrown ssl implementation that we had in pre-swiftclient-2.0 ? | 12:30 |
| dmsimard | chmouel: I haven't dug in the changelog too much but I can tell that the SSL verification mechanisms have improved in the recent versions - for instance in the Ubuntu packaged swiftclient, it won't complain about a selfsigned/wrong certificate and in the pip release it does. | 12:31 |
| dmsimard | chmouel: In the pip release, if I have two SSL vhosts on the same IP and I query the vhost that isn't returned as a default by the webserver, swiftclient will complain that the hostname I queried doesn't match the domain for the SSL certificate | 12:33 |
| dmsimard | because the SSL certificate returned is the one for the default domain | 12:33 |
| chmouel | isn't that dependent of the python version? | 12:33 |
| chmouel | i.e: python3 supports it and not py2 | 12:33 |
| dmsimard | Both running python 2.7, Ubuntu packaged version for swiftclient is 1.6.0, pip release is 2.1.0 | 12:34 |
| *** matsuhashi has quit IRC | 12:35 | |
| dmsimard | Don't have a python 3 to test on right now. | 12:35 |
| *** matsuhashi has joined #openstack-swift | 12:35 | |
| *** ppai has joined #openstack-swift | 12:36 | |
| *** matsuhas_ has joined #openstack-swift | 12:38 | |
| chmouel | dmsimard: this is mentioning in the requests FAQ http://docs.python-requests.org/en/latest/community/faq/#what-are-hostname-doesn-t-match-errors | 12:38 |
| *** matsuhashi has quit IRC | 12:39 | |
| dmsimard | Yup. I'm sure you appreciate like me the fact that swiftclient is py3 compatible now but unfortunately 2.7 is going to stick around for a while still :( | 12:40 |
| *** ajc_ has quit IRC | 12:40 | |
| dmsimard | They mention "This support has not been back ported to Python2", I wonder if that means they have not (yet) done it or if they will not do it outright | 12:41 |
| *** dANOKELOFF has joined #openstack-swift | 12:48 | |
| dANOKELOFF | Hi everyone, I follow the guide for SAIO replication ( http://docs.openstack.org/developer/swift/replication_network.html) but i dont understand now, how i can test if the replication work or not. | 12:49 |
| *** miqui has joined #openstack-swift | 12:50 | |
| *** kopparam_ has joined #openstack-swift | 12:53 | |
| *** kajinamit has quit IRC | 12:54 | |
| *** kopparam has quit IRC | 12:56 | |
| *** matsuhas_ has quit IRC | 13:03 | |
| *** matsuhashi has joined #openstack-swift | 13:03 | |
| *** kopparam_ has quit IRC | 13:04 | |
| goodes | Is there a more efficient way to move objects between profiles beyond doing a server side copy/put and then a delete? | 13:04 |
| *** matsuhashi has quit IRC | 13:08 | |
| *** matsuhashi has joined #openstack-swift | 13:08 | |
| *** kopparam has joined #openstack-swift | 13:13 | |
| *** matsuhashi has quit IRC | 13:13 | |
| *** matsuhashi has joined #openstack-swift | 13:14 | |
| *** matsuhashi has quit IRC | 13:18 | |
| *** zz_wasmum is now known as wasmum | 13:24 | |
| *** ppai has quit IRC | 13:26 | |
| peluse_ | dANOKELOFF: if you just want to know that its started 'swift-init object-replciator status'... | 13:27 |
| peluse_ | dANOKELOFF: if you want to test it you can either run the unit tests, or manually PUT an object and then browse your dir strcture to find one of the copies. Then you can edit the file, put some junk it it and save it. | 13:28 |
| dANOKELOFF | peluse_: thank's for the command, i dont found correct guide ton setup the replication , i just found this guide : http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network) | 13:29 |
| peluse_ | dANOKELOFF: make sure the autiro and repl are running and the auditor will figure out that its bad, quantine it, and then the replicator will push a new copy over the top. You can watch all that happen while it happens | 13:29 |
| *** kopparam has quit IRC | 13:29 | |
| dANOKELOFF | peluse_: but i'm not sure this guide is good | 13:29 |
| *** nosnos has quit IRC | 13:29 | |
| peluse_ | dANOKELOFF: actually I haven't personally tried the dedicated repl netork but if you set it up and it is running you can try the steps I just mentioned to see if its actually working (you can manually delete the hashes.pkl file located in the partition directory (and everything below it if you wish) and that will also cause another replicator to push everything back over | 13:31 |
| dANOKELOFF | i would try to upload a file | 13:31 |
| dANOKELOFF | and see if the replication work | 13:32 |
| dANOKELOFF | i really dont understand the replication anyone has a good and clear guide for beginners please ? | 13:40 |
| tdasilva_ | dANOKELOFF: do you have a specific question? | 13:45 |
| tdasilva_ | dANOKELOFF: this doc has a nice section on replication: https://swiftstack.com/openstack-swift/architecture/ | 13:46 |
| dANOKELOFF | tdasilva : yes , i'm beginner with swift so i try to use it and the replication system.I create to different server, with the SAIO swift. I follow the guide Dedicated replication network but when i upload file in my main server, the replication server doesnt received the file , i really dont understand how can use and setup the replication in swift | 13:47 |
| dANOKELOFF | i go to read this | 13:47 |
| peluse_ | is a very good book! | 13:47 |
| peluse_ | dANOKELOFF: you may wan to try the basic SAIO setup first (before anything with dedicated repl netowrk) so that you're starting as simple as possible | 13:48 |
| dANOKELOFF | i do that, i have two saio swift server | 13:48 |
| dANOKELOFF | where i can use for upload file | 13:49 |
| dANOKELOFF | create account | 13:49 |
| dANOKELOFF | list all file present | 13:49 |
| *** haomaiwang has joined #openstack-swift | 13:49 | |
| *** annegent_ has joined #openstack-swift | 13:50 | |
| *** annegent_ is now known as annegentle_ | 13:50 | |
| *** haomaiw__ has quit IRC | 13:50 | |
| dANOKELOFF | But now, i want to implement the replication for secure my data | 13:50 |
| tdasilva_ | so...when you setup saio and start all services, the replication daemon is already running on the saio cluster | 13:51 |
| tdasilva_ | once you upload an object, the object will be replicated automatically for you | 13:51 |
| *** haomaiw__ has joined #openstack-swift | 13:52 | |
| tdasilva_ | that document you listed is for a more advanced setup where you have replicator server running on separate nodes | 13:52 |
| tdasilva_ | it is not needed for the saio setup | 13:52 |
| *** wasmum is now known as zz_wasmum | 13:52 | |
| *** haomaiwang has quit IRC | 13:54 | |
| tdasilva_ | dANOKELOFF: does that help? | 13:55 |
| *** kopparam has joined #openstack-swift | 13:57 | |
| *** zz_wasmum is now known as wasmum | 13:58 | |
| dANOKELOFF | yeah, i know is not need for the saio setup, but i want to implement the replicator in different server, but i dont found any clear guide for that. | 13:58 |
| *** annegentle_ has quit IRC | 14:02 | |
| *** annegent_ has joined #openstack-swift | 14:03 | |
| *** mmcardle has joined #openstack-swift | 14:07 | |
| tdasilva_ | dANOKELOFF: honestly i don't have experience setting up a dedicated replication network, that's probably something notmyname or creiht can help with...they usually show up a bit later... | 14:18 |
| *** kenhui has joined #openstack-swift | 14:18 | |
| dANOKELOFF | ok, tdasilva_ thank's for your help , i continue to read the book for see if i can understand some things. | 14:18 |
| creiht | goodes: that's pretty much it | 14:19 |
| *** wasmum is now known as zz_wasmum | 14:19 | |
| *** tdasilva_ is now known as tdasilva | 14:20 | |
| creiht | dANOKELOFF: not sure I completely understand what you are trying to do | 14:21 |
| creiht | replication talks to the object server to get certain information it needs | 14:22 |
| creiht | normally this is the same object server that is handling all other requests | 14:22 |
| dANOKELOFF | creiht: i try to use the swift replication between two servers, but i dont know how i can use and setup the replication. | 14:22 |
| creiht | the separate replication allows you to run a an object server isntance that is dedicated to object replication | 14:23 |
| creiht | dANOKELOFF: the ring determines what servers/devices are enabled in the cluster | 14:23 |
| creiht | replication uses the ring to figure out where things to be and where it needs to move them to | 14:24 |
| creiht | so if you are adding a server, usually you have to add its devices to the ring | 14:24 |
| creiht | push it out to the servers, and replication will take over | 14:24 |
| dANOKELOFF | creiht: ok. But what is the file when i indicate my other server ? | 14:25 |
| creiht | dANOKELOFF: what do you mean by file? | 14:25 |
| dANOKELOFF | the configuration ring file | 14:26 |
| creiht | dANOKELOFF: http://docs.openstack.org/developer/swift/development_saio.html#setting-up-scripts-for-running-swift | 14:28 |
| creiht | step 7 | 14:28 |
| creiht | when you were setting up the saio | 14:28 |
| creiht | that script is what is used to make the rings for the saio | 14:28 |
| dANOKELOFF | ok thank's. after that, how i can test if the replication working ? | 14:29 |
| goodes | creiht: will the files be deleted immediately? | 14:30 |
| creiht | well once you get swift properly installed on the other node, and setup the ring, then you should see the partitions with objects being replicated over to that other machine | 14:31 |
| creiht | goodes: unless there are failures, then yes it should be deleted as soon as the delete returns | 14:31 |
| goodes | creiht: thes | 14:32 |
| creiht | dANOKELOFF: http://docs.openstack.org/developer/swift/howto_installmultinode.html | 14:32 |
| goodes | creiht: that's reasonable then | 14:33 |
| creiht | that might be good for you to read, as it goes over what needs to be done to setup swift for multiple nodes | 14:33 |
| creiht | the SAIO is mainly meant for developers or people that just want a quick way to try out swift | 14:33 |
| dANOKELOFF | ok thank's but the step 6 and more , the command need to do on the second or the first node ? | 14:34 |
| creiht | goodes: cool... in error cases (like a server isn't responding, or bad drive, etc) replication will eventually take care of it | 14:34 |
| creiht | dANOKELOFF: realy trying to move a SAIO to use more than one machine is a bit complicated | 14:36 |
| creiht | that's why I showed you the other docs, as it should give you a better idea of what you need to do to run swift on more than one machine | 14:36 |
| dANOKELOFF | hum... so i need to reinstall two swift but not SAIO swift | 14:38 |
| dANOKELOFF | creiht: Ok , just one question the step 6 and the other need to do on the two server ? or just one ? | 14:40 |
| *** kopparam has quit IRC | 14:40 | |
| creiht | dANOKELOFF: well it is kind of complicated | 14:41 |
| creiht | dANOKELOFF: the SAIO basically emulates running 4 servers on a single server | 14:42 |
| dANOKELOFF | creiht: ok | 14:43 |
| creiht | dANOKELOFF: if you want ot use swift on more than one machine, it is really better to start over and set up the two machines using what you have learned with the SAIO | 14:44 |
| creiht | and the help of the multi-server instructions | 14:44 |
| *** jyoti_ranjan has quit IRC | 14:46 | |
| dANOKELOFF | creiht: ok, so i need to follow the multi-server instructions and not the SAIO guide. Ok | 14:47 |
| dANOKELOFF | i will do that | 14:47 |
| dANOKELOFF | thank's for your help | 14:47 |
| *** charz has joined #openstack-swift | 14:48 | |
| creiht | np | 14:48 |
| *** IRTermite has quit IRC | 14:52 | |
| *** kevinc_ has joined #openstack-swift | 14:55 | |
| *** IRTermite has joined #openstack-swift | 14:56 | |
| *** charz has quit IRC | 15:00 | |
| *** charz has joined #openstack-swift | 15:02 | |
| *** zz_wasmum is now known as wasmum | 15:05 | |
| *** mmcardle has quit IRC | 15:09 | |
| *** byeager has joined #openstack-swift | 15:14 | |
| *** mwstorer has joined #openstack-swift | 15:16 | |
| toolslive | There is a feature branch for erasure coding. what's the status on that? | 15:19 |
| *** nacim has quit IRC | 15:21 | |
| *** annegent_ has quit IRC | 15:24 | |
| tdasilva | toolslive: as you have probably heard Storage policies have landed on master....that work was being developed on the ec branch | 15:24 |
| tdasilva | as it was the foundation work for ec | 15:25 |
| tdasilva | ec work itself is still ongoing | 15:25 |
| tdasilva | being led by the folks at intel, box and others | 15:25 |
| tdasilva | i'm not sure whether they will use the same feature/ec branch or create a new one | 15:26 |
| toolslive | one of the problems I see is that erasure coding will make the items stored on disk a lot smaller; and you have a lot more of them while swift is using the file system to store them. So I wonder what they will do to compensate that. | 15:27 |
| dANOKELOFF | on this guide (http://docs.openstack.org/developer/swift/howto_installmultinode.html) , step 6, i need to change the adress ip and give the ip adress of my server or i dont change it ? | 15:27 |
| *** bsdkurt has quit IRC | 15:29 | |
| *** judd7 has joined #openstack-swift | 15:30 | |
| *** annegent_ has joined #openstack-swift | 15:34 | |
| *** zaitcev has joined #openstack-swift | 15:36 | |
| *** ChanServ sets mode: +v zaitcev | 15:36 | |
| *** dANOKELOFF has quit IRC | 15:40 | |
| *** gyee has joined #openstack-swift | 15:42 | |
| *** charz has quit IRC | 16:03 | |
| *** annegent_ has quit IRC | 16:05 | |
| *** wasmum is now known as zz_wasmum | 16:10 | |
| notmyname | good morning, world | 16:16 |
| *** nsquare has joined #openstack-swift | 16:17 | |
| peluse_ | toolslive: well, "a lot smaller" depends :) We will have many knobs to help tune for various impacts of doing EC, including a few things to minimize the effect you mention. Bottom line though - EC isn't right for every usage model out there | 16:17 |
| peluse_ | notmyname: good morning! | 16:18 |
| peluse_ | tdasilva: yes, we decided to use feature/ec for the EC work, its not current right now though | 16:18 |
| peluse_ | notmyname: speaking of that, any ETA on when feature/ec will be clean so we can start landing some EC specific stuff? | 16:19 |
| notmyname | peluse_: ya, that's next, now that we got SP landed as a different branch. I'll need to fight clarkb be on it, though. he really doesn't want that history to go away | 16:20 |
| notmyname | peluse_: I'll see if the existing one can be renamed and then the "feature/ec" reused. maybe we'll call it "ec2" just to throw everyone off ;-) | 16:21 |
| peluse_ | notmyname: very cool, let me know when ready. tsg has 2-3 patches that he needs to rebase and propose that will get us started and that's the first step... | 16:22 |
| peluse_ | ec2 - heh | 16:22 |
| * peluse_ offline for an hour or so... | 16:22 | |
| notmyname | dmsimard: this is a cool experiment http://dmsimard.com/2014/06/21/a-use-case-of-tengine-a-drop-in-replacement-and-fork-of-nginx/ | 16:24 |
| notmyname | dmsimard: thanks for writing/publishing it | 16:25 |
| creiht | dmsimard: yeah I read that this morning as well | 16:27 |
| dmsimard | Woah, I'm a superstar now? :) | 16:28 |
| dmsimard | Glad it's useful. | 16:28 |
| notmyname | dmsimard: the buffering thing in nginx is really annoying when normally nginx is a best-practice thing and then when an admin is deploying swift, suddenly they need to learn new tricks. makes adoption harder, I think | 16:30 |
| creiht | haha | 16:30 |
| dmsimard | Yeah I learned it the hard way and had to do a move, quickly :) | 16:30 |
| notmyname | dmsimard: as did we all ;-) | 16:31 |
| *** kevinc_ has quit IRC | 16:31 | |
| dmsimard | In one of the threads I link to, there is this obscure patch of 3k+ lines of C code to be able to disable buffering | 16:31 |
| *** baojg has joined #openstack-swift | 16:31 | |
| dmsimard | I had to find another way :) | 16:31 |
| *** baojg has quit IRC | 16:32 | |
| *** baojg has joined #openstack-swift | 16:32 | |
| notmyname | dmsimard: I wonder if the current direction of nginx to an open-core model would make it impossible to maintain that fork over time. eg they may just say that no-buffer is a pay feature | 16:32 |
| dmsimard | notmyname: good question. Perhaps at that point it'd be time for tengine to distance itself from nginx like mariadb to mysql | 16:33 |
| *** rook has joined #openstack-swift | 16:33 | |
| dmsimard | In my experience, mariadb 5.5 fits right in as a drop-in replacement to mysql.. mariadb 10, not so much | 16:34 |
| dmsimard | hell, mariadb started being the default now in some distributions like fedora | 16:35 |
| dmsimard | so that means something. | 16:35 |
| notmyname | dmsimard: so what you're saying is that nginx will be bought by oracle next? ;-) | 16:36 |
| *** kevinc_ has joined #openstack-swift | 16:38 | |
| *** zz_wasmum is now known as wasmum | 16:38 | |
| *** madhuri has quit IRC | 16:40 | |
| *** CaioBrentano has quit IRC | 16:41 | |
| dmsimard | notmyname: oh my god | 16:43 |
| *** elambert has joined #openstack-swift | 16:43 | |
| dmsimard | Let's hope not :) | 16:43 |
| notmyname | :-) | 16:44 |
| notmyname | that'll be right after they buy rackspace, right creiht? ;-) | 16:44 |
| dmsimard | Well, Redhat is making a lot of waves recently.. with Inktank and Enovance. Rackspace looking for a buyer apparently and Softlayer that was acquired by IBM.. Market is moving a lot. | 16:46 |
| * creiht sighs | 16:46 | |
| *** miqui_ has joined #openstack-swift | 16:50 | |
| *** miqui has quit IRC | 16:51 | |
| *** wasmum is now known as zz_wasmum | 16:52 | |
| *** bsdkurt has joined #openstack-swift | 16:52 | |
| *** mmcardle has joined #openstack-swift | 16:54 | |
| notmyname | mordred: I sent you an email last week taking you up on your offer to do the first swift-spec commit with the infra-required boilerplate. will you be able to get to that this week? | 17:00 |
| *** nsquare has quit IRC | 17:01 | |
| *** byeager has quit IRC | 17:01 | |
| mordred | notmyname: sure nuff | 17:02 |
| notmyname | mordred: thanks | 17:02 |
| *** baojg_ has joined #openstack-swift | 17:04 | |
| *** annegent_ has joined #openstack-swift | 17:05 | |
| *** annegent_ has quit IRC | 17:05 | |
| openstackgerrit | Donagh McCabe proposed a change to openstack/swift: Add swift-checker utility for use by monitoring tools https://review.openstack.org/99961 | 17:05 |
| *** annegent_ has joined #openstack-swift | 17:06 | |
| *** baojg has quit IRC | 17:07 | |
| *** shri has joined #openstack-swift | 17:14 | |
| *** mmcardle has quit IRC | 17:18 | |
| *** annegent_ has quit IRC | 17:26 | |
| *** baojg_ has quit IRC | 17:30 | |
| *** kevinc_ has quit IRC | 17:31 | |
| *** byeager has joined #openstack-swift | 17:32 | |
| *** nsquare has joined #openstack-swift | 17:33 | |
| *** annegent_ has joined #openstack-swift | 17:35 | |
| *** byeager has quit IRC | 17:41 | |
| *** kevinc_ has joined #openstack-swift | 17:42 | |
| clayg | morning | 17:43 |
| clayg | peluse_: has someone volunteered to do the sed replace of POLICY[_INDEX] with X[-Backend]-Storage-Policy[-Index]? | 17:43 |
| clayg | peluse_: can i volunteer you? I probably won't get around to it for a couple of days | 17:44 |
| clayg | creiht: on the list endpoints api thing - I don't want to make the redirect... well I just don't think it will work on all clients - so it seems like it should be able to turn off | 17:44 |
| creiht | clayg: yeah I understand | 17:44 |
| creiht | not sure if you can just turn it off? | 17:45 |
| clayg | creiht: but I also don't really want /endpoints/ to just... "always" respond /v1 - it seems useless to clients from a discoverability perspective to push them to the old version | 17:45 |
| creiht | ahh | 17:45 |
| clayg | creiht: i like /endpoints/v1/ and /endpoints/v2/ to both be there and work | 17:45 |
| peluse_ | clayg: you bet | 17:45 |
| clayg | creiht: the only question is what to do with /endpoints/ | 17:45 |
| peluse_ | clayd: what was the final verdict wrt what to call them? | 17:45 |
| clayg | peluse_: string literals for the headers like every other header in the book | 17:46 |
| creiht | clayg: yeah | 17:46 |
| peluse_ | clayg: no sweat | 17:46 |
| clayg | creiht: i sorta had the mind that if we had *started* with the /v2/ response I wouldn't even be doing this whole version dance - which is why i sorta had this notion that some deployments might just make /endpoints/ point to v2 and happyily go on like that for years... but OTOH i get your point about differences between deployments - if someone did "swift ring api bindings in ruby" and they only work with /endpoints/ that re | 17:47 |
| clayg | creiht: dunno if that cut off | 17:47 |
| clayg | creiht: so I like the idea that maybe /endpoints is a redirect - then *most* client authors will pick the format they want and ask for it as /v2 or /v1 | 17:48 |
| clayg | creiht: but for legacy clients /endpoints *has* to be able to respond /v1 - it's like a "redirect_api = None" sorta situation... idk | 17:48 |
| * clayg is just babbling cause he doesn't know what the right answer is | 17:49 | |
| clayg | fucking tradeoffs | 17:49 |
| *** byeager has joined #openstack-swift | 17:49 | |
| clayg | peluse_: THANKS! | 17:49 |
| clayg | creiht: anyway, the {'endpoints': [], 'headers', []} thing for the /v2 responses seemed like a good idea - i'll definately do that | 17:50 |
| clayg | notmyname: torgomatic: i'm also working on a patch to make the reconciler scale sorta like what we did with the expirer - but it's a little trickier because you don't want objects to just get "skipped" for long periods if the queue isn't very deep or one of the reconciler process = N is down | 17:51 |
| clayg | notmyname: so I just abandon all the other pending storage policies reviews? it doesn't look like that happened automatically when it got merged last week | 17:52 |
| clayg | torgomatic: any other cores in channel that might want to look at adding the x-backend-storage-policy-index header to the additional_info in the object server logs? | 17:53 |
| notmyname | clayg: not yet. mordred had some ideas on how to get those actually marked as merged in gerrit. that's the first thing to try. | 17:53 |
| torgomatic | clayg: yeah, it gets tricky; you gonna have two sync points like container sync does? | 17:53 |
| notmyname | mordred: but on that (the gerrit patches) something needs to happen soon so that we can get them out of the way for reviews | 17:54 |
| clayg | torgomatic: on the scaling thing? nah, i wasn't thinking that exactly. what you mean in the db's or for the queue? the reconciler is a lot more like the expirer that container sync | 17:54 |
| mordred | notmyname: nod | 17:54 |
| notmyname | mordred: thanks | 17:54 |
| notmyname | mordred: if you're choosing between the gerrit reviews and swift-specs to do first, the gerrit reviews are more important | 17:55 |
| notmyname | :-0 | 17:55 |
| notmyname | :-) | 17:55 |
| creiht | clayg: sorry lost my network connection | 17:55 |
| torgomatic | clayg: yeah, I was just thinking of how the container sync guy has the two windows; first he does his work, and then he does everyone else's old work | 17:55 |
| *** kevinc___ has joined #openstack-swift | 17:56 | |
| clayg | torgomatic: oh yeah that part is gunna be sorta similar in that regard, but it'll be doing the if hash(queue_entry) % processes != (some subset of process N that i'm working on this cycle): skip sorta dance | 17:56 |
| creiht | clayg: part of me wonders how many people use the endpoints stuff | 17:57 |
| clayg | notmyname: mordred has a small army of clones for these types of multi-tasking events | 17:57 |
| creiht | I think a short term, would be go /v1 and /v2 and have endpoints/ be a copy of /v1 for now | 17:58 |
| creiht | and document that endpoints/ is deprecated | 17:58 |
| clayg | creiht: probably just zerovm - but I'm not sure if that's an excuse to do something stupid - seems like it's a decent exercise in how to revise un-versioned apis? | 17:58 |
| clayg | creiht: that's pretty close to how I'm leaning i suppose | 17:58 |
| creiht | then we can move at a later release to remove that | 17:58 |
| creiht | cool | 17:58 |
| creiht | we do the best we can | 17:58 |
| creiht | :) | 17:58 |
| creiht | the other problem is that /v1 isn't going to work with clusters that haven't upgraded yet | 17:59 |
| creiht | so it makes it difficult for clients | 17:59 |
| clayg | creiht: alright well let me get that working at least and then if anyone has a better idea before too long we could go and try that too | 17:59 |
| clayg | creiht: ack | 17:59 |
| notmyname | clayg: creiht: soo (good|bad) news is that I found another user of /endpoints :-) | 18:00 |
| notmyname | beyond pconstantine at zerovm | 18:00 |
| creiht | hah | 18:00 |
| creiht | well the hadoops integration uses it right? | 18:00 |
| notmyname | gil (gvernick -- don't remember exactly) is using it with apache spark for hadoopy-style stuff | 18:01 |
| notmyname | clayg: right | 18:01 |
| *** jamiehannaford has quit IRC | 18:01 | |
| *** kevinc_ has quit IRC | 18:01 | |
| notmyname | but the good news is that he's normally in here | 18:01 |
| notmyname | (gil at IBM Haifa) | 18:01 |
| creiht | notmyname: well the real bad news, is we really can't know how many people us it | 18:01 |
| creiht | use it | 18:01 |
| notmyname | of course | 18:01 |
| creiht | but either way, I think what clayg will be doing will work | 18:02 |
| notmyname | yes. agreed | 18:02 |
| notmyname | clayg: +1 | 18:02 |
| creiht | just have to make sure we communicate it well | 18:02 |
| *** mkollaro has quit IRC | 18:02 | |
| creiht | so that we don't catch anyone off guard | 18:02 |
| clayg | oh it's so weird to type 'git rebase -i master' and only see one change - i sorta had to remember how to do swift branch based workflow after doing the rebase changes into a chain based workflow for three weeks | 18:03 |
| notmyname | creiht: this actually sounds very similar to the transition RAX had to do with moving auth to v2+ for new regions | 18:03 |
| clayg | creiht: clients make everything harder, it's easy to write software no one uses | 18:03 |
| dmsimard | notmyname, creiht: Damn, I didn't even notice Mirantis linked to my article. That's an accomplishment for me :O | 18:03 |
| *** jamiehannaford has joined #openstack-swift | 18:03 | |
| creiht | clayg: lol | 18:03 |
| creiht | haha | 18:03 |
| dmsimard | er, s/accomplishment/achievement/ | 18:03 |
| notmyname | dmsimard: badge unlocked | 18:04 |
| torgomatic | having a middleware whose job is to expose internal data structures really does make it hard to maintain compatibility | 18:04 |
| creiht | dmsimard: one step closer to the stackerati | 18:04 |
| clayg | torgomatic: well and having it expose it w/o a version in a sturcture that you can't add data to... | 18:04 |
| torgomatic | clayg: true; that certainly doesn't help | 18:05 |
| clayg | creiht: is that like a car you win for being a openstack fanboy? | 18:05 |
| creiht | haha | 18:05 |
| notmyname | emacs users rejoice. vim commands in openstack source files considered harmful. https://review.openstack.org/#/c/101969/ | 18:07 |
| * notmyname throws gasoline on the fire | 18:07 | |
| creiht | lol | 18:07 |
| torgomatic | M-x erc-part-from-channel | 18:08 |
| *** elambert has quit IRC | 18:13 | |
| *** zz_wasmum is now known as wasmum | 18:15 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Minor Updates to Storage Policy Docs https://review.openstack.org/101705 | 18:15 |
| *** elambert has joined #openstack-swift | 18:15 | |
| peluse_ | clayg: OK, about to enter formatting hell... header replacement underway. If you don't hear back from me in 10 hours call the paramedics :) | 18:16 |
| *** occupant has quit IRC | 18:17 | |
| clayg | peluse_: understood | 18:17 |
| notmyname | proposed idea of how to re-use the feature/ec branch (for actual ec work): tag the current HEAD of feature/ec as storage-policies-historical, then delete/recreate feature/ec off of current HEAD of master | 18:19 |
| notmyname | gholt: note I said HEAD of <branch>, not tip ;-) | 18:19 |
| *** nthacker_ has joined #openstack-swift | 18:19 | |
| notmyname | clayg: peluse_: ^^ sound ok for banch management? | 18:20 |
| peluse_ | notmyname: works for me | 18:21 |
| *** nthacker__ has quit IRC | 18:22 | |
| *** zaitcev has quit IRC | 18:25 | |
| clayg | notmyname: i like the delete part, everything else seems ok - but I think portante was on to somehting calling the branch for doing ec work 'feature/sp' | 18:30 |
| rook | hey guys, is this the correct header to set account listing (list of containers) for a user? swift stat | grep X-Ac ===> Meta X-Account-Read: eu1prdimgsrvtenant:eu1prdimgsrvread01 | 18:31 |
| notmyname | clayg: peluse_: doesn't look like I can push tags to gerrit for swift (I can for swiftclient), so I'll try to find someone with the proper perms to do it | 18:32 |
| portante | clayg: yes! | 18:33 |
| *** toolslive has quit IRC | 18:34 | |
| *** zaitcev has joined #openstack-swift | 18:35 | |
| *** ChanServ sets mode: +v zaitcev | 18:35 | |
| notmyname | peluse_: hmm..what will it take to get tushar and kevin on IRC normally? :-) | 18:39 |
| peluse_ | notmyname: cold hard cash I'd bet :) | 18:40 |
| notmyname | peluse_: that tends to work well for most people :-) | 18:40 |
| torgomatic | is master still frozen, or are we merging stuff again? | 18:40 |
| peluse_ | notmyname: seriously, tsg is usually lurking and will obviously become more active once he posts to gerrit... | 18:41 |
| creiht | torgomatic: let it go... let it go... | 18:41 |
| creiht | sorry, couldn't resist :) | 18:41 |
| notmyname | torgomatic: unfrozen. merge away | 18:41 |
| torgomatic | creiht: hey, I'll have you know I've only had to hear songs from that movie *twice* today! :) | 18:41 |
| creiht | haha | 18:42 |
| notmyname | wanna build a snowman? | 18:42 |
| creiht | what's one more? | 18:42 |
| creiht | https://www.youtube.com/watch?v=Pa-qgRasdvc | 18:43 |
| creiht | :) | 18:43 |
| *** wasmum is now known as zz_wasmum | 18:43 | |
| notmyname | creiht: wow | 18:43 |
| creiht | :) | 18:43 |
| *** j_king has joined #openstack-swift | 18:45 | |
| notmyname | peluse_: there is some concern with PyECLib from upstream packagers that needs to be addressed. Kevin and Tushar are the points of contact, right? | 18:45 |
| peluse_ | notmyname: correct | 18:46 |
| notmyname | ack | 18:46 |
| creiht | bar | 18:46 |
| peluse_ | tushar has already had some discussions there (fyi) | 18:46 |
| tdasilva | creiht, torgomatic: even pearl jam is singing it: https://www.youtube.com/watch?v=kBPRVUG0kiQ :P | 18:47 |
| creiht | hehe | 18:48 |
| peluse_ | that made the Today show this morning | 18:48 |
| *** zz_wasmum is now known as wasmum | 18:50 | |
| gholt | notmyname: Nicely done, you're learning git! ;) | 18:52 |
| notmyname | gholt: one day I'll figure out all this new technology | 18:52 |
| *** mkollaro has joined #openstack-swift | 18:53 | |
| *** miqui_ is now known as miqui | 18:53 | |
| *** jamiehannaford has quit IRC | 18:56 | |
| *** tdasilva has quit IRC | 19:01 | |
| *** wasmum is now known as zz_wasmum | 19:05 | |
| clayg | rook: missed your question earlier, i'm not sure i understood - but account acl's don't ever use X-Acount-Read, it's X-Account-Acl: <json> all the time | 19:10 |
| *** esmute has quit IRC | 19:10 | |
| *** byeager has quit IRC | 19:11 | |
| clayg | rook: one of the keys in <json> is "read_only": ["list", "of", "users"] | 19:11 |
| rook | clayg: ah TY - trying it | 19:12 |
| rook | clayg: like this? swift post 'X-Account-Acl: {"read_only": ["eu1prdimgsrvtenant:eu1prdimgsrvread01"]}' | 19:16 |
| clayg | rook: maybe a -H 'X-Account-Acl:{"read_only": ["eu1prdimgsrvtenant:eu1prdimgsrvread01"]}' - not sure i recal | 19:17 |
| *** esmute has joined #openstack-swift | 19:25 | |
| *** zz_wasmum is now known as wasmum | 19:26 | |
| *** kevinc___ has quit IRC | 19:28 | |
| wasmum | wow the scroll back of today, lead me to PJ singing Let it go... not half as good as my 4 year princess though, sorry Eddie | 19:38 |
| rook | clayg: https://gist.github.com/anonymous/cd85783452b73e0d62fa did I add the ACL correctly ? | 19:38 |
| clayg | rook: yeah the X-Account-Acl header is like normally sanitized somewhat... but your users don't have auth prefixes... are you using keystone? | 19:39 |
| rook | yes | 19:39 |
| clayg | rook: i don't think keystone supports account-acls' | 19:40 |
| rook | bummer | 19:40 |
| clayg | rook: acctually i'm sure it doesn't, but I'm saying "I don't think" incase i'm wrong | 19:40 |
| notmyname | clayg: it doesn't yet | 19:41 |
| clayg | rook: i'm curious though - what's your use case for account acl's and keystone - most keystone folks seem to think that's all better handled by the auth system (not that keystone or keystone_auth in swift supports that either) | 19:41 |
| rook | Yeah, my customer insists on using keystone because they are going to implement the rest of the openstack stack. swift is just their first deployment | 19:42 |
| clayg | rook: well i say keystone doesn't support it - the roles and policies stuff is pretty flexible - I think if keystone_auth was smarter you could come up with some sort of keystone-client command that you could send to keystone to make a user have read only access to another user's account in swift | 19:42 |
| rook | clayg: TY, will start digging | 19:43 |
| clayg | rook: good for them! | 19:43 |
| *** jamiehannaford has joined #openstack-swift | 19:43 | |
| clayg | rook: ok, container-acl's work in keystone_auth like you might expect tho... | 19:43 |
| notmyname | ya, in the next few months we need to get account-acl support into the keystone middleware, I think. rook, I'd love it if you could help contribute code for that! | 19:43 |
| clayg | notmyname: last I talked with acoles he didn't really think account-acl's in keystone_auth was worth pursing, otherjon also sorta had the notion that policies and roles support in keystone auth would be more interesting | 19:44 |
| notmyname | ah | 19:44 |
| clayg | notmyname: I persaonlly don't much care for policies and roles - and think it'd be way better from a swift clint perspective if keystone_auth was extended to do swift account acl's the way other auth middlewares that don't have a seperate "idenity api" are going to work. | 19:45 |
| notmyname | clayg: hmmm..that doesn't immediately make sense to me. I'll need to bug them on it and think it over. why wouldn't swift store account acl roles like it does for containers? | 19:45 |
| notmyname | but acoles and otherjon have been working and thinking about keystone a _lot_ more than I have | 19:46 |
| clayg | notmyname: I think at the fundemental level swift accounts (and their authorization) aren't discoverable - where as keystone already has a record of every account, so unlike say... ldap intergration... there's no reason you can't just update the keystone database for the account everytime you want to grant someone access | 19:47 |
| notmyname | I'll begrudgingly not argue there. It doesn't sound great, but my rebuttal isn't very good either :-) | 19:49 |
| clayg | notmyname: I think it'd be fine to have both, but at some level the lack of auditability of swift's account acls is sorta problematic for security teams (we try not to tell them we already have container acl's - sshhhhhh) | 19:49 |
| clayg | rook: oh hey, btw, that traceback looks terrible - can you repeat that request with curl and capture the raw swift response? | 19:50 |
| notmyname | clayg: ya, but at that point, you pretty much have the same argument of directory permissions (or ACLs) on a filesystem. (thanks for that analogy creiht) | 19:50 |
| rook | clayg: ok | 19:51 |
| notmyname | eg you can't really ask a filesystem "show me all the directories that I have access to". same with swift, currently | 19:51 |
| clayg | notmyname: oh yeah i agree, and looking into "all the servers" and checking the pam_ldap.conf is somehow more palitable than doing a HEAD on every account? idk, i like account acls' - but i assume that you want the people creating the data in charge of who has access to it | 19:52 |
| rook | https://gist.github.com/anonymous/721acee68786093b7843 | 19:54 |
| clayg | oh gawd keystone tokens... | 19:55 |
| creiht | lol | 19:55 |
| rook | lol - sorry | 19:55 |
| notmyname | lol | 19:56 |
| clayg | rook: anyway that 403 looks pretty reasonable, and basically what you'd expect from an auth system that doesn't support account acls - so... i wonder why the client choked so hard? | 19:56 |
| rook | clayg: yeah, haven't gone thru the stack - too many other things on the plate atm | 19:56 |
| *** foexle has quit IRC | 19:56 | |
| *** psharma has quit IRC | 19:58 | |
| *** miqui has quit IRC | 19:58 | |
| clayg | rook: yeah np, thanks for what you got - if you're still feeling like super charitable you could file a bug at https://bugs.launchpad.net/swift/+filebug | 19:59 |
| *** kevinc_ has joined #openstack-swift | 19:59 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Replace POLICY and POLICY_INDEX with string literals https://review.openstack.org/101991 | 19:59 |
| clayg | rook: i guess I could just copy/paste your gist, might be good enough if someone has a devstack/keystone/swift setup rockin' | 19:59 |
| openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Add v2 API to list endpoints middleware https://review.openstack.org/101665 | 20:02 |
| *** wasmum is now known as zz_wasmum | 20:05 | |
| *** zz_wasmum is now known as wasmum | 20:06 | |
| *** occupant has joined #openstack-swift | 20:10 | |
| rook | clayg: I'm stuck in a infinate loop choosing a password for a new launchpad account :/ grr | 20:15 |
| *** acoles has quit IRC | 20:16 | |
| clayg | rook: wtf, oh many i'm so sorry :( | 20:18 |
| rook | lol - workin on it | 20:18 |
| notmyname | peluse_: clayg: SAIO running unittests. swift.conf has 3 policies (0,1,2), policy 2 is default, none are deprecated. unittests fail (can't find object-2.ring.gz). is that expected? | 20:20 |
| peluse_ | did you create the ring file? | 20:24 |
| rook | clayg: https://bugs.launchpad.net/swift/+bug/1333409 | 20:25 |
| notmyname | peluse_: I've got rings for all those (eg swift works). but those rings are in /etc/swift. it fails in test_wsgi because(?) _fake_rings() only creates 2 rings in the tmpdir. but maybe the test is getting code from swift.conf too? | 20:26 |
| notmyname | peluse_: ie I think that the tests are getting config overlap from /etc/swift and not handling it properly in the test framework | 20:27 |
| peluse_ | notmyname: yeah, OK that's probably a real problem. Have dealt with a bunch of those kinds of things, will take a look... give me a min | 20:27 |
| notmyname | peluse_: no particular rush yet. just something I noticed just now | 20:28 |
| notmyname | thanks | 20:28 |
| *** joeljwright has quit IRC | 20:31 | |
| *** wasmum is now known as zz_wasmum | 20:31 | |
| notmyname | torgomatic: I'm looking at https://review.openstack.org/#/c/93780/ (which you gave a +2 to), and I don't see how the new code path is actually tested. but maybe I'm missing something about mocking (likely) | 20:34 |
| torgomatic | notmyname: it's not really tested that well, but it's like... pass this flag to this library so that $thing-under-swift happens | 20:36 |
| *** zz_wasmum is now known as wasmum | 20:37 | |
| notmyname | torgomatic: I get the mechanism | 20:38 |
| otherjon | notmyname: clayg: rook: it seems to me that while tracking "everything I can access" is a difficult problem, it's the auth middleware's problem rather than core Swift's -- someone could write middleware that intercepted every PUT/POST, checked if account ACLs were being set, updated a canonical source of truth which mapped auth groups (not users, not accounts) to access locations (accounts or containers), solved the problem of replicating tha | 20:38 |
| otherjon | t source of truth, etc. | 20:38 |
| otherjon | wouldn't be easy, but it's not a swift limitation | 20:38 |
| clayg | notmyname: notmyname did you really just ask if failing unittests are "expected"??!? | 20:38 |
| notmyname | torgomatic: just that the mock for inspect is just there to make it not break, rather than actually testing it. in fact (just confirmed) the patch doesn't touch line 346 (the one that's actually doing the thing) | 20:38 |
| notmyname | clayg: lol. no, failing if more than 2 policies are defined in swift.conf expected to cause failure | 20:39 |
| clayg | notmyname: sounds like the same question to me, the @patch_policies thing is something folks writing tests are gunna have to get used to... don't know exactly what form of failure your describing | 20:40 |
| clayg | but either something is messed up or you messed something up, dunno | 20:40 |
| notmyname | clayg: nah that's not it in this case. I think peluse_ confirmed that it's unexpected and was looking further in to it | 20:40 |
| clayg | notmyname: yeah i mean tests shouldn't look at swift.conf or anything in /etc/swift really - but they do sometimes if you forget to mock something... | 20:41 |
| clayg | mock/patch w/e | 20:41 |
| clayg | notmyname: oh, i guess if swift.conf exists and is not valid import swift might fail - so you could get failing tests that way | 20:42 |
| clayg | notmyname: it'd be like a test that calls hash_path but doesn't patch endcap or something | 20:43 |
| notmyname | clayg: ah, it may be a missing decorator somewhere. the failing test (testing the wsgi pipeline mutating) isn't decorated | 20:43 |
| clayg | notmyname: idk ring loading doesn't normally happen at import time though | 20:43 |
| clayg | notmyname: oh, well then that's probably it - probably again assuming your swift.conf isn't valid to acctually start a wsgi server in the first place? | 20:44 |
| notmyname | swift.conf is valid | 20:44 |
| clayg | notmyname: still highlights a dependency on the the test and /etc/swift which is generally bad | 20:44 |
| notmyname | right. I think that was my point or question | 20:44 |
| notmyname | clayg: also, just to clarify, if no policy is set as default (eg I have 0 and 1, both with rings and a name set), then policy 0 is set as default, right? this is what I expected, but I get a "no default set" error | 20:45 |
| clayg | notmyname: docs say if you define more than one policy you have to specify a default | 20:45 |
| notmyname | clayg: ah, gotcha. thanks | 20:45 |
| notmyname | clayg: which is exactly what I'm seeing. so that's good :-) | 20:46 |
| clayg | notmyname: and I still don't think "a dependency on the the test and /etc/swift which is generally bad" is a question | 20:46 |
| peluse_ | sorry, was off on a call. so easy to repro - I'll go ahead and take care of it unless you've already fixed it | 20:47 |
| notmyname | peluse_: getting a repro right now, but I haven't looked in to a patch yet | 20:48 |
| *** kevinc_ has quit IRC | 20:53 | |
| peluse_ | notmyname: yeah. missing decorators on a few functions | 20:54 |
| notmyname | peluse_: ah ok | 20:54 |
| notmyname | peluse_: is that jsut @patch_policies? | 20:55 |
| peluse_ | notmyname: in need of one more tweak as well but yes that's the one that's missing. | 20:55 |
| notmyname | peluse_: ah ok. then if you've already solved it (and I'm jsut locally testing what you're saying) can you submit it? unless you don't even have your editor open, I can do it | 20:56 |
| *** jamiehannaford has quit IRC | 20:57 | |
| *** miqui has joined #openstack-swift | 20:57 | |
| peluse_ | the one additional tweak is in _fake_rings() btu yes I'll go ahead and submit it. Need a few more min to scrub and do some additional testing | 20:57 |
| notmyname | peluse_: https://gist.github.com/notmyname/2e3e682e743aa0fa1d36 | 21:01 |
| *** dmsimard is now known as dmsimard_away | 21:01 | |
| notmyname | peluse_: same with or without _fake_rings() patches | 21:01 |
| notmyname | *patched | 21:02 |
| clayg | notmyname: ew... that one has to do with the mocked policies caching rings between tests, sort of a failing of the class level patch polies | 21:02 |
| peluse_ | notmyname: the tweak isn't to patch _fake_rings(), its currently incorrect in its used of declaring a local policy collection | 21:03 |
| notmyname | oh | 21:03 |
| notmyname | makes sense | 21:03 |
| clayg | peluse_: who's _fake_rings()? | 21:03 |
| notmyname | clayg: test_wsgi.py | 21:03 |
| *** annegent_ has quit IRC | 21:04 | |
| * notmyname is starting to think he won't get everything done today that he wanted to do | 21:06 | |
| clayg | notmyname: peluse_: meh, patch_policies should probably create new policies each time instead of reusing the same muted globals - what a pita | 21:07 |
| clayg | mutated | 21:07 |
| peluse_ | claygg: will propose something shortly.... see whatcha think | 21:08 |
| *** byeager has joined #openstack-swift | 21:14 | |
| openstackgerrit | Joel Wright proposed a change to openstack/python-swiftclient: Add importable SwiftService incorporating shell.py logic https://review.openstack.org/85453 | 21:19 |
| *** wasmum is now known as zz_wasmum | 21:22 | |
| *** byeager has quit IRC | 21:26 | |
| * notmyname steps away for a while | 21:30 | |
| *** kenhui has quit IRC | 21:34 | |
| *** rook has quit IRC | 21:41 | |
| *** kevinc_ has joined #openstack-swift | 21:47 | |
| *** pconstantine_ has joined #openstack-swift | 21:50 | |
| *** jamiehannaford has joined #openstack-swift | 22:02 | |
| *** zz_wasmum is now known as wasmum | 22:05 | |
| openstackgerrit | Joel Wright proposed a change to openstack/python-swiftclient: Add importable SwiftService incorporating shell.py logic https://review.openstack.org/85453 | 22:08 |
| *** wasmum is now known as zz_wasmum | 22:08 | |
| *** zz_wasmum is now known as wasmum | 22:20 | |
| *** wasmum is now known as zz_wasmum | 22:21 | |
| *** pconstantine_ has quit IRC | 22:25 | |
| *** pconstantine_ has joined #openstack-swift | 22:29 | |
| mattoliverau | Morning everyone | 23:00 |
| * notmyname is back for a bit | 23:02 | |
| *** dmsimard_away is now known as dmsimard | 23:03 | |
| *** jamiehannaford has quit IRC | 23:04 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Fix issues with test_wsgi.py and Storage Policies https://review.openstack.org/102052 | 23:05 |
| notmyname | peluse_: looking (thanks) | 23:06 |
| peluse_ | notmyname: no prob. turned out to be a little more of a PITA than I thought so hopefully it passes for you as well and you and/or clayg can double check the imp changes also | 23:08 |
| * peluse_ heading home... | 23:09 | |
| notmyname | peluse_: in your updated test_loadapp_proxy() | 23:09 |
| notmyname | peluse_: is overriding POLICIES and then not setting it back going to cause problems? | 23:10 |
| notmyname | peluse_: ah, nm. it's ok because _fake_ring resets it | 23:11 |
| notmyname | tests pass | 23:11 |
| shri | Folks… Consider that I have swift cluster deployed with multiple regions. Is there a way for the client to write data to a specific region? | 23:26 |
| notmyname | shri: are the regions independently addressable? | 23:27 |
| shri | nope | 23:27 |
| notmyname | ie do you have a unique domain/IP endpoint for each? | 23:27 |
| notmyname | shri: your using one domain/IP for each and eg use DNS to route to the "closest"? | 23:27 |
| shri | actially, right now this is just slideware.. but yes, I could either use DNS to route to the closest or have separate IPs for each. | 23:28 |
| shri | *actually | 23:28 |
| notmyname | ok, there's two solutions then :-) | 23:29 |
| notmyname | shri: you could also look in to Swift's write and read affinity settings | 23:29 |
| *** acoles has joined #openstack-swift | 23:30 | |
| *** ChanServ sets mode: +v acoles | 23:30 | |
| notmyname | shri: ie http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters | 23:30 |
| shri | yeah… I'm seeing just those. but then those settings are at the swift proxy config level. When a client writes, it will directly send the http request to the swift endpoint | 23:30 |
| notmyname | shri: right. which is a proxy server | 23:30 |
| notmyname | shri: you'll have proxy servers everywhere | 23:30 |
| shri | oh… | 23:30 |
| notmyname | shri: eg https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/ | 23:31 |
| shri | so I can have proxy servers in each region and clients will simply write data to the proxy server closest to them | 23:31 |
| notmyname | shri: it's slightly more complicated than that. read over those two links first | 23:31 |
| shri | ok .. :-) | 23:31 |
| notmyname | shri: and now that storage policies are merged (as of last friday) you could create a policy for each region. but you won't find a lot of docs online for that yet--it's not even released yet (still in QA) | 23:32 |
| shri | sure… let me go through this and understand it first. will come back with more questions! | 23:33 |
| *** annegent_ has joined #openstack-swift | 23:38 | |
| mattoliverau | While questions are flying around, last night (my time) a question came up in channel, so I thought I'd ask the experts the answer so I can help them tonight (after you all go to sleep). The question was about reseller_prefix's, this guy wanted to change the reseller-prefix but the account databases have the old one set. So how does one go changing the reseller prefix.. according to some old answers | 23:38 |
| mattoliverau | on lauchpad, there used to be a swift-auth-update-reseller-prefix cli tool. Is this possible any more? If not would they have to load the requred middle ware again with a different prefix and migrate or can swift do something magic? | 23:38 |
| notmyname | mattoliverau: I don't remember that tool, but it seems like a pretty hard thing to change. the reseller prefix is used as part of the hash for placement, so _every_ thing (account, contianer, and object) would have to be rehashed | 23:39 |
| *** elambert has quit IRC | 23:40 | |
| *** mkollaro has quit IRC | 23:40 | |
| torgomatic | the moral of the story: even if you're 100% sure that your cluster will never be used for anything, don't make your reseller prefix "BUTT_" | 23:40 |
| notmyname | torgomatic: what's that transid suffix you have? | 23:41 |
| torgomatic | notmyname: exactly :) | 23:41 |
| notmyname | lol | 23:41 |
| * notmyname out again for a while | 23:42 | |
| mattoliverau | lol, fair enough, thanks guys. Good to have an extra peice of the puzzle and have a definitive answer for them :) | 23:45 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!