Friday, 2018-09-28

timburkebah, my repro didn't pan out -- ratelimit's get_container_info call still has a PATH_INFO like /bucket/obj so the proxy-server 400s00:12
timburke(plus, it thinks that it wants to do account-level ratelimiting...)00:13
timburkeso while i still think my broader concern is warranted (do we have middlewares that *do* drop the sysmeta when translating between sysmeta and client headers?), that bug seems very particular to S3Request.get_container_info rather than proxy.controllers.base.get_container_info00:22
timburkethere's https://github.com/openstack/swift/blob/2.19.0/swift/common/middleware/symlink.py#L249-L264 but that's objects...00:30
* timburke shrugs00:31
DHEroles in keystone are a little confusing. can I just make a new role, add it to proxy-server.conf as "operator_roles = <newrole>, <existing-values>" and that user can use swift but not any other openstack stuff? (ie make virtual machines, etc)00:40
*** gyee has quit IRC00:51
*** two_tired2 has joined #openstack-swift00:55
DHEaside: liberasurecode_rs_vand in 10+3 configuration on an older 3.6 GHz CPU (i7-4790) in theory can hit 500 megabits of PUT performance per core... actual throughput was ~100 megabits at ~19% CPU usage01:12
mattoliverauDHE yup (re:keystone). You can have a list of roles in keystone that match to operator roles. Then any user in that role can access swift, and so long as you make sure members of that role don't have access to other openstack things it shold work as expected.01:25
DHE"other openstack things" is the tricky bit. my nova system doesn't even have a policy.json file. or rather it's just "{ }".... :/01:26
DHEand reading it is weird...01:26
DHEI'll roll with this and see how it goes...01:29
*** itlinux has joined #openstack-swift01:44
*** itlinux has quit IRC01:44
*** psachin has joined #openstack-swift03:30
*** mikecmpbll has quit IRC03:41
*** two_tired2 has quit IRC04:11
*** itlinux has joined #openstack-swift05:12
*** e0ne has joined #openstack-swift05:52
*** pcaruana has joined #openstack-swift06:11
kota_hello world06:16
*** e0ne has quit IRC06:24
mattoliveraukota_: o/06:27
*** e0ne has joined #openstack-swift06:52
*** rcernin has quit IRC07:12
*** gkadam has joined #openstack-swift07:23
*** mikecmpbll has joined #openstack-swift08:04
openstackgerritMerged openstack/swift master: Use latest eventlet in probe tests  https://review.openstack.org/60252608:24
*** guimaluf has quit IRC09:44
*** e0ne has quit IRC10:16
*** e0ne has joined #openstack-swift10:25
*** psachin has quit IRC13:13
*** two_tired2 has joined #openstack-swift13:57
openstackgerritThiago da Silva proposed openstack/liberasurecode master: Install ISA-L lib to be tested w/ liberasurecode  https://review.openstack.org/60439114:24
*** two_tired2 has quit IRC14:35
*** e0ne has quit IRC14:58
*** e0ne has joined #openstack-swift15:02
notmynamegood morning16:08
notmynametimburke: do you know how to check what verion of python was running in a set of tests?16:18
notmynameeg http://logs.openstack.org/62/605862/2/check/swiftclient-functional-py2/b42c7e9/job-output.txt.gz is supposed to be py2 and http://logs.openstack.org/62/605862/2/check/swiftclient-functional/837299b/job-output.txt.gz is supposed to be py3. but I can't really find anything in there that actually says that16:18
*** gyee has joined #openstack-swift16:24
notmynamemaybe we need to add a `python -V` to the start of all our tests16:35
notmynameboth of those log files above are from https://review.openstack.org/#/c/605862/16:36
patchbotpatch 605862 - python-swiftclient - py2 functional testing - 2 patch sets16:36
*** ianychoi has quit IRC16:39
*** mikecmpbll has quit IRC16:41
*** gkadam has quit IRC16:42
*** ianychoi has joined #openstack-swift16:44
tdasilvanotmyname: it's weird that all tests are being skipped, not sure why...16:53
notmynametdasilva: turns out, these jobs run the tests twice! scroll up and you'll see another with all tests running and passing16:53
notmynametimburke was saying this is to test keystone vs not-keystone16:53
tdasilvaheh, ok: i just the skipped in the logs then saw this: http://logs.openstack.org/62/605862/2/check/swiftclient-functional/837299b/testr_results.html.gz16:54
notmynameyep. I did exactly the same thing yesterday--sgo to the bottom, scroll up until you see results, and "wat?!"16:54
notmynameI was intentionally leaving that weirdness alone for now. I first want to get whatever we have today running in py2 and py3. then we can go back in and make sure the right things are being tested16:55
notmynamethe state of func tests in swiftclient are pretty sad. I don't want to try to fix all of that right now. that will take a long time16:55
timburkehmm... more functional test flakiness when run in resource-starved VMs? http://logs.openstack.org/22/580122/2/check/swift-multinode-rolling-upgrade/9334639/job-output.txt.gz#_2018-09-28_04_50_28_83653717:05
*** psachin has joined #openstack-swift17:09
timburkenotmyname: tdasilva: you can indirectly determine python version from https://github.com/openstack/python-swiftclient/blob/master/requirements.txt#L1 -- look for whether futures shows up in the tox env17:14
timburkecompare http://logs.openstack.org/62/605862/2/check/swiftclient-functional-py2/b42c7e9/job-output.txt.gz#_2018-09-28_01_23_29_134661 and http://logs.openstack.org/62/605862/2/check/swiftclient-functional/837299b/job-output.txt.gz#_2018-09-28_01_24_44_57676917:14
*** ejat has quit IRC17:29
notmynametimburke: thanks. *sigh* that's a terrible heuristic17:42
timburkei wholeheartedly agree17:42
*** e0ne has quit IRC17:44
notmynametimburke: however, the good news is that the py2 functional tests are actually using py2! yay!17:45
*** mikecmpbll has joined #openstack-swift17:55
*** mahatic has quit IRC17:56
*** e0ne has joined #openstack-swift18:02
*** mahatic has joined #openstack-swift18:04
*** ChanServ sets mode: +v mahatic18:04
*** e0ne has quit IRC18:05
*** e0ne has joined #openstack-swift18:25
notmynamedid anyone see the policy naming mailing list thread?18:48
*** e0ne has quit IRC18:50
timburkehuh. http://logs.openstack.org/91/604391/3/check/liberasurecode-unittests/13ef1c8/job-output.txt.gz#_2018-09-28_16_51_31_91645218:53
timburke"the `impossible' happened" -- sounds ominous18:53
notmynamelol18:53
notmynamethe policy stuff makes me want to remember all hisashi's work on the RBAC stuff18:53
timburkeapparently we hit https://github.com/lu-zero/vex/blob/3c7650b/priv/ir_opt.c#L1223 ?18:55
notmynameI wonder what the Ico_ prefix on those types means18:56
timburkewe merged some of that RBAC stuff... looks like https://review.openstack.org/#/c/212825/ and https://review.openstack.org/#/c/253371/ are still open18:59
patchbotpatch 212825 - swift - Add functional test for access control (COPY) with... - 10 patch sets18:59
patchbotpatch 253371 - swift - Improves RBAC related functional test - 8 patch sets18:59
notmynamehttps://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:add-functional-test18:59
notmynamebut I'm trying to remember how it works with keyston/oslo RBAC at all. like where are these defined?19:00
timburkeyeah, i'm trying to remember, too. i feel like there was something ... oh! here! https://review.openstack.org/#/c/149930/19:01
patchbotpatch 149930 - swift - WIP: Enable Role-based access control using oslo.p... (ABANDONED) - 15 patch sets19:01
notmynameyeah. I'd love to have the policy.jsob stuff enabled for any auth system and avoid the need to bring in oslo config. it would give operators quite a bit of control, especially when they back auth with ldap or ad19:07
*** e0ne has joined #openstack-swift19:29
*** e0ne has quit IRC19:34
openstackgerritFatema Khalid Sherif proposed openstack/swift master: Enabling direct_client users to overwrite X-Timestamp  https://review.openstack.org/60326119:38
*** openstackgerrit has quit IRC20:07
*** openstackgerrit has joined #openstack-swift20:08
openstackgerritTim Burke proposed openstack/swift master: Ignore ENOENT and ENOTEMPTY errors in delete_partition  https://review.openstack.org/60619220:08
*** psachin has quit IRC20:10
*** geaaru has joined #openstack-swift21:41
*** paladox is now known as paladox[EU_UK]22:07
*** paladox[EU_UK] is now known as paladox22:08
*** paladox is now known as paladox_UK_EU22:09
*** paladox_UK_EU is now known as paladox[UK_EU]22:09
*** paladox[UK_EU] is now known as paladox22:10
openstackgerritMerged openstack/python-swiftclient master: py2 functional testing  https://review.openstack.org/60586222:41
*** fatema_ has joined #openstack-swift22:47
fatema_Good morning22:47
timburkea very early morning for you fatema_, no?22:54
openstackgerritMerged openstack/swift master: Unquote URL before using splited parts.  https://review.openstack.org/58012222:55
fatema_yes, 1 A.M. :D22:58
fatema_but no lectures tomorrow so it's fine22:58
fatema_timburke, I just had some questions but left them in comments.22:58
fatema_I wanted to know another thing about the bug https://bugs.launchpad.net/swift/+bug/175725022:59
openstackLaunchpad bug 1757250 in OpenStack Object Storage (swift) "direct_client gen_headers is inconsistent" [Wishlist,New]22:59
fatema_It mentions the need to *make sure all direct_client methods accept the headers kwarg*23:00
openstackgerritTim Burke proposed openstack/swift master: Tolerate missing containers when trying to clean up  https://review.openstack.org/60621723:03
timburkehurray for weekends!23:03
timburkei'll take a look at comments next, but yeah -- it'd be nice if callers could pass headers for all api calls23:03
timburkei think it's just the two functions that need it23:04
fatema_timburke, are callers intended to pass headers through kwargs ??23:08
fatema_I see that most of the functions in direct_client don't have kwargs23:09
timburkeyou usually see signatures like https://github.com/openstack/swift/blob/2.19.0/swift/common/direct_client.py#L214-L215 or https://github.com/openstack/swift/blob/2.19.0/swift/common/direct_client.py#L248-L251 -- the bug is just that https://github.com/openstack/swift/blob/2.19.0/swift/common/direct_client.py#L224-L225 (for example) doesn't accept a headers arg23:11
timburkethe caller might provide it as a keyword arg like direct_head_container(..., headers={'x-blah-blah': 'blah'}) or positionally like direct_head_container(..., {'x-blah-blah': 'blah'}) -- i'm not so concerned about that part23:13
fatema_ok I see now how it could be passed. why isn't this part a concern ?23:18
timburkebecause i'm fairly certain that the majority of callers are inside the swift repo ;-)23:22
*** fatema__ has joined #openstack-swift23:22
*** fatema_ has quit IRC23:23
fatema__Hmm....23:24
fatema__You know better of course. But I think I would do it to close the bug23:25
timburkefor the few that aren't, as long as we append to the end of the argument list, we won't break existing users. though i wouldn't be surprised if we've rearranged args before -- again, this doesn't seem highly-used and where we *really* care about api compat is in things like proxy-server responses23:25
timburkeOH! i think i get the question now :-) i'm pretty sure clayg just meant that there should be a headers arg, and it should be named "headers" to be consistent with the other functions, not that we should have everything start accepting **kwargs and ignoring anything we don't recognize23:27
*** gyee has quit IRC23:33

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