#2438 report versions of components
Merged 20 days ago by tkopecek. Opened 2 months ago by tkopecek.
tkopecek/koji issue2430  into  master

file modified
+11
@@ -7654,3 +7654,14 @@ 

          session.deleteNotificationBlock(n_id)

          if not goptions.quiet:

              print(_("Notification block %d successfully removed.") % n_id)

+ 

+ 

+ def handle_version(goptions, session, args):

+     """Report client and hub versions"""

+     ensure_connection(session)

+     print('Client: %s' % koji.__version__)

+     try:

+         version = session.getKojiVersion()

+         print("Hub:    %s" % version)

+     except koji.GenericError:

+         print("Hub:    Can' determine (older than 1.23)")

file modified
+4 -3
@@ -13,7 +13,7 @@ 

  # serve to show the default.

  

  #import sys

- #import os

+ import os

  

  # If extensions (or modules to document with autodoc) are in another directory,

  # add these directories to sys.path here. If the directory is relative to the
@@ -53,10 +53,11 @@ 

  # |version| and |release|, also used in various other places throughout the

  # built documents.

  #

+ exec(open(os.path.join(os.path.dirname(__file__), '../../koji/_version.py'), 'rt').read())

  # The short X.Y version.

- version = '1.22'

+ version = '%d.%d' % locals()['__version_info__'][:2]

  # The full version, including alpha/beta/rc tags.

- release = '1.22.1'

+ release = locals()['__version__']

  

  # The language for content autogenerated by Sphinx. Refer to documentation

  # for a list of supported languages.

file modified
+3
@@ -10278,6 +10278,9 @@ 

      def echo(self, *args):

          return args

  

+     def getKojiVersion(self):

+         return koji.__version__

+ 

      def getAPIVersion(self):

          return koji.API_VERSION

  

file modified
+3
@@ -62,6 +62,9 @@ 

  

  from koji.xmlrpcplus import Fault, dumps, getparser, loads, xmlrpc_client

  from . import util

+ from . import _version

+ __version__ = _version.__version__

+ __version_info__ = _version.__version_info__

  

  SSL_Error = None

  try:

file added
+2
@@ -0,0 +1,2 @@ 

+ __version_info__ = (1, 22, 1)

+ __version__ = '.'.join([str(x) for x in __version_info__])

file modified
+6 -1
@@ -30,9 +30,14 @@ 

      return requires

  

  

+ def get_version():

+     exec(open('koji/_version.py', 'rt').read())

+     return(locals()['__version__'])

+ 

+ 

  setup(

      name="koji",

-     version="1.22.1",

+     version=get_version(),

      description=("Koji is a system for building and tracking RPMS. The base"

                   " package contains shared libraries and the command-line"

                   " interface."),

@@ -122,6 +122,7 @@ 

          dist-repo                 Create a yum repo with distribution options

          import-comps              Import group/package information from a comps file

          moshimoshi                Introduce yourself

+         version                   Report client and hub versions

  

  monitor commands:

          add-notification          Add user's notification

file modified
+2 -1
@@ -1,6 +1,7 @@ 

  #include "includes/header.chtml"

+ #import koji

  

- <h4>API reference</h4>

+ <h4>API reference <small>(hub version: $koji_version, web version: $koji.__version__)</small></h4>

  

  <ul>

  #for method in $methods

file modified
+4
@@ -2485,6 +2485,10 @@ 

      server = _getServer(environ)

  

      values['methods'] = sorted(server._listapi(), key=lambda x: x['name'])

+     try:

+         values['koji_version'] = server.getKojiVersion()

+     except koji.GenericError:

+         values['koji_version'] = "Can't determine (older then 1.23)"

  

      return _genHTML(environ, 'api.chtml')

  

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.

rebased onto 5ccea64dcec2de0886b0512daaf4b4ceb1dc7d31

2 months ago

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

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

2 months ago

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

2 months ago

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

Metadata Update from @mikem:
- Pull-request tagged with: discussion

2 months ago

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.

rebased onto 432566d

a month ago

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/

1 new commit added

  • update version
a month ago

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

a month ago

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

a month ago

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

a month ago

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.

rebased onto f54d1f5

20 days ago

1 new commit added

  • flake8 fix
20 days ago

Commit e8119e5 fixes this pull-request

Pull-Request has been merged by tkopecek

20 days ago