Monday, 2022-05-02

b-prajaktaHI , I am new to Launchpad07:18
b-prajaktaI want to contribute to openstack be resolving few bugs 07:25
*** marlinc- is now known as marlinc07:26
b-prajaktaBut when I try self -assign bugs , I am not able to do it , even if the Assiggnee is set to None07:26
b-prajaktaPlease can someone help me with this07:26
b-prajaktaIs there any step that I am missing 07:26
b-prajaktaI am not able to see the assign yourself option when i right click on assignee - None07:26
fricklerb-prajakta: depending on the project you may need additional privileges in order to do that. you can try to talk to people in that project in their channel about it. or just write a comment in the bug report. or simply submit a review referencing the bug id07:46
marlincWhat could be the cause of 'greenlet.error: cannot switch to a different thread' error messages? Seeing this in the Cinder API I can imagine, especially when using something like uWSGI but this is happening when running cinder-volume and cinder-scheduler08:42
*** rlandy|out is now known as rlandy10:23
marlincLooks like this might be the cause
jamesbensonjrwr: ping 15:24
*** rlandy is now known as rlandy|ruck16:25
*** rlandy|ruck is now known as rlandy|rover18:30
muzicarHi. I've been reading around a bit and haven't yet come to a conclusion about swauth and keystone - I inherited a 24TB openstack switf object storage that has been neglected - still on ubuntu 14.04 and on swift 1.3.1 . I have a few projects in queue that would require keystone as auth instead of swauth but there are quite a few projects still running in production that use swauth. My question is - can both keystone and swauth be used a19:23
*** timburke__ is now known as timburke19:24
timburkemuzicar, yes, keystone and swauth can both be used in the same proxy pipeline. it's been a while since i did it, but i wouldn't be surprised if the pipeline order was significant19:29
timburkeprobably want it like '... authtoken keystoneauth swauth ... proxy-server' but if you've got a dev or staging environment, it's worth verifying19:33
timburkenote that you'll definitely want delay_auth_decision=true for authtoken19:35
muzicargreat cheers for that. I currently don't have any test/dev env but I could probably spin something up. I checked the swift changelog and I didnt notice any clear "deprecation" of swauth - I know the project itself is deprecated - but from what I gather swauth works with the latest openstack swift without any issues - am I on the right track here?19:37
muzicar(the track being that I would also bump swift before adding keystone)19:38
timburkeas far as i'm aware -- but that's not saying much19:41
timburkei *do* know that if you're looking to bump python versions, too, it may get hairy. swauth was retired in part because it hadn't been ported to py319:41
muzicarah good point. the latest swift is the last one that supports python 2.7 so that is indeed something to keep in mind.19:44
timburkestill, getting to 2.29.1 is going to be *way* better than being stuck on 1.3, even if you have to be there a while19:47
timburkeis there any plan to migrate the swauth users to keystone, once you've got both enabled?19:48
muzicarwould there be any benefits to that since all the swauth users would keep on using swauth for auth?19:50
timburkemuzicar, main thing i was thinking of was being able to some day get off py2. fwiw, i took a stab at adding py3 support to swauth at -- i haven't actually functionally tested it, though20:13
muzicarthat would be wise indeed. Is there a way to migrate swauth users to keystone? 20:54
timburkemuzicar, hand out new keystone creds and move data between accounts. could be a little painful, though at 24T, it could be worse. if you create a "reseller admin" on the keystone side, that user will be able to do cross-account copies so you don't even need to stream the data through the client21:47
timburkeat 24T, copying all data down to a couple hard drives then wiping and rebuilding the cluster isn't off the table21:50
muzicardidnt even think about rebuilding tbh but I suppose that would also be viable. I guess Ill have a better view of things once I get a full picture on which projects exactly have this and which can either be retired or someone would still be willing to switch it to keystone.22:04
muzicarah sry... I forgot the 0 at the end :) its a 240TB cluster not 24TB and its at about 23%22:06
timburkethat makes more sense :-) i was going to say, 24T's not so far off from what i've got in my garage22:12
timburke23% full is a great spot to be, though -- you've got the option to do a complete copy without deleting as you go22:13
*** rlandy|rover is now known as rlandy|rover|bbl22:29
muzicarvalid point. Cheers for all the info. I might swing by here again once I get a bit deeper into this but I definetly have a better picture as to what can be done :)22:35
timburkesounds good. also feel free to drop in #openstack-swift -- you'll probably catch some other swift folks that might not be in here23:42

Generated by 2.17.3 by Marius Gedminas - find it at!