ho | notmyname: i think we need to find out a way to use oslo libraries | 00:00 |
---|---|---|
notmyname | I'm not opposed to using oslo libraries. it's a question of what problem they are solving for us vs the added complexity they bring | 00:01 |
*** haomai___ has joined #openstack-swift | 00:02 | |
notmyname | eg adding policy.json support is nice, but that (currently) seems to mean that we add new dependencies to swift and a whole new config system that isn't compatible with what deployers have been using for 5+ years | 00:02 |
*** yuanz has quit IRC | 00:03 | |
*** haomaiwa_ has quit IRC | 00:03 | |
ho | notmyname: my idea is hybrid (only middleware which uses olso libs initialize oslo config). not swift to oslo config deployment. I also don't want to change current deployment method (paste ini). | 00:04 |
notmyname | yeah, that sounds a lot better than "everythign switch to a new config system" :-) | 00:04 |
notmyname | but doesn't that mean we'd end up with one config for keystone middleware and another config for everything else? that doesn't sound very nice | 00:05 |
notmyname | ho: how come it's not possible to put the necessary new config variables into the existing config section we have today? | 00:07 |
ho | notmyname: my idea is swift uses only proxy-server.conf but swift can get info from oslo config style and current style. | 00:07 |
*** petertr7 is now known as petertr7_away | 00:08 | |
*** proteusguy has quit IRC | 00:08 | |
ho | notmyname: it's difficult because you know oslo config is a global variable and some oslo libraries access it so it's difficult to control. | 00:09 |
notmyname | isnt' that just a bad idea in general? having a global variable that multiple threads read and write to? | 00:10 |
notmyname | but what do you mean by "difficult to control"? | 00:11 |
ho | notmyname: i think so. we can't handle multi instances. "difficult to control" is oslo libraries use global conf internally so if I introduces oslo conf as a local conf, I also need to bring the local conf to other libraries. | 00:13 |
notmyname | ho: so eg in the current patch, when you create a new Enforcer(), you pass in the global CONF variable. why not pass in the config values that we already have and can derive from our existing config parser? | 00:13 |
ho | notmyname: you checked my code :-) I will re-produce it but I have some trouble with only passed CONF to Enforcer. I'm not sure now. | 00:14 |
notmyname | oh, don't take my questions to mean that I understand either ;-) | 00:15 |
ho | notmyname: sorry, wait a minute. | 00:15 |
*** jrichli has quit IRC | 00:15 | |
*** yuan has joined #openstack-swift | 00:18 | |
*** nadeem has quit IRC | 00:19 | |
ho | notmyname: CONF has some attributes such as project so I need to hack the CONF to pass it and I mentioned that oslo pli | 00:19 |
*** jrichli has joined #openstack-swift | 00:20 | |
ho | notmyname: and oslo policy or some oslo dependencies use oslo config. | 00:20 |
*** proteusguy has joined #openstack-swift | 00:20 | |
*** pgbridge has quit IRC | 00:20 | |
ho | notmyname: minimum approach only for my problem is just initialize oslo config but not use it. | 00:21 |
notmyname | so CONF is more than just a mapping of config options. it has some magic state and methods that do things outside of what we need it for. and the policy class constructors (eg Enforcer) require a CONF object to be passed in. therefore we need to have a CONF object to give it | 00:24 |
*** dmorita has quit IRC | 00:24 | |
notmyname | s/CONF/whatever cfg.CONF thing/ | 00:24 |
notmyname | is that basically right? | 00:24 |
*** dmorita has joined #openstack-swift | 00:24 | |
ho | notmyname: thanks for the summarization. it's right :-) | 00:25 |
notmyname | ho: based on your patch as-is right now, there are zero new config files needed by deployers, right? (except for the new policy.json -- I'm thinking just of an operator who has upgraded and hasn't started using it) | 00:27 |
ho | notmyname: right! zeo new config files. | 00:28 |
*** Guest73 has joined #openstack-swift | 00:28 | |
ho | s/zeo/zero/ | 00:28 |
*** Guest73 has quit IRC | 00:31 | |
*** haomai___ has quit IRC | 00:34 | |
*** richmit has joined #openstack-swift | 00:36 | |
*** richmit has quit IRC | 00:37 | |
notmyname | ho: what is the new _shared_state dictionary for? where is that used? | 00:40 |
notmyname | oh wait. that's making one data structure that all instances have access to? | 00:41 |
*** chlong has joined #openstack-swift | 00:41 | |
*** jasondotstar has quit IRC | 00:42 | |
notmyname | why? | 00:42 |
ho | notmyname: yes, oslo policy exectes some method such as authorize_cross_tenant, check_role_by_acls. the purpose is to share the instance attributes b/w AclCheck and KeystoneAUth | 00:44 |
ho | notmyname: many typo... s/exectes/executes/ s/KeystoneAUth/KeystoneAuth/ | 00:46 |
notmyname | what's ACLCheck? | 00:47 |
*** jrichli has left #openstack-swift | 00:48 | |
ho | notnyname: AclCheck is a class which deal with swift's container acl checking (I will introduce new rule which starts with "acl:". see L122 in keystoneauth.py ) | 00:50 |
*** kota_ has joined #openstack-swift | 00:50 | |
*** ChanServ sets mode: +v kota_ | 00:50 | |
kota_ | morning | 00:51 |
swifterdarrell | kota_: g'morning! | 00:52 |
*** jrichli has joined #openstack-swift | 00:52 | |
swifterdarrell | kota_: you may be interested in https://review.openstack.org/#/c/191970/1 :) :) | 00:53 |
notmyname | torgomatic: I can't find anything in gerrit for you for oslo.config. was your patch to allow passing in a dict to CONF or loading paste.ini stuff or ...? | 00:53 |
kota_ | swifterdarrell: good morning! | 00:53 |
swifterdarrell | kota_: that was a great catch, btw, in your review! | 00:53 |
kota_ | swifterdarrell: thanks! and 191970 is interesting to me. | 00:54 |
*** zhill has joined #openstack-swift | 00:54 | |
kota_ | awsome *quick* work for that :) | 00:54 |
kota_ | I'm willing to take a time to review it during today ;) | 00:55 |
swifterdarrell | kota_: thanks! | 00:56 |
notmyname | ho: thank you for talking it over and helping me understand. I want to spend some more time thinking on it | 00:56 |
notmyname | unfortunately, i've got to go now | 00:56 |
notmyname | talk to you tomorrow | 00:56 |
ho | thanks! I'm really happy to share my concern for this :-) | 00:56 |
kota_ | swifterdarrell: Thanks for poking me to look at the nice patch and your patch 184189 is really interesting me too :) | 00:56 |
patchbot | kota_: https://review.openstack.org/#/c/184189/ | 00:56 |
ho | notmyaname: have a nice evening! | 00:57 |
ho | kota_: morning! | 01:07 |
kota_ | ho: morning :) | 01:08 |
mattoliverau | kota_: morning | 01:12 |
kota_ | mattoliverau: :) | 01:13 |
*** zhill has quit IRC | 01:34 | |
*** gyee is now known as operator99 | 01:49 | |
*** ahonda has quit IRC | 01:52 | |
*** zhill has joined #openstack-swift | 01:55 | |
*** zhill has quit IRC | 02:00 | |
*** zhill has joined #openstack-swift | 02:01 | |
*** ktsuyuzaki has joined #openstack-swift | 02:01 | |
*** kota_ has quit IRC | 02:03 | |
*** zhill has quit IRC | 02:05 | |
*** jasondotstar has joined #openstack-swift | 02:09 | |
*** jasondotstar has quit IRC | 02:09 | |
*** jasondotstar has joined #openstack-swift | 02:10 | |
*** zhill has joined #openstack-swift | 02:11 | |
*** kota_ has joined #openstack-swift | 02:14 | |
*** ChanServ sets mode: +v kota_ | 02:14 | |
*** ktsuyuzaki has quit IRC | 02:16 | |
openstackgerrit | Tim Burke proposed openstack/python-swiftclient: Add bulkdelete command https://review.openstack.org/190887 | 02:16 |
*** ktsuyuzaki has joined #openstack-swift | 02:17 | |
*** kota_ has quit IRC | 02:19 | |
*** kota_ has joined #openstack-swift | 02:19 | |
*** ChanServ sets mode: +v kota_ | 02:19 | |
*** ktsuyuzaki has quit IRC | 02:21 | |
*** ktsuyuzaki has joined #openstack-swift | 02:22 | |
*** kota_ has quit IRC | 02:23 | |
*** jasondotstar has quit IRC | 02:24 | |
*** kota_ has joined #openstack-swift | 02:24 | |
*** ChanServ sets mode: +v kota_ | 02:24 | |
*** zhill has quit IRC | 02:24 | |
*** ktsuyuzaki has quit IRC | 02:26 | |
*** jrichli has quit IRC | 02:31 | |
*** kota_ has quit IRC | 02:32 | |
*** haomaiwang has joined #openstack-swift | 02:38 | |
*** thurloat is now known as thurloat_isgone | 02:49 | |
*** mfalatic has quit IRC | 02:52 | |
*** marzif has joined #openstack-swift | 03:09 | |
*** tellesnobrega has quit IRC | 03:22 | |
jith_ | hi all, i have installed swift (SAIO) in one VM.. i have to connect this with another devstack machine.. how to connect the standalone swift with another devstack machine.. should i create swift endpoint using swift vm's ip?? | 03:23 |
*** zaitcev has quit IRC | 03:26 | |
*** kota_ has joined #openstack-swift | 03:57 | |
*** ChanServ sets mode: +v kota_ | 03:57 | |
*** km_ has joined #openstack-swift | 04:02 | |
*** km has quit IRC | 04:02 | |
*** ho_ has joined #openstack-swift | 04:04 | |
*** ho has quit IRC | 04:05 | |
*** kota_ has quit IRC | 04:05 | |
*** marzif has quit IRC | 04:13 | |
*** ppai has joined #openstack-swift | 04:32 | |
*** ho_ has quit IRC | 04:58 | |
*** km_ has quit IRC | 05:00 | |
*** ho has joined #openstack-swift | 05:01 | |
*** SkyRocknRoll has joined #openstack-swift | 05:01 | |
*** km has joined #openstack-swift | 05:02 | |
*** ho has quit IRC | 05:02 | |
*** ho has joined #openstack-swift | 05:07 | |
*** fifieldt has joined #openstack-swift | 05:10 | |
ho | jith_: I don't understand what do you want to use the devstack. devstack as a client or one of a storage node??? | 05:11 |
*** haomaiwang has quit IRC | 05:14 | |
*** Kennan has quit IRC | 05:14 | |
ho | jith_: if you use the devstack as a client, you need to register an endpoint (the ip address, port of saio) in keystone. | 05:14 |
jith_ | ho: thanks for the response... i want to configure devstack setup with swift.. but swift is in a seperate Virual machine.. currently my devstack is running without swift in 192.168.52.11 and my swift (SAIO setup) is running in another VM (192.168.52.66). how i will bind the devstack machine to listen the swift machine | 05:15 |
jith_ | i understand something i have to do with endpoint and proxy-server.conf | 05:16 |
jith_ | ho: thanks a lot... should i configure anything in swift? | 05:17 |
jith_ | for eg http://thornelabs.net/2014/07/16/authenticate-openstack-swift-against-keystone-instead-of-tempauth.html in this they have edited something in proxy-server.conf | 05:18 |
*** Kennan has joined #openstack-swift | 05:20 | |
ho | jith_: usually authtoken and keytoneauth in the pipeline in proxy-server.conf when you use keystone. | 05:23 |
ho | jith_: sorry. I will re-write. wait a minute. | 05:24 |
ho | jith_: when you use keystone as an authentication server authtoken and keystoneauth middleware should be configured in the pipeline (in proxy-server.conf) | 05:25 |
jith_ | ho:sure thanks :) | 05:25 |
jith_ | also i have used stack user in the place of <your-user-name> in saio.. so should i create stack user instead of swift in keystone, or is it enough if i mention in proxy-server.conf in default section as user:stack.. i m sorry if i am wrong.. i m a beginner | 05:29 |
ho | jith_: the user needs to have a role which is admin or SwiftOperator (you defined them in proxy-server.conf as operator_roles). So you need to put the role to the user in keystone. | 05:32 |
ho | jith_: http://docs.openstack.org/kilo/install-guide/install/apt/content/swift-install-controller-node.html | 05:34 |
jith_ | thanks ho: i am bit confused in /etc/swift/proxy-server.conf DEFAULT section.. what user i have to mention? Swift processes run under a separate user and group. the default user is swift. in my case it is running as jith user and jith group. but in keystone i have created the swift user. | 05:39 |
jith_ | so will it do any mismatch or i should create a jith user for swift in keystone? | 05:41 |
ho | jith_: user in default section is for executing the proxy-server process not related to keystone. | 05:51 |
ho | :q | 05:51 |
jith_ | ho: thanks.. i think we have to give keystone user name in [filter:authtoken] | 05:52 |
ho | jith_: yes. in authtoken section you use an user to access keystone and in keystoneauth section you speficy roles for an user to access swift | 05:54 |
jith_ | ho: thanks.. i understand :) | 05:55 |
*** proteusguy has quit IRC | 05:55 | |
ho | jith_: you are welcome :-) | 05:56 |
*** haomaiwa_ has joined #openstack-swift | 05:59 | |
*** proteusguy has joined #openstack-swift | 05:59 | |
jith_ | ho: u r really guiding good.. :) | 06:01 |
*** silor has joined #openstack-swift | 06:16 | |
*** silor1 has joined #openstack-swift | 06:19 | |
*** silor has quit IRC | 06:22 | |
*** ianbrown has quit IRC | 06:39 | |
*** kota_ has joined #openstack-swift | 06:39 | |
*** ChanServ sets mode: +v kota_ | 06:39 | |
*** ronenkat has joined #openstack-swift | 06:41 | |
*** mmcardle has joined #openstack-swift | 06:57 | |
openstackgerrit | Pradeep Kumar Singh proposed openstack/python-swiftclient: SwiftClient object upload beginning with / or "./" https://review.openstack.org/185269 | 06:58 |
*** SkyRocknRoll has quit IRC | 06:59 | |
jith_ | ho: what is workers field in proxy-server.conf? | 07:07 |
*** SkyRocknRoll has joined #openstack-swift | 07:18 | |
*** SkyRocknRoll has quit IRC | 07:18 | |
*** SkyRocknRoll has joined #openstack-swift | 07:18 | |
*** CrackerJackMack has quit IRC | 07:22 | |
*** CrackerJackMack has joined #openstack-swift | 07:33 | |
*** jordanP has joined #openstack-swift | 07:46 | |
*** acoles_away is now known as acoles | 07:48 | |
*** geaaru has joined #openstack-swift | 07:51 | |
*** joeljwright has joined #openstack-swift | 07:53 | |
*** ChanServ sets mode: +v joeljwright | 07:53 | |
openstackgerrit | Hisashi Osanai proposed openstack/swift-specs: Oslo config support in Swift https://review.openstack.org/192094 | 07:57 |
*** a1|away has quit IRC | 07:58 | |
*** AbyssOne has quit IRC | 07:58 | |
ho | jith_: https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L25 | 08:01 |
ho | jith_: there is an explanation for it. | 08:02 |
*** ronenkat_ has joined #openstack-swift | 08:08 | |
*** ronenkat has quit IRC | 08:11 | |
*** chlong has quit IRC | 08:18 | |
openstackgerrit | Kota Tsuyuzaki proposed openstack/swift: Use just IP on get_more_nodes, too https://review.openstack.org/192548 | 08:30 |
*** ronenkat__ has joined #openstack-swift | 08:30 | |
*** ronenkat_ has quit IRC | 08:34 | |
*** km has quit IRC | 08:38 | |
jith_ | ho: thanks | 08:56 |
jith_ | ho: for configuring SAIO in devstack... should i modify anything in local.conf? | 09:02 |
*** kei_yama has quit IRC | 09:02 | |
jith_ | because usually in devstack we use SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 | 09:03 |
jith_ | SWIFT_REPLICAS=3 | 09:03 |
jith_ | SWIFT_DATA_DIR=/mnt/data/swift | 09:03 |
ho | jith_: I think SAIO and swift in devstack are different :) It looks more changes than my env. I don't think you should change more. detailed: https://github.com/openstack-dev/devstack/blob/master/lib/swift | 09:25 |
openstackgerrit | Hisashi Osanai proposed openstack/swift: WIP: Enable Role-based access control using oslo.policy in Swift https://review.openstack.org/149930 | 09:25 |
jith_ | ho: thanks ho.. so i cant configure it? | 09:27 |
ho | jith_: you build swift in devstack right? i think you can configure it. (from terminology point of view it's not called saio) | 09:34 |
ho | jith_: i will leave now. see you tomorrow! | 09:35 |
*** ho has quit IRC | 09:36 | |
jith_ | ho: i just enabled swift services in devstack.. and created keystone endpoints for SAIO.. then trying to up devstack now | 09:36 |
jith_ | ho: ok sure.. :) | 09:36 |
openstackgerrit | Ondrej Novy proposed openstack/swift: Time synchronization check in recon. https://review.openstack.org/192562 | 09:40 |
*** haomaiwa_ has quit IRC | 09:41 | |
*** ianbrown has joined #openstack-swift | 10:07 | |
*** ianbrown has quit IRC | 10:19 | |
*** cebruns has quit IRC | 10:19 | |
*** cebruns has joined #openstack-swift | 10:21 | |
*** ianbrown has joined #openstack-swift | 10:26 | |
*** haomaiwang has joined #openstack-swift | 10:28 | |
*** kota_ has quit IRC | 10:34 | |
*** jasondotstar has joined #openstack-swift | 10:41 | |
*** dmorita has quit IRC | 10:46 | |
*** aix has joined #openstack-swift | 10:49 | |
*** silor1 has quit IRC | 11:03 | |
*** jasondotstar has quit IRC | 11:06 | |
*** thurloat_isgone is now known as thurloat | 11:14 | |
*** ianbrown has quit IRC | 11:22 | |
*** tellesnobrega has joined #openstack-swift | 11:33 | |
*** tellesnobrega has quit IRC | 11:40 | |
*** tellesnobrega has joined #openstack-swift | 11:43 | |
*** mmcardle has quit IRC | 11:45 | |
*** ppai has quit IRC | 12:02 | |
*** ppai has joined #openstack-swift | 12:16 | |
*** ppai has quit IRC | 12:23 | |
*** ppai has joined #openstack-swift | 12:35 | |
*** NM has joined #openstack-swift | 12:40 | |
*** geaaru has quit IRC | 12:41 | |
*** geaaru has joined #openstack-swift | 12:42 | |
*** mmcardle has joined #openstack-swift | 12:42 | |
*** amoturi has joined #openstack-swift | 12:50 | |
*** petertr7_away is now known as petertr7 | 12:53 | |
*** ppai has quit IRC | 13:10 | |
*** vinsh has joined #openstack-swift | 13:11 | |
*** jamielennox is now known as jamielennox|away | 13:13 | |
*** jamielennox|away is now known as jamielennox | 13:21 | |
*** SkyRocknRoll has quit IRC | 13:30 | |
*** NM1 has joined #openstack-swift | 13:30 | |
*** NM has quit IRC | 13:33 | |
*** jamielennox is now known as jamielennox|away | 13:33 | |
*** lastops has joined #openstack-swift | 13:37 | |
*** jamielennox|away is now known as jamielennox | 13:42 | |
*** pgbridge has joined #openstack-swift | 13:43 | |
*** acampbell has joined #openstack-swift | 13:45 | |
*** wbhuber has joined #openstack-swift | 13:58 | |
*** kbee has joined #openstack-swift | 14:00 | |
*** pgbridge has quit IRC | 14:04 | |
*** blmartin has joined #openstack-swift | 14:12 | |
*** kbee has quit IRC | 14:20 | |
*** kbee has joined #openstack-swift | 14:21 | |
*** jrichli has joined #openstack-swift | 14:26 | |
*** kbee has quit IRC | 14:27 | |
*** ronenkat__ has quit IRC | 14:34 | |
*** acampbel11 has joined #openstack-swift | 14:34 | |
*** acampbel11 has quit IRC | 14:38 | |
*** acampbell has quit IRC | 14:38 | |
*** acampbel11 has joined #openstack-swift | 14:38 | |
*** jrichli has quit IRC | 14:41 | |
*** jrichli has joined #openstack-swift | 14:47 | |
*** cdelatte has joined #openstack-swift | 14:47 | |
*** minwoob has joined #openstack-swift | 14:49 | |
*** jrichli has quit IRC | 14:49 | |
*** NM1 has quit IRC | 14:50 | |
*** jrichli has joined #openstack-swift | 14:50 | |
*** pgbridge has joined #openstack-swift | 14:51 | |
*** blmartin_ has joined #openstack-swift | 14:52 | |
*** silor has joined #openstack-swift | 14:52 | |
*** wbhuber has quit IRC | 14:53 | |
*** jrichli has quit IRC | 14:54 | |
*** blmartin has quit IRC | 14:55 | |
*** jrichli has joined #openstack-swift | 14:56 | |
*** wbhuber has joined #openstack-swift | 14:59 | |
*** wbhuber_ has joined #openstack-swift | 14:59 | |
*** zaitcev has joined #openstack-swift | 15:03 | |
*** wbhuber has quit IRC | 15:03 | |
*** ChanServ sets mode: +v zaitcev | 15:03 | |
*** openstackgerrit has quit IRC | 15:05 | |
*** openstackgerrit has joined #openstack-swift | 15:05 | |
*** ajiang has left #openstack-swift | 15:23 | |
*** jamielennox is now known as jamielennox|away | 15:38 | |
notmyname | good morning | 15:41 |
*** janonymous_ has joined #openstack-swift | 15:42 | |
*** jamielennox|away is now known as jamielennox | 15:47 | |
*** petertr7 is now known as petertr7_away | 15:48 | |
pgbridge | good morning | 15:49 |
*** lcurtis has joined #openstack-swift | 15:49 | |
minwoob | Good morning. | 15:49 |
charz | good morning | 15:50 |
*** jamielennox is now known as jamielennox|away | 15:58 | |
*** jordanP has quit IRC | 15:59 | |
janonymous_ | good morning | 16:05 |
*** jamielennox|away is now known as jamielennox | 16:06 | |
*** kbee has joined #openstack-swift | 16:06 | |
*** jlhinson has joined #openstack-swift | 16:07 | |
*** nadeem has joined #openstack-swift | 16:08 | |
*** nadeem has quit IRC | 16:08 | |
minwoob | Does anyone know a good way to verify whether a fragment that needs to be reconstructed is already located on one of a list of nodes? | 16:09 |
minwoob | Rather, from a list of responses containing fragments from those nodes. | 16:10 |
*** ajiang has joined #openstack-swift | 16:13 | |
minwoob | For clarification, I have hit a blocker in: https://bugs.launchpad.net/swift/+bug/1452553 | 16:13 |
openstack | Launchpad bug 1452553 in OpenStack Object Storage (swift) "don't rebuild existing fragments" [Undecided,New] - Assigned to Minwoo Bae (minwoob) | 16:13 |
notmyname | I get so many emails about "would like to know more about Enterprise Mobility? We can help!" | 16:14 |
notmyname | I don't even know what enterprise mobility means | 16:14 |
notmyname | much less why it's capitalized | 16:14 |
notmyname | or why I need help with it | 16:15 |
notmyname | at least it makes for an easy email filter | 16:15 |
pgbridge | that could mean a lot of different things. mobility of what exactly? | 16:19 |
notmyname | enterprise, obviously! | 16:21 |
notmyname | maybe something like detaching the saucer section? http://vignette3.wikia.nocookie.net/memoryalpha/images/1/1b/USS_Enterprise-D_saucer_separation.jpg/revision/latest?cb=20120205044747&path-prefix=en | 16:22 |
*** amoturi has quit IRC | 16:22 | |
pgbridge | lol maybe | 16:22 |
pgbridge | that's definitely something i could see needing help with | 16:22 |
*** janonymous__ has joined #openstack-swift | 16:24 | |
*** janonymous_ has quit IRC | 16:26 | |
minwoob | clayg: If you could revisit the bug mentioned in my inquiry about ~20 min ago and let me know, that would be helpful. Thanks. | 16:27 |
*** kbee has quit IRC | 16:30 | |
*** kbee has joined #openstack-swift | 16:30 | |
*** openstackgerrit has quit IRC | 16:33 | |
*** openstackgerrit has joined #openstack-swift | 16:34 | |
*** jamielennox is now known as jamielennox|away | 16:35 | |
*** zhill has joined #openstack-swift | 16:38 | |
*** fthiagogv has joined #openstack-swift | 16:38 | |
*** acampbell111 has joined #openstack-swift | 16:43 | |
*** gyee_ has joined #openstack-swift | 16:43 | |
*** fifieldt_ has joined #openstack-swift | 16:44 | |
*** acampbel11 has quit IRC | 16:45 | |
*** fifieldt has quit IRC | 16:45 | |
*** operator99 has quit IRC | 16:45 | |
*** ryshah has joined #openstack-swift | 16:46 | |
*** a| has joined #openstack-swift | 16:46 | |
*** a| has quit IRC | 16:46 | |
openstackgerrit | Tim Burke proposed openstack/python-swiftclient: Add bulkdelete command https://review.openstack.org/190887 | 16:47 |
*** logan2 has joined #openstack-swift | 16:47 | |
ryshah | Hi - Does Juno Swift have this vulnerability? www.tenable.com/security/tns-2015-05 | 16:49 |
*** jamielennox|away is now known as jamielennox | 16:49 | |
ryshah | Juno installs 3.6 Sqlite3 and Sqlite3 3.8 fixes the vulnerability... The issue is when user input is not validated.... | 16:50 |
*** gyee has joined #openstack-swift | 16:52 | |
*** mfalatic has joined #openstack-swift | 16:54 | |
*** mmcardle has quit IRC | 16:54 | |
notmyname | ryshah: for the record, it would have been MUCH better had you asked this question by filing a bug on launchpad and marking it as a security bug. that way, if it is an issue, it would only be shared with the security bug teams and a patch could be developed | 16:57 |
notmyname | as it is, I'm looking at the CVE now https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3415 | 16:57 |
ryshah | notmyname: I can definitely do that if you recommend... I was not sure if the issue was raised by someone before | 17:02 |
notmyname | no need at this point | 17:02 |
notmyname | so looking at the various links there, it's really hard to tell if it impacts swift or not | 17:03 |
*** thurloat is now known as thurloat_isgone | 17:03 | |
notmyname | on the one hand, I'd say no because users don't ever directly talk to sqlite DBs in swift. user data is put into those DBs, but that is properly escaped | 17:03 |
*** haomaiw__ has joined #openstack-swift | 17:04 | |
*** haomaiwang has quit IRC | 17:04 | |
notmyname | on the other, I don't know | 17:04 |
ryshah | That was my initial thought too.. However, looking at code it seemed to me that at some places swift use container/account names directly in queries | 17:05 |
notmyname | seems that the overview talks about a CHECK clause, which swift doesn't use | 17:05 |
*** kbee has quit IRC | 17:05 | |
ryshah | notmyname: Do you think this needs to be looked further by security team? In that caseI can file a launchpad bug | 17:06 |
*** NM has joined #openstack-swift | 17:06 | |
*** mfalatic has quit IRC | 17:07 | |
*** petertr7_away is now known as petertr7 | 17:10 | |
*** ronenkat has joined #openstack-swift | 17:11 | |
*** jamielennox is now known as jamielennox|away | 17:13 | |
*** mfalatic has joined #openstack-swift | 17:19 | |
notmyname | ryshah: no not at this point. the CVE specifically talks about the CHECK clause, so I think we're ok | 17:22 |
ryshah | notmyname: OK - thank you! | 17:25 |
*** ryshah_ has joined #openstack-swift | 17:26 | |
*** thurloat_isgone is now known as thurloat | 17:26 | |
*** ryshah has quit IRC | 17:29 | |
*** acoles is now known as acoles_away | 17:34 | |
*** breitz has joined #openstack-swift | 17:42 | |
*** aix has quit IRC | 17:42 | |
notmyname | jrichli: acoles_away: so I went to the vault meetup last night | 17:45 |
notmyname | it was interesting. it's a pretty cool system they have with some very nice features | 17:48 |
notmyname | for example, you can have dynamic secrets that expire | 17:48 |
notmyname | so if you have an application talking to a postgres DB, the application can ask vault for the creds, vault will generate unique credentials that work only for a certain amount of time, give those back to the app, then the app talks to the DB like normal | 17:49 |
*** petertr7 is now known as petertr7_away | 17:49 | |
notmyname | full audit logging and integration with various different systems and auth schemes | 17:49 |
notmyname | however, definitely not "enterprise" (which isn't a bad thing) ;-) | 17:50 |
notmyname | eg they dont' currently have any integration with HSMs | 17:50 |
notmyname | although the guy admitted that they probably would be forced to do that at some point | 17:50 |
notmyname | the scale of thigns they were talking about were in line with what I've heard from HSMs, but certainly way below a load that swift could generate | 17:52 |
*** nadeem has joined #openstack-swift | 17:53 | |
*** prometheanfire has joined #openstack-swift | 17:53 | |
notmyname | eg vault might be good at storing a few tens of thousands of secrets and serving them up from storage at 1000/sec. | 17:53 |
prometheanfire | so, how is swift's federation support (between federated keystones)? | 17:54 |
prometheanfire | notmyname: hi | 17:54 |
notmyname | however, that's not any different (magnitude wise) from barbican or HSMs. so we've got to work around that kind of thing anyway (and there are ideas on that too) | 17:54 |
notmyname | prometheanfire: I'm not sure what that question means | 17:54 |
*** petertr7_away is now known as petertr7 | 17:55 | |
swifterdarrell | notmyname: CHECK might have just been an example of where comparison operator parsing could cause trouble? https://www.sqlite.org/src/info/02e3c88fbf6abdcf | 17:56 |
notmyname | swifterdarrell: yeah, I'm not sure. it's not the easiest report to parse | 17:56 |
prometheanfire | using federated keystone, can one region on one keystone replicate to one region on another keystone? | 17:57 |
notmyname | prometheanfire: all keystone is doing is associating a user identity with a storage endpoint (or multiple endpoints). any federation/regionality of keystone and swift is independent | 17:58 |
notmyname | prometheanfire: right? | 17:58 |
prometheanfire | right | 17:59 |
prometheanfire | is that enough to replication between federated 'regions'? | 17:59 |
prometheanfire | deployments might be a better word | 17:59 |
notmyname | isn't keystone federation orthogonal to swift deployments? | 18:00 |
prometheanfire | I think so? | 18:00 |
prometheanfire | not sure | 18:00 |
prometheanfire | which is why I ask :D | 18:00 |
notmyname | if you have 2 keystone deployments that federate auth, they can point to "local" swift clusters or a common swift cluster | 18:00 |
clayg | minwoob: looks like bug #1452553 is assigned to you - is there a gerrit review associated with the bug? or still just the attached patchfile? | 18:01 |
openstack | bug 1452553 in OpenStack Object Storage (swift) "don't rebuild existing fragments" [Undecided,New] https://launchpad.net/bugs/1452553 - Assigned to Minwoo Bae (minwoob) | 18:01 |
notmyname | if you have two different swift clusters, then the only way to "move" data between them is with container sync | 18:02 |
prometheanfire | right | 18:02 |
notmyname | prometheanfire: there isn't anything we've done in swift with keystone federation. I'm not sure if that matters or not. | 18:02 |
prometheanfire | ya, will likely have to test | 18:03 |
openstackgerrit | Jiri Suchomel proposed openstack/swift: Let swift-object-info print information about files in given directory, if directory is provided instead of data file together with --recursive option. https://review.openstack.org/189258 | 18:05 |
*** geaaru has quit IRC | 18:11 | |
*** amoturi has joined #openstack-swift | 18:14 | |
notmyname | reminder to all that there's a swift team meeting today at 2100UTC (http://time.unitarium.com/utc/21). agenda is at https://wiki.openstack.org/wiki/Meetings/Swift | 18:21 |
notmyname | and I'd like to spend some time talking about https://review.openstack.org/#/c/192094/ (oslo.config) | 18:22 |
*** acampbell has joined #openstack-swift | 18:25 | |
jrichli | notmyname: thank you for the info about Vault | 18:26 |
jrichli | I will take a closer look | 18:27 |
minwoob | clayg: So I see that the fix for it will need to reside in swift.obj.reconstructor.make_rebuilt_fragment_iter(), but I was wondering if there is a precedent for how to verify that the retrieved fragments do not contain the fragment needing to be reconstructed? | 18:28 |
*** vinsh has quit IRC | 18:29 | |
*** acampbell111 has quit IRC | 18:29 | |
clayg | minwoob: all the info should be in the headers - I think you might have to throw out responses even before you get down into make_rebuilt_fragment_iter | 18:29 |
clayg | what did I do in the patch that was associated with the bug? | 18:29 |
openstackgerrit | Samuel Merritt proposed openstack/swift: Use just IP, not port, when determining partition placement https://review.openstack.org/191970 | 18:32 |
*** acampbel11 has joined #openstack-swift | 18:32 | |
peluse | clayg, when you get a chance please take a peek at patch 191521 | 18:35 |
patchbot | peluse: https://review.openstack.org/#/c/191521/ | 18:35 |
*** acampbell has quit IRC | 18:36 | |
minwoob | clayg: I don't think it was caused by anything you did. I just wanted to consult you on the bug for some clarification since I saw that you had opened it up. | 18:38 |
minwoob | clayg: Thank you. | 18:38 |
clayg | minwoob: yeah I opened it - and I also attached a .patch - did you see the .patch? It may have been crap (peluse knows all about my crap patches) - but if you haven't seen it you should go track it down and give it a once over before you get to far down in the weeds | 18:39 |
peluse | heh | 18:39 |
peluse | minwoob, what patch are your working on (patch num or bug num)? I have something I've started on GET error handling in conjuntion with some pyeclib updates coming soon - want to make sure there isn't too much overlap here | 18:40 |
minwoob | clayg: Ah, thanks for pointing that out. | 18:41 |
minwoob | peluse: It's for this one: | 18:41 |
minwoob | peluse: https://bugs.launchpad.net/swift/+bug/1452553 | 18:41 |
openstack | Launchpad bug 1452553 in OpenStack Object Storage (swift) "don't rebuild existing fragments" [Undecided,New] - Assigned to Minwoo Bae (minwoob) | 18:41 |
peluse | minwoob, OK there might be a small amount of integration but I don't think anything huge. If you see your scope expanding beyond what's in the bug please sync w/me (no pun intended) | 18:44 |
minwoob | peluse: Haha. | 18:44 |
minwoob | peluse: Okay, got it. | 18:44 |
clayg | peluse: is that like a "psync"? | 18:46 |
peluse | yeah, much better than prevert! | 18:47 |
clayg | so what do I have to do to fix the jerasure thing in liberasure now? | 18:48 |
clayg | Error: Invalid arguments passed to liberasurecode_instance_create | 18:54 |
*** wbhuber_ has quit IRC | 18:55 | |
charz | notmyname: clayg https://bugs.launchpad.net/swift/+bug/1464142 | 18:56 |
openstack | Launchpad bug 1464142 in OpenStack Object Storage (swift) "object-reconstructor ssync_sender and ssync_receiver exception" [Undecided,New] | 18:56 |
notmyname | and https://bugs.launchpad.net/swift/+bug/1466138 | 18:57 |
openstack | Launchpad bug 1466138 in OpenStack Object Storage (swift) "EC reconstructor (ssync_sender) got exceptions while send request to object-server and disk already umount" [Undecided,New] | 18:57 |
notmyname | and https://bugs.launchpad.net/swift/+bug/1452619 | 18:57 |
openstack | Launchpad bug 1452619 in OpenStack Object Storage (swift) "object-reconstructor crash in ssync_sender" [Undecided,Confirmed] | 18:57 |
notmyname | those are the 3 EC bugs i know of right now | 18:57 |
clayg | I installed charz there's a few unrelated requests in there | 18:58 |
clayg | object-reconstructor: 192.168.12.15:6003/d34/608 Exception Broken Pipe <- that's ssync saying the remote end closed it's connection on him unexpectedly (could be 409's int he replicate requests) | 18:59 |
charz | clayg: k, make sense. | 19:00 |
clayg | object-server: 192.168.12.13/d56/2028 Exception invalid literal for int() <- that's the object server saying that ssnc closed it's connection on him unexpectedly (could be... idk... could be interesting) | 19:00 |
clayg | but you can see those are different device/parts - so they're not related requests | 19:00 |
clayg | and in both cases somehow you managed to pull the uninteresting side of the explosion :( | 19:00 |
peluse | FYI the patch I pinged clayg on earlier had the same failure signature as https://bugs.launchpad.net/swift/+bug/1452619 | 19:04 |
openstack | Launchpad bug 1452619 in OpenStack Object Storage (swift) "object-reconstructor crash in ssync_sender" [Undecided,Confirmed] | 19:04 |
charz | clayg: yeah, I think I need to grab more info or log to the bug. will try tmr. | 19:04 |
clayg | peluse: the got disconnected? yeah the 409's can definately cause that - I would have thought charz already had all the known patches/issues applied | 19:05 |
peluse | that would be patch 191521 | 19:05 |
patchbot | peluse: https://review.openstack.org/#/c/191521/ | 19:05 |
peluse | bah, starting a meeting I have to pay attention to | 19:05 |
*** joeljwright has quit IRC | 19:06 | |
*** NM has quit IRC | 19:08 | |
charz | clayg: peluse I applied the patch 191521 for all nodes today. And this bug (https://bugs.launchpad.net/swift/+bug/1464142) is reported two or three days ago. | 19:11 |
openstack | Launchpad bug 1464142 in OpenStack Object Storage (swift) "object-reconstructor ssync_sender and ssync_receiver exception" [Undecided,New] | 19:11 |
patchbot | charz: https://review.openstack.org/#/c/191521/ | 19:11 |
*** fifieldt_ has quit IRC | 19:12 | |
*** NM has joined #openstack-swift | 19:14 | |
*** openstackgerrit has quit IRC | 19:16 | |
*** openstackgerrit has joined #openstack-swift | 19:16 | |
clayg | isn't ldconfig supposed to square my LD_LIBRARY_PATH for me already or something? | 19:19 |
*** prometheanfire has left #openstack-swift | 19:20 | |
peluse | charz, so I'm not sure I follow you- have you seen issues *since* you applied 191521? | 19:23 |
peluse | or you saw issues so then you applied the patch? | 19:23 |
clayg | peluse: i don't think he applied your change - he applied the my version in the .patch - so he may just have been seeing all the issues you already fixed in 191521 | 19:24 |
*** gyee has quit IRC | 19:25 | |
peluse | things never work out that well though :) | 19:25 |
peluse | will be interested to hear though... | 19:26 |
*** nadeem has quit IRC | 19:29 | |
*** fifieldt_ has joined #openstack-swift | 19:30 | |
clayg | NONE OF THIS IS RIGHT | 19:30 |
peluse | do tell! | 19:30 |
*** nadeem has joined #openstack-swift | 19:30 | |
clayg | peluse: pyeclib sucks at installing itself - i really have no f'in idea what it thinks it's doing | 19:31 |
peluse | which version are you using? | 19:32 |
clayg | isn't everyone running 1.0.7? | 19:32 |
peluse | well, wasn't sure if you were off-roading or not | 19:32 |
peluse | I believe tsg said there were isntallation fixes coming in 1.0.8 | 19:32 |
clayg | well that'd be great | 19:33 |
peluse | let me see if I can get an ETA | 19:33 |
peluse | new pyeclib in the next few days.... | 19:35 |
notmyname | peluse: are tsg and kevin the only ones with commit access to pyeclib? | 19:35 |
*** NM has quit IRC | 19:37 | |
peluse | notmyname, no I don't think so - others have contributed including kota I believe | 19:38 |
peluse | maybe more... | 19:38 |
peluse | also tsg mentions that there are indeed installation fixes in 1.0.8 | 19:38 |
notmyname | contributors != commit access | 19:39 |
peluse | oh yeah, no I think just keving and tsg | 19:39 |
*** silor has quit IRC | 19:51 | |
*** nadeem has quit IRC | 19:55 | |
*** joeljwright has joined #openstack-swift | 20:01 | |
*** ChanServ sets mode: +v joeljwright | 20:01 | |
*** lastops has quit IRC | 20:09 | |
*** nadeem has joined #openstack-swift | 20:16 | |
*** thurloat is now known as thurloat_isgone | 20:17 | |
*** amoturi has quit IRC | 20:18 | |
*** NM has joined #openstack-swift | 20:21 | |
*** wbhuber has joined #openstack-swift | 20:24 | |
*** acampbel11 has quit IRC | 20:28 | |
*** wer_ has quit IRC | 20:30 | |
*** wer_ has joined #openstack-swift | 20:35 | |
*** jrichli has quit IRC | 20:40 | |
*** torgomatic has quit IRC | 20:46 | |
*** gyee has joined #openstack-swift | 20:46 | |
notmyname | tdasilva: any reason you did a +1 instead of a +2 on https://review.openstack.org/#/c/191970/ ? | 20:49 |
*** torgomatic has joined #openstack-swift | 20:50 | |
*** ChanServ sets mode: +v torgomatic | 20:50 | |
*** ho has joined #openstack-swift | 20:50 | |
tdasilva | notmyname: that part of the code is pretty new to me, so I did review it but i'd prefer someone with more experience on that code giving their full blessing | 20:50 |
notmyname | tdasilva: ok :-) | 20:50 |
tdasilva | i'm still pretty careful with the whole +2 thing ;) | 20:51 |
zaitcev | It was a problem to me but I resolved it differently | 20:51 |
*** acoles_away is now known as acoles | 20:52 | |
tdasilva | zaitcev: now i'm curious ??? | 20:52 |
zaitcev | I figured that the right model is "the buck stops here". As a core, I have the full power and full responsibility. So if I'm not familiar with the area, I have to study it. | 20:52 |
zaitcev | Then, +1 goes only if I have objections. If I feel that my competence is lacking, I abstain. Sometimes do a comment with +0 | 20:53 |
ho | good morning! | 20:54 |
notmyname | hello ho | 20:54 |
ho | notmyname: hello! | 20:55 |
zaitcev | In kernel it happened all the time, except not formalized. Sometimes the fallback is to prove to yourself that this patch does not damage known use cases, and if it works or not, oh well, it's still a +2 as safe. So kinda degrade along the other axis than +x. | 20:55 |
zaitcev | Don't we have a meeting in 5 minutes? New time? | 20:55 |
notmyname | yup | 20:55 |
tdasilva | zaitcev: good insights, thx | 20:56 |
*** kota_ has joined #openstack-swift | 20:56 | |
*** ChanServ sets mode: +v kota_ | 20:56 | |
kota_ | Good morning! | 20:57 |
notmyname | hello kota_ | 20:57 |
ho | kota_: morning! | 20:57 |
mattoliverau | morning | 20:57 |
notmyname | hi mattoliverau | 20:58 |
joeljwright | morning :) | 20:58 |
zaitcev | tdasilva: you can/should still drop -1 on anything you don't like, even spelling fixes | 20:58 |
notmyname | everybody is either waking up or staying up :-) | 20:58 |
*** delattec has joined #openstack-swift | 20:59 | |
*** delatte has joined #openstack-swift | 20:59 | |
*** jrichli has joined #openstack-swift | 20:59 | |
peluse | or half asleep in the middle of the day | 20:59 |
notmyname | meeting time in #openstack-meeting | 20:59 |
kota_ | joeljwright: hi and congrats for swiftclient-core! | 20:59 |
notmyname | looks like we need to wait for them to wrap up in there | 21:00 |
joeljwright | thanks kota_ | 21:00 |
zaitcev | joeljwright: yeah, thanks for coming onboard, I really dropped the ball on reading those client fixes recently. | 21:00 |
*** cdelatte has quit IRC | 21:00 | |
joeljwright | zaitcev: well I shall be here reminding people now :) | 21:01 |
*** gyee has quit IRC | 21:03 | |
*** barker has joined #openstack-swift | 21:03 | |
*** petertr7 is now known as petertr7_away | 21:03 | |
acoles | notmyname: thanks for all that info re vault | 21:03 |
*** proteusguy has quit IRC | 21:09 | |
*** ryshah_ has quit IRC | 21:11 | |
*** wer_ has quit IRC | 21:13 | |
*** haomaiwang has joined #openstack-swift | 21:13 | |
*** haomaiw__ has quit IRC | 21:15 | |
clayg | peluse: reviewed! | 21:17 |
*** haomaiw__ has joined #openstack-swift | 21:21 | |
*** haomaiwang has quit IRC | 21:21 | |
*** openstackgerrit has quit IRC | 21:24 | |
*** openstackgerrit has joined #openstack-swift | 21:24 | |
*** wer_ has joined #openstack-swift | 21:25 | |
acoles | peluse: clayg : bug me if there are ec recon related patches you'd like me to review. i'm a bit distracted but will *try* | 21:29 |
peluse | clayg, thanks :) I debated submitting w/o a test for the obj server change and decided to go ahead since I was running short on time. damn it :) | 21:30 |
peluse | I'll work on it | 21:31 |
clayg | peluse: i'm +1, if you get another +2 ping me and I'll approve with a todo to fix the tests - i agree it's better to get it in | 21:31 |
peluse | yeah, wasn't obvious to me how to tackle it quickly at the time... | 21:34 |
peluse | but I have some time tomorrow to work on it | 21:34 |
*** barker has quit IRC | 21:38 | |
*** fthiagogv has quit IRC | 21:42 | |
*** ianbrown has joined #openstack-swift | 21:53 | |
*** NM has quit IRC | 21:55 | |
notmyname | ugh | 22:01 |
joeljwright | wow, that was intense | 22:01 |
notmyname | tons going on :-) | 22:02 |
kota_ | agreed | 22:03 |
joeljwright | guess I'm going to have my work cut out getting people to review swiftclient patches | 22:03 |
notmyname | :-) | 22:03 |
MooingLemur | I still have some outstanding EC issues that I haven't taken time to dig into, but effectively objects that appear to have quorum aren't getting reconstructed, and there are no exceptions thrown. | 22:03 |
notmyname | MooingLemur: have you filed a bug on it? | 22:03 |
notmyname | we need to collect all the info and then prune duplicates as we find them | 22:04 |
* mattoliverau is off to find some breakfast | 22:04 | |
MooingLemur | not yet, I felt like I didn't really have enough information to offer yet other than it isn't working right. :P | 22:04 |
ho | zaitcev: i have a question about selinux on rhel. does it work only for /srv/node? i was asked the question here (our time). | 22:04 |
kota_ | is as well as matt | 22:04 |
acoles | mattoliverau: yum sounds tempting | 22:04 |
*** kota_ has quit IRC | 22:05 | |
MooingLemur | but I added a few debug lines to the revert code, and it appears to be deleting things as if they'd been reverted every time it encounters one of these reconstructions. | 22:05 |
notmyname | MooingLemur: if you have some tracebacks, that's good to. a repeatable case is even better (eg run this, then do that, ta-da it breaks) | 22:05 |
*** wbhuber has quit IRC | 22:06 | |
MooingLemur | I really wish I could turn up the debug on reconstruction | 22:06 |
MooingLemur | there doesn't seem to be enough logging there. | 22:06 |
joeljwright | wanted to ask - currently seeing test errors on swiftclient patches | 22:06 |
ho | zaitcev: and i couldn't find the code for rhel7. rhel6: https://github.com/redhat-openstack/openstack-selinux/blob/el6/openstack-selinux-swift.fc | 22:06 |
MooingLemur | a successful reconstruction logs nothing that I can see, even with debug logging | 22:06 |
joeljwright | gate-temptest-dsvm-neutron-src-python-swiftclient is failing with tempest.exceptions.BuildErrorException | 22:07 |
joeljwright | Details: {u'code': 500, u'message': u'No valid host was found. There are not enough hosts available.', u'created': u'2015-06-17T21:31:05Z'} | 22:07 |
joeljwright | any ideas? | 22:07 |
*** mfalatic has quit IRC | 22:07 | |
*** mfalatic has joined #openstack-swift | 22:08 | |
notmyname | joeljwright: no, but that sounds like it might be a test-infrastructure error. I don't know | 22:08 |
notmyname | joeljwright: it might help to ask in #openstack-qa | 22:08 |
*** blmartin_ has quit IRC | 22:08 | |
joeljwright | kk, thanks | 22:08 |
zaitcev | ho: Sorry, I don't know a thing about SElinux. I'll have to ask around. | 22:10 |
*** delatte has quit IRC | 22:10 | |
*** delattec has quit IRC | 22:10 | |
*** delattec has joined #openstack-swift | 22:18 | |
*** delatte has joined #openstack-swift | 22:18 | |
*** harlowja has left #openstack-swift | 22:22 | |
ho | zaitcev: thanks! | 22:25 |
*** acoles is now known as acoles_away | 22:25 | |
*** acoles_away is now known as acoles | 22:26 | |
*** acoles is now known as acoles_away | 22:28 | |
*** pgbridge has quit IRC | 22:36 | |
*** jlhinson has quit IRC | 22:37 | |
*** jrichli has quit IRC | 22:37 | |
*** lcurtis has quit IRC | 22:39 | |
*** km has joined #openstack-swift | 22:44 | |
*** jasondotstar has joined #openstack-swift | 22:45 | |
*** minwoob has quit IRC | 22:50 | |
*** joeljwright has quit IRC | 22:54 | |
zaitcev | Guys I have an ops question. Does anyone run a bunch of object-expirers on several proxies or other nodes? | 22:59 |
*** gyee has joined #openstack-swift | 23:01 | |
*** doxavore has joined #openstack-swift | 23:04 | |
notmyname | zaitcev: yeah, I think we have one running on each object server | 23:05 |
zaitcev | notmyname: What, really? One per object server?! | 23:06 |
notmyname | I think | 23:07 |
acorwin | zaitcev: notmyname got his info from me, which is not necessarily 100% reliable, but it looks that way. swifterdarrell might be able to pop in with more authority. | 23:07 |
zaitcev | notmyname: The real question is, do they tend to convoy or not? All they do is rescanning a special account. Will they try to expire all the same things simultaneously? | 23:07 |
swifterdarrell | zaitcev: there was some sharding stuff added upstream and we use that | 23:08 |
*** mfalatic has quit IRC | 23:08 | |
notmyname | zaitcev: isnt' that what the "process" config var is for? so you can have each working on a different modulo | 23:08 |
swifterdarrell | zaitcev: # processes is how many parts to divide the work into, | 23:10 |
swifterdarrell | zaitcev: # process is "zero based", if you want to use 3 processes, you should run processes with process set to 0, 1, and 2 | 23:10 |
zaitcev | notmyname, swifterdarrell: thanks for pointing that out, the code is rather simple to follow about it. if obj_process % self.processes != self.process: | 23:10 |
zaitcev | (even without the comments) | 23:10 |
swifterdarrell | zaitcev: so the answer to your original question was "yes" | 23:11 |
zaitcev | however, I thought about recommending someone "oh just run 4 of them, one per proxy" so they don't need to do an extra failover operation | 23:11 |
zaitcev | they rolled out a HA module with Pacemaker | 23:11 |
zaitcev | And I was "WTF guys, you never do that in Swift", but then thoght "maybe they know something" | 23:12 |
zaitcev | but in that case, you can't run this "process" thing or else 1/4th remains unexpired and proxy goes down | 23:12 |
swifterdarrell | zaitcev: I mean, you just need one object-expirer proc with each "process" value. Making that HA is a separate problem, right? | 23:13 |
zaitcev | Can I just tell them do do interval = I0 + proxy_number * prime_number | 23:13 |
zaitcev | that'll deconvoy them hopefuly | 23:13 |
swifterdarrell | zaitcev: kind of like making a 2nd object-expirer (no process stuff) failover for a main one is also separate problem from having main one run | 23:13 |
swifterdarrell | zaitcev: AFAIK, swift is agnostic re HA for that kind of backend daemon | 23:14 |
zaitcev | well sure | 23:14 |
swifterdarrell | zaitcev: or perhaps "indifferent" vs. agnostic | 23:14 |
redbo | I'm not super happy with expiring objects. The server that has the current expiring objects container on just gets hammered. | 23:15 |
swifterdarrell | zaitcev: you want to shard swift-object-expirer for performance; that just makes you have to HA more processes | 23:15 |
zaitcev | swifterdarrell: indeed. | 23:15 |
swifterdarrell | zaitcev: for an eventually-consistent store, it's not like you need really fine-grained failover for object expiry; the backed daemons do the right thing before the objects are actually reaped | 23:16 |
redbo | so we have this little ddos that switches servers every hour | 23:16 |
swifterdarrell | redbo: interesting... | 23:17 |
mattoliverau | redbo: I'm assuming the expiring objects container's list order isn't important, so there could be some simple sharding we can do there. Maybe I'll have a play with that later :) | 23:19 |
redbo | I kind of wish expired objects were just dropped from container listings the way tombstones are, and then the actual .data files were cleaned up by the auditor or something. | 23:19 |
mattoliverau | interesting idea | 23:20 |
redbo | or something, I haven't actually tried to write it. But quit relying on containers to house them. | 23:21 |
clayg | redbo: the object auditor could also write an aysnc pending for the delete's | 23:21 |
redbo | yeah but I'd like to get them out of container listings faster than audit scale time | 23:22 |
*** nadeem has quit IRC | 23:24 | |
*** kei_yama has joined #openstack-swift | 23:30 | |
notmyname | cschwede: chmouel: do you know cyril roelandt? or what his IRC nick is? | 23:36 |
*** chlong has joined #openstack-swift | 23:37 | |
*** wer_ has quit IRC | 23:43 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!