koji

Clone

#2438 report versions of components
Merged 3 years ago by tkopecek. Opened 3 years 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."),

file modified
+1 
@@ -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)
Edited 3 years ago by tkopecek

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.

Edited 3 years ago by julian8628

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

rebased onto 5ccea64dcec2de0886b0512daaf4b4ceb1dc7d31
3 years 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
3 years ago

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done
3 years 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
3 years 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 432566d00a0f115259c75ed8da1840fd5edb43af
3 years 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
3 years ago

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

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

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done
3 years 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
3 years ago

1 new commit added

  • flake8 fix
3 years ago

Commit e8119e5 fixes this pull-request

Pull-Request has been merged by tkopecek
3 years ago
Changes Summary 9
+11 -0
file changed
cli/koji_cli/commands.py
+4 -3
file changed
docs/source/conf.py
+3 -0
file changed
hub/kojihub.py
+3 -0
file changed
koji/__init__.py
+2
file added
koji/_version.py
+6 -1
file changed
setup.py
+1 -0
file changed
tests/test_cli/data/list-commands.txt
+2 -1
file changed
www/kojiweb/api.chtml
+4 -0
file changed
www/kojiweb/index.py
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.