Thursday, 2016-05-05

tqtrannotmyname: hi john, this is thai. we met briefly at the summit. im working on converting the swift test cases into a tempest plugin. seems like we either have to rename the current /test to something like /swift_tests  or move it under /swift/test00:01
notmynametqtran: oh? that's interesting. why?00:01
notmynametqtran: (I'm not necessarily opposed. but why won't it work otherwise?)00:02
tqtranin setup.cfg, under packages we have the swift folder, we need to also add the test folder00:02
*** sorrison_laptop has quit IRC00:02
tqtrannow when you install this into tempest, it install two packages, swift and test00:02
notmynameunder [files]\npackages = ?00:03
tqtrantempest already have a folder call tests, having another test folder there isnt informative00:03
notmynameie it's not an entry point?00:03
tqtranhttps://github.com/openstack/swift/blob/master/setup.cfg#L2600:03
tqtranwe need both an entry point and packages00:04
tqtranright now, its only including /swift/swift00:04
tqtranwe would need to add /swift/test to pacakges00:04
notmynameI remember the same issue from a loooong time ago. IIRC something like if you use ./setup.py develop for a few different projects, you better hope they don't all have a "test" directory (or something like that)00:06
tqtranyes, basically00:06
tqtranit has a really high chance of collision00:07
tqtranthere are basically two ways to package it, neutron and manila does it differently. let me link the example00:07
*** sorrison_laptop has joined #openstack-swift00:08
tqtranhttps://github.com/openstack/neutron/blob/master/setup.cfg#L2300:08
tqtranhttps://github.com/openstack/neutron/tree/master/neutron/tests00:08
openstackgerritSamuel Merritt proposed openstack/swift: Remove unneeded setting of SO_REUSEADDR.  https://review.openstack.org/31279100:08
tqtranin this case, the test folder is under neutron, so we're ok00:08
tqtranhttps://github.com/openstack/manila/blob/master/setup.cfg#L2600:08
tqtranhttps://github.com/openstack/manila/tree/master/manila_tempest_tests00:08
tqtranin this case, manila has a different folder specifically for tempest00:08
notmynameso after talking to exactly zero other people about this, my gut reaction is to s/test/swift_tests/ and add that00:09
tqtranright, that would be my recommendation too00:10
tqtranbut this is a pretty big chance, so maybe its worth bringing up at the weekly discussion?00:10
tqtran*chance-change00:10
notmynameis it a big change to the code, or just a "big" change to the general structure of things?00:11
tqtranbasically all of the import statements would have to change00:12
tqtranimport test --> import swift_test00:12
tqtranand the ordering might have to change to keep pep8 happy00:12
notmyname14 matches00:12
*** ukaynar has quit IRC00:13
notmynamenah, we don't do the flake8 import linters00:13
timburke...for precicely this sort of reason, i believe :)00:13
tqtrani found way more than 14 matches00:14
notmynameah yes. "from test." has 116 matches00:14
tqtran:) there we go, i was going through them just now00:14
notmynameso you're saying that the current way we have it won't work and somethign has to change. either way, it seems to be equally "big". initially I'd prefer the swift_tests structure instead of rehoming the tests directory00:15
tqtranright, either way its going to be big00:15
notmyname"big" ;-)00:15
tqtranbecause moving it under /swift/swift will also require redoing the imports00:16
notmynameof course, the alternative is to just not do a tempest plugin at all. which means we can't have our tests that we manage validating things that claim to be "swift" or things that need to be tested against swift00:16
notmynameI think the tempest plugin is a good thing, so working under that assumption...00:17
notmynametqtran: here's what I'd suggest. first try to do a patch that renames the directories and changes the import. see how big it is. if it's a cosmetic change and everything still seems to work, then let's discuss the patch itself in gerrit00:18
notmynamehowever, if it seems more impactful than that, let's raise it at next wednesday's meeting. still would be good to have a baseline from which to talk about it00:18
tqtransounds like a plan, that is a good starting point00:18
notmynametqtran: in fact, a really good idea would be to copy/paste this conversation and write down some of your thoughts on it and put a link to that record on https://wiki.openstack.org/wiki/Swift/ideas00:19
tqtranlet me experiment with it a another day or so, i dont want to change it and then find an alternative solution or not have it work properly in tempest00:19
*** gyee has quit IRC00:20
tqtrangoing to head out for a bit, thanks for the talk. i'll jot down the ideas and put up a patch tomorrow. have a good one everyone00:21
*** garthb_ has joined #openstack-swift00:23
*** garthb_ has quit IRC00:27
*** garthb has quit IRC00:27
*** sorrison_laptop has quit IRC00:28
*** rickyrem has joined #openstack-swift00:29
*** lyrrad has quit IRC00:39
*** amit213 has quit IRC00:42
notmynameok, new plan (I think). I'm not going to copy all the open spec reviews into separate wiki pages. that sounds terribly tedious. instead, I can just land them all! (or most of them, at least)00:43
*** arch-nemesis has quit IRC00:46
*** suyash has quit IRC00:49
*** esker has joined #openstack-swift00:52
mattoliveraunotmyname: also, those specs that are important to a person I'm sure have a copy of it (like I do).00:54
*** esker has quit IRC00:57
*** sorrison_laptop has joined #openstack-swift01:03
mahaticgood morning01:03
*** rickyrem has quit IRC01:05
*** Jeffrey4l has joined #openstack-swift01:07
mattoliveraumahatic: morning01:09
*** klrmn has quit IRC01:12
*** ozialien10 has quit IRC01:12
*** amit213 has joined #openstack-swift01:13
*** amit213 has quit IRC01:16
*** esker has joined #openstack-swift01:28
*** esker has quit IRC01:33
*** klamath has quit IRC02:01
*** klamath has joined #openstack-swift02:01
*** klamath has quit IRC02:02
*** klamath has joined #openstack-swift02:03
*** esker has joined #openstack-swift02:04
*** esker has quit IRC02:09
*** tqtran has quit IRC02:19
*** ukaynar has joined #openstack-swift02:21
*** sorrison_laptop has quit IRC02:25
*** dmorita has quit IRC02:32
*** esker has joined #openstack-swift02:40
*** esker has quit IRC02:44
*** _JZ_ has joined #openstack-swift02:47
jrichliacoles: good plan.  oh, and btw, I am running out of the Loch Fyne that I got in Bristol :-(02:47
mattoliveraujrichli: well I guess it's time to head back there then ;)02:52
jrichlimattoliverau: sounds like a plan!  I will have some more sticky toffee pudding while I am at it!02:52
*** klrmn has joined #openstack-swift02:53
*** cdelatte has quit IRC03:03
*** Jeffrey4l has quit IRC03:05
*** Jeffrey4l has joined #openstack-swift03:05
*** esker has joined #openstack-swift03:15
*** SkyRocknRoll has joined #openstack-swift03:17
*** natarej_ has joined #openstack-swift03:18
*** esker has quit IRC03:20
*** garthb has joined #openstack-swift03:20
*** natarej__ has quit IRC03:21
*** nadeem has joined #openstack-swift03:39
openstackgerritMerged openstack/swift-specs: Add containeralias spec  https://review.openstack.org/15552403:44
openstackgerritMerged openstack/swift-specs: Swift Request tagging for detailed logging/tracing  https://review.openstack.org/28792203:44
openstackgerritMerged openstack/swift-specs: tempurls with a prefix-based scope  https://review.openstack.org/19960703:44
openstackgerritMerged openstack/swift-specs: Updating spec to reflect a few changes.  https://review.openstack.org/24718503:45
openstackgerritMerged openstack/swift-specs: Changing Policies spec  https://review.openstack.org/16876103:45
openstackgerritMerged openstack/swift-specs: Swift tiering specification  https://review.openstack.org/15133503:46
openstackgerritMerged openstack/swift-specs: Add questions section into global_ec_cluster  https://review.openstack.org/22443903:47
openstackgerritMerged openstack/swift-specs: formpost should allow subprefix-based signature  https://review.openstack.org/22505903:47
openstackgerritMerged openstack/swift-specs: PACO single-process spec.  https://review.openstack.org/21011703:47
openstackgerritJohn Dickinson proposed openstack/swift-specs: Killing specs  https://review.openstack.org/31277803:49
openstackgerritMerged openstack/swift-specs: Large containers (Sharding) - Pivot Ranges.  https://review.openstack.org/21873803:49
*** esker has joined #openstack-swift03:51
openstackgerritMerged openstack/swift-specs: Killing specs  https://review.openstack.org/31277803:55
*** esker has quit IRC03:57
openstackgerritJohn Dickinson proposed openstack/swift-specs: because spelng is hard  https://review.openstack.org/31281903:57
*** daemontool has quit IRC03:57
*** daemontool has joined #openstack-swift03:58
notmynamethere are two more open swift-specs patches that I cannot land because they are marked WIP: https://review.openstack.org/#/q/project:openstack/swift-specs+status:open03:58
notmynameone owned by acoles_ and the other owned by hrou03:59
notmynameplease drop your WIP03:59
*** sorrison_laptop has joined #openstack-swift04:01
openstackgerritMerged openstack/swift-specs: because spelng is hard  https://review.openstack.org/31281904:02
*** klrmn has quit IRC04:09
*** klrmn has joined #openstack-swift04:10
*** asettle has quit IRC04:13
jrichliI'll tell hrou04:26
*** esker has joined #openstack-swift04:27
* jrichli is going to sleep now04:30
*** esker has quit IRC04:32
*** dikonoor has joined #openstack-swift04:34
*** klrmn has quit IRC04:35
*** dikonoor has quit IRC04:39
*** dikonoor has joined #openstack-swift04:40
*** dikonoo has joined #openstack-swift04:41
*** dikonoo has quit IRC04:41
*** sorrison_laptop has quit IRC05:03
*** esker has joined #openstack-swift05:03
*** esker has quit IRC05:08
*** _JZ_ has quit IRC05:26
*** dukhlov has joined #openstack-swift05:27
*** ukaynar has quit IRC05:34
notmynameredbo: I added the slab file thing and memoizing get_info calls to https://wiki.openstack.org/wiki/Swift/ideas05:45
*** bigdogstl has joined #openstack-swift05:51
*** bigdogstl has quit IRC05:56
*** dukhlov has quit IRC06:01
*** sorrison_laptop has joined #openstack-swift06:02
*** openstackgerrit has quit IRC06:03
*** openstackgerrit has joined #openstack-swift06:03
*** dukhlov has joined #openstack-swift06:06
*** mingdang1 has joined #openstack-swift06:10
*** garthb has quit IRC06:12
*** dukhlov has quit IRC06:14
*** asettle has joined #openstack-swift06:18
*** blair has joined #openstack-swift06:18
*** blair has quit IRC06:22
*** nadeem has quit IRC06:34
*** jmccarthy has joined #openstack-swift06:37
*** tesseract has joined #openstack-swift06:44
*** tesseract is now known as Guest2128806:45
*** natarej_ has quit IRC06:48
*** nadeem has joined #openstack-swift06:52
*** blair has joined #openstack-swift06:53
*** sorrison_laptop has quit IRC06:54
*** blair has quit IRC06:58
*** nadeem has quit IRC07:00
*** mingdang1 has quit IRC07:01
*** ppai has joined #openstack-swift07:10
*** _JZ_ has joined #openstack-swift07:20
*** asettle has quit IRC07:40
*** mvk_ has quit IRC07:44
*** dmk0202 has joined #openstack-swift07:57
*** _JZ_ has quit IRC07:58
*** dmk0202 has quit IRC08:03
*** dmk0202 has joined #openstack-swift08:11
*** jistr has joined #openstack-swift08:34
*** mvk_ has joined #openstack-swift08:39
*** acoles_ is now known as acoles09:05
*** mmcardle has joined #openstack-swift09:06
acolesnotmyname: removed my WIP and nudged workflow so that spec lands09:44
openstackgerritMerged openstack/swift-specs: Updateable Object Sysmeta  https://review.openstack.org/10931409:47
*** naseer036 has joined #openstack-swift10:02
naseer036 /me waves hello10:08
*** yoyo has joined #openstack-swift10:12
*** yoyo has quit IRC10:13
*** Jeffrey4l has quit IRC10:15
*** Jeffrey4l has joined #openstack-swift10:17
*** naseer123 has joined #openstack-swift10:20
*** mmcardle has quit IRC10:21
openstackgerritAlistair Coles proposed openstack/swift: crypto - cleanup encrypter error handling  https://review.openstack.org/31266210:22
openstackgerritAlistair Coles proposed openstack/swift: crypto - only set body crypto meta if body is read and encrypted  https://review.openstack.org/30579410:22
openstackgerritAlistair Coles proposed openstack/swift: crypto - cleanup decrypter exception handling  https://review.openstack.org/30480610:22
acolesnaseer036: hi10:26
*** mmcardle has joined #openstack-swift10:34
*** asettle has joined #openstack-swift10:46
*** dukhlov has joined #openstack-swift10:47
*** dukhlov has quit IRC10:49
*** asettle has quit IRC10:51
*** mmcardle has quit IRC10:56
*** mmcardle has joined #openstack-swift10:58
*** NM has joined #openstack-swift11:02
*** links has joined #openstack-swift11:05
*** chenhuayi has joined #openstack-swift11:20
*** DUDI has joined #openstack-swift11:24
*** NM has quit IRC11:38
*** mmcardle has quit IRC11:44
*** ri0 has joined #openstack-swift11:46
*** naseer123 has quit IRC11:47
*** links has quit IRC11:53
*** chenhuayi has quit IRC12:02
*** ekarlso has quit IRC12:06
*** ekarlso has joined #openstack-swift12:06
*** MVenesio has joined #openstack-swift12:06
openstackgerritBrian Ober proposed openstack/swift: Storage Account Object Count Quota Support  https://review.openstack.org/31260312:09
*** mingdang1 has joined #openstack-swift12:20
*** naseer036 has quit IRC12:25
tdasilvagood morning12:42
*** ri0 has quit IRC12:45
openstackgerritRichard Hawkins proposed openstack/swift: go: middleware to allow creating test objects  https://review.openstack.org/31225512:48
openstackgerritRichard Hawkins proposed openstack/swift: go: middleware to allow creating test objects  https://review.openstack.org/31225512:53
*** bapalm has joined #openstack-swift12:54
*** pauloewerton has joined #openstack-swift13:00
*** asettle has joined #openstack-swift13:13
*** esker has joined #openstack-swift13:17
*** dukhlov has joined #openstack-swift13:18
*** esker has quit IRC13:27
*** esker has joined #openstack-swift13:28
hrounotmyname, jrichli - Thanks for the email regarding patch 242804 which was an update to the spec to go the direction talked about post Tokyo (fail POSTs).  I can take off WIP but I'm thinking maybe I should just abandon it as we are/were attempting to take a different direction that would conflict with that update (remains to be seen if we'll go that route though), thoughts ?13:30
patchbothrou: https://review.openstack.org/#/c/242804/ - swift-specs - Symlink spec updates13:30
*** daemontool_ has joined #openstack-swift13:35
*** daemontool has quit IRC13:37
*** ppai has quit IRC13:47
*** openstackgerrit has quit IRC13:47
*** openstackgerrit has joined #openstack-swift13:48
*** ametts has joined #openstack-swift13:55
*** asettle has quit IRC13:57
*** MVenesio has quit IRC14:00
*** garthb has joined #openstack-swift14:00
*** klamath has quit IRC14:02
*** klamath has joined #openstack-swift14:03
*** klamath has joined #openstack-swift14:03
*** links has joined #openstack-swift14:07
*** DUDI has quit IRC14:11
*** SkyRocknRoll has quit IRC14:11
*** _JZ_ has joined #openstack-swift14:14
*** links has quit IRC14:16
*** MVenesio has joined #openstack-swift14:17
*** mingdang1 has quit IRC14:26
openstackgerritAlistair Coles proposed openstack/python-swiftclient: Tighten up testing for sloppy auth version  https://review.openstack.org/31299814:29
*** jistr has quit IRC14:29
*** StevenK has quit IRC14:29
*** dukhlov has quit IRC14:42
*** cdelatte has joined #openstack-swift14:48
*** jistr has joined #openstack-swift14:51
*** arch-nemesis has joined #openstack-swift14:52
*** garthb has quit IRC14:54
*** garthb has joined #openstack-swift14:54
notmynamehrou: no, just remove the WIP. if we land it, we have a record of those thoughts, even if they aren't what the final plan is. if we don't land it, pretty much zero people will be able to dig out the words from gerrit history14:54
*** SkyRocknRoll has joined #openstack-swift14:55
*** esker has quit IRC15:05
*** ukaynar has joined #openstack-swift15:06
*** ukaynar has quit IRC15:14
*** ukaynar has joined #openstack-swift15:15
*** Lickitysplitted_ has quit IRC15:22
*** Lickitysplitted has joined #openstack-swift15:22
*** lcurtis has joined #openstack-swift15:23
*** bkeller` is now known as bkeller15:24
*** bkeller is now known as bkeller`15:25
*** garthb has quit IRC15:33
*** dmk0202 has quit IRC15:38
*** pgbridge has joined #openstack-swift15:39
*** ukaynar_ has joined #openstack-swift15:42
*** ukaynar has quit IRC15:42
*** Guest21288 has quit IRC15:46
ntatanotmyname, tqtran, So, I've been working on the tempest plugin for Swift functional tests and had similar questions about packaging.. My current work is an in-repo plugin that resides inside of test/tempest directory structure with an entry-point for plugin class and test listed under packages in setup.cfg15:52
timburkegood morning15:53
ntataMy original though was to push a patch with WIP and add notmyname and matt treinish as reviewers.. but now, I will wait for this discussion15:54
ntataMy original thought was to push a patch with WIP and add notmyname and matt treinish as reviewers.. but now, I will wait for this discussion15:54
*** arch-nemesis has quit IRC15:56
*** ukaynar_ has quit IRC15:57
*** ukaynar has joined #openstack-swift16:02
*** garthb has joined #openstack-swift16:08
openstackgerritDavid Goetz proposed openstack/swift: go: hashes.invalid  https://review.openstack.org/28683316:09
*** mmcardle has joined #openstack-swift16:10
*** zaitcev has joined #openstack-swift16:19
*** ChanServ sets mode: +v zaitcev16:19
*** dmorita has joined #openstack-swift16:25
notmynamegood morning16:29
acolestimburke: this change is curious - https://review.openstack.org/#/c/310596/2/swiftclient/shell.py@120116:30
patchbotacoles: patch 310596 - python-swiftclient - Default to v3 auth if we find a (user|project)-dom...16:30
zaitcevI missed another IRC meeting16:30
*** nadeem has joined #openstack-swift16:30
acoleszaitcev: congrats :)16:30
timburkeacoles: yeah, i had a reason for that...at one point...i'm sure of it16:31
acolestimburke: I'm wondering if there was any reason for the condition on v2 or v316:31
acolestimburke: right!16:31
timburkemaybe belongs in its own patch16:31
zaitcevthis guy is a lunatic http://lists.openstack.org/pipermail/openstack-dev/2016-May/094005.html16:31
acolestimburke: you mean you had a reson for removing it or a reason for it being there and the latter has gone away?16:32
acolesit seems to work16:32
notmynamezaitcev: hmm...hadn't seen that email yet16:33
zaitcevI started responding, but there's no arguing with delusion. I guess I'll just try to stick to facts once again, for the benefit of other people reading.16:33
timburkeacoles: for removing it. haven't done the blame yet to see when it came in or whether there was a good reason for *that*16:33
*** lakshmiS has joined #openstack-swift16:37
*** lyrrad has joined #openstack-swift16:39
acolestimburke: it came in here, so the v2 condition has always applied to using token and url https://review.openstack.org/#/c/23079/2/bin/swift16:40
patchbotacoles: patch 23079 - python-swiftclient - Allow v2 to use storage_url/storage_token directly (MERGED)16:40
timburkeacoles: that's what i was just learning, too. and it relied on our default auth version getting overridden when not all([auth, user, key])16:40
acolestimburke: except if you only provide token and url on command line then the auth version defaults to v2.0 anyway :) which means you get to use a v1 token and v1 auth url!!16:41
acolesthe joys of swiftclient!16:41
zaitcevI don't like how you guys are intent of making the selection of API version more complex in the name of poorly understood convenience. It's opaque and violates KISS principle.16:42
timburkeacoles: i think i dropped it with the expectation that i would do something more intelligent to detect when we ought to default to keystone, as in https://review.openstack.org/#/c/189387/15/swiftclient/shell.py@122616:44
patchbottimburke: patch 189387 - python-swiftclient - Prompt for missing password16:44
timburkezaitcev: i agree, to an extent. i'd kinda prefer that users just know what the hell auth they're trying to use and tell us. but users have demonstrated an unwillingness to do that, which causes persistent misunderstandings like "swiftclient doesn't support keystone v3!"16:47
acolestimburke:  i can't actually find a way (on master) to NOT have token/url passed to client when no auth version is specified - I either have all of A/K/U tokens in which case the enforce_requires check passes and then the token/url override in the Client,16:48
acolesor I don't have all of A/K/U options in which case the shell default to auth version 2 and allows token/url without enforce_requires check16:49
timburkeacoles: yep. which makes me want to remove that version check all the more. less to have to reason about16:49
acoleszaitcev: same as timburke  said, and additionally we unfortunately default to an API that is deprecated, but we can't change that default without breaking users, so we have to find more intelligent defaulting logic16:50
acolesor we do a discovery/version negotiation with keystone for every cli command16:51
*** mmcardle has quit IRC16:52
clarkbI think keystoneauth can do all that for you?16:53
clarkbthe version discovery stuff and making sure the right api is used to get a token16:53
acolestimburke: the weird outcome is defaulting the auth_version option to 2 when all we have is a v1 token and url :/ one day someone in service or client is going to trust that auth_version option and take some action based on it16:53
acolesclarkb: when I last tried, which admittedly was a long time ago, that came at the cost of an additional request to keystone. has that changed?16:56
clarkbacoles: discovery is an extra http get iirc16:57
timburkeacoles: yeah... i don't like that either. eventually, i'd prefer to just get rid of it entirely in favor of AUTH_PLUGIN or whatever that env var is that keystoneauth uses16:57
clarkbbut you can also specify a version directy to get around that16:58
acolesclarkb: makes sense.16:58
clarkbas a user my grumps are usually more along the lines of "this client refuses to function and the error I get back is indecipherable" not "zomg it made an extra 200ms rtt request"16:58
acolestimburke: are we going to update the docs to simplify the v3 auth example?17:08
acolestimburke: or is this a stealth feature?17:08
timburkeacoles: i'm inclined to say stealth feature. i'm in favor of being explicit in the docs, so that when there's a v4 and we have to change the defaulting logic *again*, whatever scripts were written based on the docs will definitely still work17:13
timburkei *am* debating about whether those docs ought to use ST_AUTH_VERSION or OS_IDENTITY_API_VERSION, though17:14
zaitcevURLs for v2 and v3 are not the same, are they? So you can't discover anything unless you muck the URL and issue a GET to prefefined URL like /info.17:14
redboI'm so jealous of how amazon does auth.17:14
zaitcevredbo: did you implement STS and AW4 in RAX17:14
zaitcevwe're currently working on it in Ceph RGW17:15
zaitcevWell, not I personally17:15
acolestimburke: i think i agree, and actually would prefer to see the auth version cli option called out explicitly in the v2 examples as well17:15
redboI don't know what those are, and also I don't think so.17:16
zaitcevWe have a guy in Detroil who comes into work in the 3 p.m. and then works until 4 a.m. and he's working on STS.17:16
acolestimburke: +1 for using OS_IDENTITY_API_VERSION - that was one of my review comments but it got merged first :)17:16
notmynameredbo: +1 (to the way AWS does auth)17:17
zaitcevSimple Token Service is anything but simple, and it allows anyone to supply an authenticator to Amazon, so S3 for instance calls out to that service.17:17
zaitcev(as far as I understand)17:17
zaitcevWhich means17:17
zaitcevKEYSTONE, right?!17:17
*** jistr has quit IRC17:17
notmynamezaitcev: that's interesting. I like the whole request signing method (albeit the v4 one with signing the whole body seems "interesting")17:18
acolestimburke:  OS_IDENTITY_API_VERSION not yet supported in service.py default options which would mean the doc examples become inconsistent between cli and service, so i concluded that we shoudl add  OS_IDENTITY_API_VERSION in service then change all the doc examples to use that17:19
*** gyee has joined #openstack-swift17:21
timburkeacoles: good point. i should go through an clean this up some more... or wait for joel to move on the config file stuff17:21
*** suyash has joined #openstack-swift17:21
*** klrmn has joined #openstack-swift17:21
openstackgerritMerged openstack/python-swiftclient: Parse options to dict  https://review.openstack.org/31226217:21
acolestimburke: i started a patch for the docs and then gave up for that reason ;)17:22
openstackgerritMerged openstack/python-swiftclient: Pull option processing out to service.py  https://review.openstack.org/31226317:22
redboI'm mostly jealous that implementing it doesn't take days and it doesn't require a separate request to auth.17:22
acolestimburke: ^^ 2 down...17:22
*** tqtran has joined #openstack-swift17:23
timburkenotmyname: it doesn't seem like a wholely bad idea...though it has an unfortunate requirement to reinvent chunked transfers17:23
*** cebreidian has quit IRC17:24
acolestimburke: i'll try to finish the 3rd review later, afk for a while17:31
*** CaioBrentano has quit IRC17:31
timburkeacoles: yeah, no worries. thanks for getting the other two in17:31
*** CaioBrentano has joined #openstack-swift17:37
tqtranntata-: nandini?17:37
notmynametqtran: yes17:44
*** itlinux has joined #openstack-swift17:52
*** StevenK has joined #openstack-swift17:56
*** arch-nemesis has joined #openstack-swift17:57
*** CaioBrentano has quit IRC17:57
*** CaioBrentano has joined #openstack-swift18:00
*** Jeffrey4l has quit IRC18:01
notmynamedfg_: looks like you're getting the controversy you hoped for on the mailing list ;-)18:16
*** dmorita has quit IRC18:17
*** dmorita has joined #openstack-swift18:18
dfg_notmyname: ya :) its kinda comforting- like old times :p18:21
notmynamedfg_: oh, can you send me some hummingbird graphs? something like req/sec or first-byte latency stuff. things that I can use as "we're not just doing this because we're bored with python" evidence18:25
notmynamedfg_: the saddlebird stuff is ok, but I'd prefer to leave out the proxy stuff and focus on what the object server can do. would make it less confusing and a crisper message18:26
*** acoles is now known as acoles_18:30
dfg_notmyname: so all the numbers you want would be straight to object server?18:30
notmynamedfg_: yeah, preferably, since that's what we're actually initially looking at18:32
redboI have this brilliant plan.  I'm going to make hummingbird into a python library.  Then swift-object-server will just look like "import hummingbird, sys  hummingbird.main(sys.args)"18:38
*** dmorita has quit IRC18:38
redbooops argv.  My first bug.18:38
notmynameheh18:39
*** esker has joined #openstack-swift18:40
notmynameredbo: you mean patch 20610518:41
patchbotnotmyname: https://review.openstack.org/#/c/206105/ - swift - Use entrypoints for storage policy implementation ...18:41
notmynameredbo: clayg will really like that because then swift-init still works ;-)18:42
*** dmorita has joined #openstack-swift18:42
*** rickyrem has joined #openstack-swift18:44
*** tqtran has quit IRC18:44
*** esker has joined #openstack-swift18:45
swiftfan_ceph is going to be part of openstack?18:46
nadeemswiftfan_ : where did you get this idea?18:48
swiftfan_I keep up with the openstack-dev list18:49
*** tqtran has joined #openstack-swift18:50
notmynameswiftfan_: that is up to the ceph team and the TC, and as far as I know, there's been zero interest from both of those parties to do that18:52
swiftfan_the TC?18:52
notmynametechnical committee18:53
*** mvk_ has quit IRC18:54
swiftfan_well, I hope they can work things out - it'd be good to have the option of using ceph18:55
notmynameyou have that option today18:55
swiftfan_we have to use openstack, political reasons18:56
swiftfan_all technical problems are ultimately people problems18:57
*** dmorita has quit IRC18:57
*** dmorita has joined #openstack-swift18:58
clarkbceph is a supported backend for nova, cinder, glance iirc. Just as much as say kvm or xen.18:58
swiftfan_yeah, but we have to use openstack even if there are better options18:59
clarkbI am saying it is just as openstack as using eg kvm or xen and I assume yo uare using one of them19:00
clarkbanyways as notmyname mentions it is an option today19:00
swiftfan_we aren't using nova - openstack is more than servers19:01
swiftfan_marconi works great19:01
claygswiftfan_: I thought it was zaqar?19:02
clarkbwhich too has different supported backends19:02
clarkbnova was just an example19:02
clarkbzaqar does redis and mongodb iirc19:02
tdasilvaswiftfan_: are you saying you can't use ceph today because it is not part of the openstack bigtent?19:02
notmynamesuccessful troll is successful?19:03
swiftfan_they did change the name to zaqar - I didn't notice19:03
swiftfan_yeah, we are 100% openstack19:04
swiftfan_anyway, back to work -- those asyncs aren't going to clear themselves19:04
*** guitarzan has joined #openstack-swift19:07
*** dikonoor has quit IRC19:09
openstackgerritMerged openstack/python-swiftclient: Default to v3 auth if we find a (user|project)-domain-(name|id) option  https://review.openstack.org/31059619:16
*** guitarzan has left #openstack-swift19:18
-openstackstatus- NOTICE: Gerrit is restarting to address performance issues related to a suspected memory leak19:22
zaitcevKevin is just nuts. His proposition is basically "please accept this enormous dislocation, so that I could reap the benefits of avoiding talking to my managers and explaining to them why running OpenStack on top of Ceph makes a great deal of sense in our environment." Fine, I see why you like this idea, but what is in it for me? Why should I do anything to help you?19:27
notmynamezaitcev: while mildly entertaining to read (because the alternative it so be sad), I'm not too worried about that line of reasoning. it's based on some inaccuracies about both swift and openstack itself, and it's not a new argument at all19:30
notmynamezaitcev: if something escalates on it, I'll jump in at some point, but for now, I'm just excitedly waiting for my mail client to give me the next chapter int he sage ;-)19:30
notmyname*saga19:30
zaitcevFreudian19:31
zaitcev^_^19:31
notmynamelol19:31
zaitcevIt's worse because I have a different sage in #animeblogger channel and at times it's startling.19:32
*** mvk_ has joined #openstack-swift19:32
notmynameyeah, that might get weird to confuse the two :-)19:32
*** papercup has joined #openstack-swift19:40
papercupHi folks - is there a known bug with the servers processes not responding to SIGTERM after a stress run ?19:41
claygpapercup: *servers* or *daemons*19:41
notmynamehttps://bugs.launchpad.net/swift/+bug/148920919:42
openstackLaunchpad bug 1489209 in OpenStack Object Storage (swift) "SIGTERM to a busy daemon has no impact" [High,In progress] - Assigned to Hisashi Osanai (osanai-hisashi)19:42
papercupclayg:  daemon19:42
claygpapercup: becuase for servers, not that I'm aware of - for daemons, yes I believe so (and could probably track down the lp bug #)19:42
clayg... except notmyname already did!19:42
papercupclayg:  notmyname thanks .. let me take a look19:43
zaitcevIs this only for the daemons that use InternalClient or all other daemons too, like replicators?19:45
*** rickyrem has quit IRC19:52
CaioBrentanoHi guys!19:57
CaioBrentanoI'm getting some "new" errors on my object-server logs19:57
CaioBrentanoobject-server: ERROR container update failed with <ip>:6001/sdf (saving for async update later): ConnectionTimeout (0.5s) (txn: txd5de5a17cef844fab6cb4-00572ba3b9)19:57
CaioBrentanois this related with I/O?19:57
*** dukhlov has joined #openstack-swift19:57
ahalenot like a swift bug, but i've seen bad hardware make pretty much every swift daemon/process/whatev hang uninteruptibly19:58
swiftfan_CaioBrentano: those are asyncs. backend processes *might* clear them eventually. until then your container listings *might* be inaccurate19:59
swiftfan_an async is a failed request to update a container db that will be tried later20:00
swiftfan_they could be caused by high load20:00
CaioBrentanoA new app is creating tons of objects... I was figuring out that could be disk io saturation20:00
*** clu_ has joined #openstack-swift20:01
*** daemontool_ has quit IRC20:01
swiftfan_on a put to swift, the object server has to update the conainter dbs -- if that fails, an async is created20:01
swiftfan_it sits on disk until cleaned up20:01
swiftfan_the # of aysncs in your cluster is something you should monitor20:02
swiftfan_they can really get out of hand20:02
papercupclayg:  being a newbie - I'm not sure I understand if the bug is applicable for proxy/container/account server parent processes as well, because I see that happening for me after I'm done running  ssbench for large scenario repeatledly20:03
CaioBrentanothanks swiftfan_20:04
CaioBrentanois there anyway to monitor this other than log parsing?20:04
swiftfan_you should probably look for them on disk20:04
swiftfan_they are just files on disk20:05
swiftfan_there might be a swift recon thing for it20:05
swiftfan_CaioBrentano: http://docs.openstack.org/developer/swift/admin_guide.html <-- look for "pending" on that page20:06
swiftfan_that's one way to do it20:07
CaioBrentanonice! thanks again swiftfan_20:07
swiftfan_no problem - i love being helpful! :)20:07
*** NM has joined #openstack-swift20:10
openstackgerritThiago da Silva proposed openstack/swift: Refactor server side copy as middleware  https://review.openstack.org/15692320:10
zaitcevclayg: have you, or are you going to post a patch to catch_errors that excludes SystemExit?20:18
zaitcevhttps://gist.github.com/clayg/965ab068d5f0f56ee77bae7dff2e9ebb#file-fix-catch-errors-patch20:20
*** dmk0202 has joined #openstack-swift20:29
-openstackstatus- NOTICE: Gerrit is restarting to revert incorrect changes to test result displays20:30
*** cdelatte has quit IRC20:34
*** daemontool_ has joined #openstack-swift20:35
openstackgerritShashirekha Gundur proposed openstack/swift: To fix probe tests failing from commit cf48e75  https://review.openstack.org/31315020:35
openstackgerritShashirekha Gundur proposed openstack/swift: To fix probe tests failing from commit cf48e75  https://review.openstack.org/31315020:45
*** amit213 has joined #openstack-swift20:50
*** esker has quit IRC20:52
*** esker has joined #openstack-swift20:57
*** rcernin has joined #openstack-swift21:05
rcerninguys does swift provide any health check tool which can be targeted against a specific account?21:06
claygswift-account-audit is a thing -> https://github.com/openstack/swift/blob/master/bin/swift-account-audit21:07
claygrcernin: but it's not that lovingly mantained - folks tend to think about cluster/node issues more than something that may be isolated to an account i guess?21:07
claygzaitcev: I have not, i should, but am not currently, but might at some later point21:11
rcerninclayg, thanks, i m looking for something like the swift-dispersion-tool, but if that could be targeted against an account. To make sure the objects are replicated on all nodes.21:11
claygzaitcev: I *do* still think it's a better approach than the thread thing... the servers get away from it because of the parent process forking workers is the guy that gets the TERM21:12
zaitcevclayg: so maybe we'll just have a voting contest then21:13
claygrcernin: yeah sounds interesting - i'm not sure that the current swift-account-audit uses rings to go directly to backend storage servers or just proxy api requests21:13
claygzaitcev: if needed - i guess gerrit is sort of for that - I think I took off my -121:14
zaitcevclayg: you did, but might as well keep it21:15
claygzaitcev: trying to rib me into writing tests for the SystemExit patch might be the best strategy tho... kudos there21:15
zaitcevaww snap21:15
claygmaybe tomorrow - fridays are good for that kind of stuff21:15
claygzaitcev: if you can manage to shutdown the trolls on the ML that might at least keep me from getting destracted by that :)21:16
*** MVenesio has quit IRC21:16
zaitcevclayg: Sorry, that's not possible... I've already given up.21:16
clayglol21:16
claygnotmyname: do you have the intel/pypy patches handy?21:17
openstackgerritBrian Ober proposed openstack/swift: Storage Account Object Count Quota Support  https://review.openstack.org/31260321:24
*** cdelatte has joined #openstack-swift21:24
*** ukaynar has quit IRC21:26
*** mingdang1 has joined #openstack-swift21:26
*** lakshmiS has quit IRC21:32
*** ametts has quit IRC21:34
*** NM has quit IRC21:37
*** MVenesio has joined #openstack-swift21:42
*** dukhlov has quit IRC21:42
*** pauloewerton has quit IRC21:42
papercup being a newbie - I'm not sure I understand if the bug - https://bugs.launchpad.net/swift/+bug/1489209 -  applicable for proxy/container/account server parent processes as well, because I see that happening for me after I'm done running  ssbench for large scenario repeatledly21:42
openstackLaunchpad bug 1489209 in OpenStack Object Storage (swift) "SIGTERM to a busy daemon has no impact" [High,In progress] - Assigned to Hisashi Osanai (osanai-hisashi)21:42
papercupclayg: ^^21:43
notmynameclayg: yeah, I do, but they aren't complete. If you're doing pypy tests, the best thing currently is to up the GC size to kinda sidestep the issue21:43
notmynameclayg: but if you want the patch that i have, I can easily pastebin it21:44
*** MVenesio has quit IRC21:44
notmynameclayg: ah. I see the ML message now :-)21:44
*** arch-nemesis has quit IRC21:45
*** dukhlov has joined #openstack-swift21:49
openstackgerritDavid Goetz proposed openstack/swift: go: adding a x-trans-id to repconn along with the sender device id  https://review.openstack.org/31316721:50
*** dukhlov has quit IRC21:53
*** ametts has joined #openstack-swift21:56
*** _JZ_ has quit IRC21:57
mattoliveraumorning22:06
*** asettle has joined #openstack-swift22:18
brianclineweird question - do changes that typically change the on-disk ring format typically get tagged with UpgradeImpact? (I know there are only a few of them)22:18
notmynamebriancline: I don't think we've done much with that tag before22:18
notmynamebriancline: but IIRC there's only been one on-disk ring format change, and that was a couple of years ago22:19
brianclinenotmyname: ah, thanks.22:21
*** cdelatte has quit IRC22:22
notmynamesgundur-: what's the difference in your patch 313150 and torgomatic's patch 311899? why do you think one should be done over the other?22:22
patchbotnotmyname: https://review.openstack.org/#/c/313150/ - swift - To fix probe tests failing from commit cf48e7522:22
patchbotnotmyname: https://review.openstack.org/#/c/311899/ - swift - Fix probe tests from commit cf48e7522:22
claygpapercup: the bug as written for "SIGTERM to a busy daemon has no impact" and the proposed solutions to the problem as zaitcev hrou and I understand it is *not* applicable to proxy/container/account server parent processes22:27
timburkenotmyname: it may also be worth using UpgradeImpact when we know that a rebalance will move a lot of parts within a ring. thinking of patch 24157122:28
patchbottimburke: https://review.openstack.org/#/c/241571/ - swift - Put part-replicas where they go (MERGED)22:28
papercupclayg: thanks. that's very helpful.22:28
claygpapercup: are you experiencing issues with the wsgi-server processes/workers not responding to SIGTERM?  I'm still unclear?22:29
papercupclayg yes22:29
claygtimburke: Warning - you shit is about to get a whole lot better22:29
*** rcernin has quit IRC22:29
claygpapercup: strace 'em?22:29
claygpapercup: are you running with worker count 0 (no fork)?22:30
papercupclayg: worker count is 322:30
claygpapercup: werid - yeah I don't see how any issue there could be related to the reported bug22:30
timburkeclayg: oh, it definitely got better. but we should probably offer a warning when we know there'll be a lot of replication traffic as it all settles down22:30
claygpapercup: FWIW I do benchmarking loads all the time on clusters of various configurations and have never had any issue with services failing to respond to TERM22:31
papercupclayg:  yes - I didn't think so. but then, I don't know much.  Let me strace and see ... just looking at stacks in gdb doesn't help much :-)22:31
claygpapercup: HUP is a different story for various reasons - the default behavior of swift-init stop is TERM - reload has a HUP behavior thats more... "graceful" i think is the term we've used - I call it yellowbellied22:32
papercupclayg:  :-)22:32
claygtimburke: idk; i don't think i disagree with what you're saying - fucking UpgradeImpact everywhere!  But FWIW you can *see* how many parts move in a rebalance - the fact that we had a ring out there were it was scaryier to fix them than leave them hozed up prompted patch 311226 - but in the one case I know about no ones behavior was going to change w/ or w/o the commit tag?22:34
patchbotclayg: https://review.openstack.org/#/c/311226/ - swift - Pretend *some* parts min_part_hours_passed22:34
*** ametts has quit IRC22:35
openstackgerritClay Gerrard proposed openstack/swift: Pretend *some* parts min_part_hours_passed  https://review.openstack.org/31122622:40
openstackgerritSamuel Merritt proposed openstack/swift: Remove unneeded setting of SO_REUSEADDR.  https://review.openstack.org/31279122:40
*** garthb has quit IRC22:47
*** garthb_ has joined #openstack-swift22:47
*** cdelatte has joined #openstack-swift22:51
*** nadeem has quit IRC22:51
*** david-lyle has quit IRC22:51
*** david-lyle has joined #openstack-swift22:53
brianclineclayg: yeah, behavior definitely wouldn't change. it's useful to have bigger ops-side things like that easily grokable like UpgradeImpact is during an upgrade endeavor, where there may be tons of commits to sift through. i think so far most changes about that i think end up in the changelog -- but that (intentionally) doesn't tell an operator some of the finer details they may need to know, but which may be in the commit msg or gerrit history22:55
*** david-lyle has quit IRC22:58
brianclineer.. i said grok, i think i meant grep or whatever22:58
*** newmember has joined #openstack-swift23:01
claygbriancline: whatever you think helps - I just read every commit every time I package swift for release ;)23:03
*** newmember has quit IRC23:04
notmynameI do my best to highlight those sort of things in the changelog at every release so you don't have to grep every commit message23:10
brianclineclayg: lol, i usually scan the --oneline output.. mostly for words that give me palpitations23:13
claygbriancline: good strategy!23:14
brianclinenotmyname: yeah, the changelog is helpful - but sometimes for further detail, finding a way back to the commit/discussion on changes of that caliber isn't trivial23:15
claygbriancline: did the last bout of ring fixes give you guys some grief too?  discussions with dfg_ is what prompted the pretend_min_part_hours_locked and I'm sorta happy with how it went - cschwede didn't *immediately* say I was crazy.  It's all very related to what timburke is pointing out23:15
notmynamebriancline: would you prefer the changelog have a reference to the commit SHA? I could do that23:15
claygAnd donagh reminds of the "consequences" of our code as well :D23:16
brianclineclayg: the only major effect I noticedf was exactly what you predicted -- some additional part movement once you do the first post-upgrade rebalance. I read through the pretend_min_part_hours_locked review briefly, but haven't had ample time to dig in to see if it's causing us any pain or not though :-\23:19
brianclinenotmyname: sure, that'd be one good way to do it23:20
* briancline is curious how others feel about it23:20
claygbriancline: once you rebalance on the swift 2.6(ish?) code it's over an done - it only hurt once and in all the cases I personally cared about it was worse to not fix it than it was to fix it - ahale said he'd just wait until dfg_ had a better plan - which apparently was "nerd snipe clayg into making ahale happy"23:21
brianclinelol23:21
claygI honestly hadn't realized how much people were scared of that sha until dfg_ pointed it out to me last week - i don't even realize how wide spred it is?23:22
claygwhere "it" ~= "concern about fixing bad part placement in a single rebalance"23:22
claygIn my testing I never observed it moving stuff that shouldn't move ... I guess I still don't understand what percentage of parts we're talking about or even how much part movement is scray in "your" cluster on a case by case basis23:23
claygI have my own tolerences for pain23:23
*** sorrison_laptop has joined #openstack-swift23:23
brianclineyeah, seems it would vary widely. both the movement and the sensitivity23:24
*** lcurtis has quit IRC23:24
brianclinepersonally I'd always rather have the one-time movement over and done with, even if it means a noticeable amoutn of additional IOPS during a routine ring push to do it23:26
*** mingdang1 has quit IRC23:27
*** vinsh_ has quit IRC23:31
*** urth has quit IRC23:31
*** sorrison_laptop has quit IRC23:33
*** cdelatte has quit IRC23:34
*** urth has joined #openstack-swift23:36
*** klamath has quit IRC23:38
*** tqtran has quit IRC23:41
*** dmk0202 has quit IRC23:42
*** MVenesio has joined #openstack-swift23:45
openstackgerritJohn Dickinson proposed openstack/swift: Rework the contributor docs  https://review.openstack.org/30187123:47
*** MVenesio has quit IRC23:50
*** ukaynar has joined #openstack-swift23:51

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