Reasoning for resources dict - I plan to use it for heteregenous information about builder. Basics would be number of cpus, free memory and disk in given time (for new planner). I was thinking about separate option for each of these, but it looks that there could be potentially a lot of random resources (access to network, capability to spawn VMs, mounted filesystems, etc.) so dictionary seems to be better suited for this. Anyway, think about this (@mikem)

Does that make sense to make the builder's koji_version versioned(moved to host_config)?
It is currently useless for buildroot, but it is a key factor of the build environment and worthy to track.

It is questionable. While user can setup all other values, this is just reported value from builder. Not sure about it.

Anyway that is trivial thing currently, and we can have a follow-up later
:thumbsup:

There is a lot to think about here. Please do not merge this until we have clearly sorted things out.

Reasoning for resources dict - I plan to use it for heteregenous information about builder.

While I appreciate the forward thinking of this, I really don't like the asymmetry in how the host fields in the db are handled. The task_load and ready values are both call args and table fields, while version is also a table field, but buried in this resources parameter. The code consequently seems awkward dealing with this asymmetry.

If we expand resources in the future, will all its fields correspond fields in the host table? If so, that seems like it works against the convenience of bundling this data in a dict. If not, then that seems like a potential mess of special cases.

The host version part of this PR is the trickiest part of this and not actually requested in #2430. It might be best to leave this part out for now and give ourselves more time to think about how we should handle it.

The API_VERSION in koji has never been updated and it's not clear how we want to handle updating it. I'm not sure I want to make it more visible (also seems little odd to add this in the web and nowhere else).

It might be best to leave that out for now to and have a larger discussion about where this field goes from here.

https://pagure.io/fork/tkopecek/koji/commits/scheduler is the build->hub task logic rewrite which uses host fields for storing actual cpu/memory values.

/dropped host info meanwhile/

Thanks, much simpler.

This looks fine, but the cli should handle talking to an older hub.

Traceback (most recent call last):
  File "/home/mikem/Devel/koji/koji/cli2/lkoji", line 337, in <module>
    rv = locals()[command].__call__(options, session, args)
  File "/home/mikem/Devel/koji/koji/cli/koji_cli/commands.py", line 7635, in handle_version
    print('Hub:    %s' % session.getKojiVersion())
  File "/home/mikem/Devel/koji/koji/koji/__init__.py", line 2343, in __call__
    return self.__func(self.__name, args, opts)
  File "/home/mikem/Devel/koji/koji/koji/__init__.py", line 2770, in _callMethod
    raise err
koji.GenericError: Invalid method: getKojiVersion

I'd expect it to tell the user it can't determine rather than dump an exception. New client + old hub is a common case, and one which this feature is intended for.

Similarly, the web ui change will also raise an exception talking to an old hub. That's less of a concern since we recommend keeping the web and hub versions in sync. However, it's easy enough to be friendly about it here.

Commit e8119e52 fixes this pull-request