@cverna do you mind taking a look?

This looks like an issue with OSBS. Is there a queue/issue space for reporting problems for that service ... or does the Atomic Working Group usually front these?

I am on it .

This looks like an issue with OSBS. Is there a queue/issue space for reporting problems for that >service ... or does the Atomic Working Group usually front these?

It is better to open these in the fedora-infra, there is an OSBS tag.

I have opened https://pagure.io/fedora-infrastructure/issue/6861 to track this issue.

I am on it .

This looks like an issue with OSBS. Is there a queue/issue space for reporting problems for that >service ... or does the Atomic Working Group usually front these?

It is better to open these in the fedora-infra, there is an OSBS tag.
I have opened https://pagure.io/fedora-infrastructure/issue/6861 to track this issue.

Yeah. the problem is that fedora infra (and releng) repos are quite high volume and it can be hard as a user (or even as someone who tries to help manage existing problems in the Atomic* space) to keep up with them. I typically open an issue here and then strategize about the best way to solve the problem. If it involves including infra/releng/websites/fesco/qa/etc then I open a ticket there too and report back here.

It's a hard problem to solve. I honestly wish pagure had the ability to have tickets depend on other tickets in other repos etc..

If this is a bad practice then we can revisit it, but it's been what works best for us so far.

This issue is now fixed on our infra (again), but maybe the underlying issue is something that the atomic WG should possibly look at:

puiterwijk | Short summary: if a special directory exists on the container host (osbs-node*), docker will mount that directory in /var/run/secrets for RHEL
           | subscription manager certificates. But that conflicts directly with the attempts to mount service account secrets into /run/secrets/<uuid>    
           | that Kubernetes/Openshift tries to do                                                                                                         
puiterwijk | Basically, deleting /usr/share/rhel/secrets will fix this, because that avoids the Fedora/RH docker to mount that into /run/secrets

(note that OSBS production is currently on Openshift Origin 3.6: https://koji.fedoraproject.org/koji/buildinfo?buildID=953622)

It looks like the main problem is fixed, thanks a lot! However, the build still fails in some late step:

ERROR - one or more exit plugins failed: plugin 'koji_tag_build' raised an exception: TypeError('Invalid type unicode for argument 1',)

https://koji.fedoraproject.org/koji/taskinfo?taskID=26445345

Although it doesn't prevent the image to be available in the candidate registry.

Still seeing the same issue..

On 25 April 2018 at 08:34, Honza Horak pagure@pagure.io wrote:

hhorak added a new comment to an issue you are following:
Still seeing the same issue..

I ll look at it, today.
Sorry about that

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/455

So we have the following error

2018-04-18 19:59:04,058 platform:- - atomic_reactor.plugin - INFO - running plugin instance with args: '{u'kojihub': u'https://koji.fedoraproject.org/kojihub', u'koji_principal': u'osbs/osbs.fedoraproject.org@FEDORAPROJECT.ORG', u'koji_keytab': u'FILE:/etc/krb5.osbs_osbs.fedoraproject.org.keytab', u'target': u'f28-container-candidate'}'
2018-04-18 19:59:04,059 platform:- - atomic_reactor.koji_util - INFO - Using Kerberos for Koji authentication
2018-04-18 19:59:04,471 platform:- - atomic_reactor.plugin - DEBUG - Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/atomic_reactor/plugin.py", line 238, in run
    plugin_response = plugin_instance.run()
  File "/usr/lib/python2.7/site-packages/atomic_reactor/plugins/exit_koji_tag_build.py", line 88, in run
    session = create_koji_session(self.kojihub, self.koji_auth)
  File "/usr/lib/python2.7/site-packages/atomic_reactor/koji_util.py", line 112, in create_koji_session
    koji_login(session, **auth_info)
  File "/usr/lib/python2.7/site-packages/atomic_reactor/koji_util.py", line 92, in koji_login
    result = session.krb_login(**kwargs)
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2165, in krb_login
    sprinc = krbV.Principal(name=self._serverPrincipal(cprinc), context=ctx)
TypeError: Invalid type unicode for argument 1

This is because the kerberos Principal is passed as an unicode by atomic-reactor and the python-krbV module is expecting a string.

I ll wait for the end of the infra freeze (next week) to test a patch and submit it to upstream.

@cverna: https://github.com/projectatomic/atomic-reactor/pull/860
Me and Adam had a patch written for that, which was in our RPMs before, did that backport get lost?

Also, it shouldn't even get to the krbV codepaths, as that means that gssapi failed.

@puiterwijk Hum, it looks like I removed the patch[0] when upgrading to atomic-reactor 1.6.29 not sure why tho :disappointed:

[0] - https://src.fedoraproject.org/rpms/atomic-reactor/c/fb1219f7abf2bbda6648da59ddf412371ed03d29?branch=master

Also, it shouldn't even get to the krbV codepaths, as that means that gssapi failed.

Looking at koji's code, gssapi fails silently, there is a debug statement here but I am not how I would get that in atomic-reactor

If you make sure that python-krbV is not available, it goes into the "else:", which raises it as an exception.

@hhorak I have rebuilt the buildroot container, if you could try to build your container again to see if the build works.

Thanks

I've successfully built container today, thanks!