#2280 Use requests_gssapi instead of requests_kerberos
Merged by mikem. Opened by simo.
simo/koji use_request_gssapi  into  master

Download 2280.patch

Retain ability to use the old requests_kerberos where request_gssapi is
not available yet.

Fixes #882

rebased onto d5b53fc126f156437633a0d5b3ea6b5fa4143c0a

@tkopecek thanks for the help, CI passes now!
(following up from #2274)

Thank you for writing this patch!

I'm confused why we don't simply import requests_gssapi without renaming it to the obscure reqgssapi name.

This would allow us to set requests_kerberos = None, and this would make it easier to read and understand that hairy code below that tests requests_kerberos.__version__ for the principal kwarg support. Like "If we have requests_gssapi, assume that the principal kwarg will always work without checking __version__"

I just didn't want to have divergence at this stage, once we remove the support for requests-kerberos and the even older krbV cleanup can be done.

I see there were some comments in #2274 about the lack of python-requests-gssapi on el6 and el7. As a Fedora packager, is that something I can help with, or are those platforms too old for the latest versions of python-gssapi + python-requests-gssapi? It would simplify QE if we could reduce the options.

I do not know about EL7, but almost certainly EL6 can't do python-gssapi/request-gssapi easily enough, we just need to wait for EL6 to die a graceful death ...

python-requests-gssapi is packaged for epel7.

el6 doesn't support new enough python tooling (cython, etc.) for python-gssapi. Heck, I have to patch around cython bugs just to build in el7, even.

Better would be to stop caring about el6, given even el7 is in maintenance mode.

any obstacle to merging this one ?

Capacity :- ) We need to test it more - I've scheduled if to 1.23 already but if there is some strong reason to squeeze it into 1.22 we can discuss it.

When is 1.23 going to land in Fedora ?
I am providing patches like this because we want to drop python-kerberos from Fedora, ans we'll never do it if we can't make a concerted effort to remove all dependencies and then ban re-entry :-)

It would be around October. But yes, it make sense to squeeze it into 1.22

the version check doesn't seem necessary anymore. requests-gssapi's first GA is 1.0.0

@julian8628 as mentioned before that code runs with both requests-gssapi AND requests-kerberos, for gssapi it is redundant but it is still needed if request-kerberos is the only available.

Metadata Update from @tkopecek:
- Pull-request tagged with: testing-ready

breaking automerge, removing testing-ready temporarily

Metadata Update from @tkopecek:
- Pull-request untagged with: testing-ready

Is there anything I need to do here ?

We need to merge all other testing-ready PRs first, so it is rebasing correctly. No need for action.

there's no python2-requests-gssapi on fedora32+ (python-requests-gssapi is python3-requests-gssapithere, and py2 ver is available on fedora29 and 28)
I think we could just remove this part for python2-koji

does this make sense? https://pagure.io/fork/julian8628/koji/commits/pr2280

@julian8628 sounds reasonable ...

Do you want me to amend this PR with that commit ?

@simo Yes please. Appreciated that!

rebased onto 3b9fcc664f8e1da3eadf27a54555eeae503687c3

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done

Commit 18e0e880 fixes this pull-request

Pull-Request has been merged by mikem

resolved minor merge conflicts with #2244

Are you sure the change in util/kojira is correct ?
It seem to undo something I was not touching in my original commit

to be clear I think gssapi_login _> krb_login is wrong in your conflict resolution

Metadata