Also, hub principal is derived from client principal, so we need to be able to set server principal separately (at least kojid.conf, best koji.conf).

candidate PR: #1648

Commit 0fa9eb08 fixes this issue

a small fix PR #1696

Commit 9f268438 fixes this issue

a set of followup fixes: PR #1701

Commit 97cee1c3 fixes this issue

Commit 004dda16 relates to this ticket

Note that this change means that there's a different getUser signature between 1.19.0 and 1.19.1 and since the new flag defaults to False it means that a client which wants to obtain the kerberos data will in many cases need to call getUser twice:

1. getUser FOO True
2. no kerberos info, unsure if because there really isn't or if host has migrated to new API

3. call getUser FOO True True

4. getUser FOO True True

5. contains new kerberos info provided koji instance is running the new API, but errors on old API
6. getUser FOO True

Is there any guidance on which is "most polite" from a koji perspective? Is it better to just jump straight in to trying the new API and falling back on failure, or better to only attempt the new API if the information isn't in the results from using the old API?

apologies, my two lists of 1-3 got merged into a single list of 1-6. Please read the above pretending that those are two different situations of which API should be called first, both labelled 1 through 3.

@cobrien
Thanks for the advice.

getUser FOO True
no kerberos info, unsure if because there really isn't or if host has migrated to new API

no, kerberos info is hidden by the default krb_princs=False

call getUser FOO True True

getUser FOO True True
contains new kerberos info provided koji instance is running the new API, but errors on old API
getUser FOO True

Maybe it is worthy to set the default value of krb_princs to True, but anyway relying on the old property krb_principal in result will fail, new property is krb_principals

(milestone was set to None but was unable be changed back :disappointed: )

My point is that it makes it difficult to write code that will work with both versions, and I was simply trying to illustrate why. If the default for krb_princs were True then I could write a check for whether either krb_principal or krb_principals were in the result, and act appropriately. As it is I think the most correct is to write it using the new API, and catch the exception and retry using the old API. It's easy enough after that to look for just which key ended up in the user info dict.

Yes, the second one is better as trying the newer version at first

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/1629

Please continue any further discussion there.