two commits for koji uploading and python2

[cgwalters]

Only make check tested.

[cgwalters]

This only partially helps, next stumbling block is:

walters@toolbox /v/s/w/s/g/c/coreos-assembler> ./src/cmd-koji-upload 
Traceback (most recent call last):
  File "./src/cmd-koji-upload", line 47, in <module>
    from cosalib.build import _Build
  File "/var/srv/walters/src/github.com/coreos/coreos-assembler/src/cosalib/build.py", line 14, in <module>
    from cmdlib import Builds
  File "/var/srv/walters/src/github.com/coreos/coreos-assembler/src/cmdlib.py", line 13, in <module>
    import semver
ImportError: No module named semver

Pushed another commit to deal with that...

Bigger picture we are going to be fighting seriously uphill because Fedora is trying to drop Python 2.

It's also going to be a drag on everyone else as no one else (including FCOS as of this writing AFAIK) is importing builds to koji.

[cgwalters]

The more I think about this, the more I feel like the Koji importer should be a separate container that runs a separate control loop distinct from the primary cosa build.

IOW, we have a separate app which does

loop {
  latest_koji = query_koji_for_last_build()
  latest_cosa_build = curl_builds_json()
  if latest_koji != latest_cosa_build {
    upload_to_koji()
  }
}

or so. We only import to Koji successful builds, etc.

[cgwalters]

Perhaps better as a container triggered from a jenkins job, then we can change the rhcos pipeline to edge trigger the koji upload job when the primary build is done, also it can be on a timer for robustness/eventual-consistency.

[cgwalters]

If no one has an opinion on this by tomorrow...I'll probably proceed with #720 (comment)

[cgwalters]

OK so there's 3 options:

1. Fix the koji/kerberos stuff to work with Python 3 (preferred)
2. Try to have all of the code imported by cmd-koji-upload to be dual 2/3 compat (ick)
3. Move it to a separate container/job (this comment)

I did some work on option 3...it's not going to be a trivial change, but it does seem like a better long term architecture, particularly if we view Koji as a best-effort backup and not a source of truth.

That said, does anyone (@darkmuggle ?) have more information on the bugs in option 1?

[cgwalters]

Hm sorry I hadn't been paying close attention and I just remembered Ben is out. Resolving this can probably wait till he's back.

[ashcrow]

👍

[ashcrow]

👍

[ashcrow]

I think we disable flake8 checking for imports within code so this should be fine. I am personally a fan of importing optional items when needed like this 👍

[ashcrow]

LGTM overall. There is one test that is failing though.

[cgwalters]

I don't think we should ship this though, trying to be dual python2/3 would be really painful and IMO argue against using Python at all (aside from e.g. the koji uploader, as AFAIK Koji only has a python library). We should pick among the options here #720 (comment)

[darkmuggle]

@cgwalters before I went on holiday, I found that there might be a path to make the Koji importer work with Py3. I would love nothing more than to port to Py3.

Can you give me a day or two to flesh that out?

[cgwalters]

Yeah of course! I am happy to help.

[cgwalters]

This is obsoleted by #729