Skip to content
Snippets Groups Projects
  1. Apr 21, 2022
  2. Mar 07, 2022
    • John Snow's avatar
      python/aqmp: add start_server() and accept() methods · 481607c7
      John Snow authored
      
      Add start_server() and accept() methods that can be used instead of
      start_server_and_accept() to allow more fine-grained control over the
      incoming connection process.
      
      (Eagle-eyed reviewers will surely notice that it's a bit weird that
      "CONNECTING" is a state that's shared between both the start_server()
      and connect() states. That's absolutely true, and it's very true that
      checking on the presence of _accepted as an indicator of state is a
      hack. That's also very certainly true. But ... this keeps client code an
      awful lot simpler, as it doesn't have to care exactly *how* the
      connection is being made, just that it *is*. Is it worth disrupting that
      simplicity in order to provide a better state guard on `accept()`? Hm.)
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Acked-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-id: 20220225205948.3693480-9-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      481607c7
    • John Snow's avatar
      python/aqmp: refactor _do_accept() into two distinct steps · 5e9902a0
      John Snow authored
      
      Refactor _do_accept() into _do_start_server() and _do_accept(). As of
      this commit, the former calls the latter, but in subsequent commits
      they'll be split apart.
      
      (So please forgive the misnomer for _do_start_server(); it will live up
      to its name shortly, and the docstring will be updated then too. I'm
      just cutting down on some churn.)
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Acked-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-id: 20220225205948.3693480-7-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      5e9902a0
    • John Snow's avatar
      python/aqmp: remove _new_session and _establish_connection · 68a6cf3f
      John Snow authored
      
      These two methods attempted to entirely envelop the logic of
      establishing a connection to a peer start to finish. However, we need to
      break apart the incoming connection step into more granular steps. We
      will no longer be able to reasonably constrain the logic inside of these
      helper functions.
      
      So, remove them - with _session_guard(), they no longer serve a real
      purpose.
      
      Although the public API doesn't change, the internal API does. Now that
      there are no intermediary methods between e.g. connect() and
      _do_connect(), there's no hook where the runstate is set. As a result,
      the test suite changes a little to cope with the new semantics of
      _do_accept() and _do_connect().
      
      Lastly, take some pieces of the now-deleted docstrings and move
      them up to the public interface level. They were a little more detailed,
      and it won't hurt to keep them.
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Acked-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-id: 20220225205948.3693480-4-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      68a6cf3f
    • John Snow's avatar
      python/aqmp: rename 'accept()' to 'start_server_and_accept()' · 0ba4e76b
      John Snow authored
      
      Previously, I had a method named "accept()" that under-the-hood calls
      bind(2), listen(2) *and* accept(2). I meant this as a simplification and
      counterpart to the one-shot "connect()" method.
      
      This is confusing to readers who expect accept() to mean *just*
      accept(2). Since I need to split apart the "accept()" method into
      multiple methods anyway (one of which strongly resembling accept(2)), it
      feels pertinent to rename this method *now*.
      
      Rename this all-in-one method "start_server_and_accept()" instead.
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Acked-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Message-id: 20220225205948.3693480-3-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      0ba4e76b
  3. Feb 23, 2022
    • John Snow's avatar
      Python: add setuptools v60.0 workaround · 762c280d
      John Snow authored
      Setuptools v60 and later include a bundled version of distutils, a
      deprecated standard library scheduled for removal in future versions of
      Python. Setuptools v60 is only possible to install for Python 3.7 and later.
      
      Python has a distutils.sysconfig.get_python_lib() function that returns
      '/usr/lib/pythonX.Y' on posix systems. RPM-based systems actually use
      '/usr/lib64/pythonX.Y' instead, so Fedora patches stdlib distutils for
      Python 3.7 and Python 3.8 to return the correct value.
      
      Python 3.9 and later introduce a sys.platlibdir property, which returns
      the correct value on RPM-based systems.
      
      The change to a distutils package not provided by Fedora on Python 3.7
      and 3.8 causes a regression in distutils.sysconfig.get_python_lib() that
      ultimately causes false positives to be emitted by pylint, because it
      can no longer find the system source libraries.
      
      Many Python tools are fairly aggressive about updating setuptools
      packages, and so even though this package is a fair bit newer than
      Python 3.7/3.8, it's not entirely unreasonable for a given user to have
      such a modern package with a fairly old Python interpreter.
      
      Updates to Python 3.7 and Python 3.8 are being produced for Fedora which
      will fix the problem on up-to-date systems. Until then, we can force the
      loading of platform-provided distutils when running the pylint
      test. This is the least-invasive yet most comprehensive fix.
      
      References:
       https://github.com/pypa/setuptools/pull/2896
       https://github.com/PyCQA/pylint/issues/5704
       https://github.com/pypa/distutils/issues/110
      
      
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Message-id: 20220204221804.2047468-2-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      762c280d
  4. Nov 01, 2021
    • John Snow's avatar
      python: Add iotest linters to test suite · 461044ce
      John Snow authored
      
      Run mypy and pylint on the iotests files directly from the Python CI
      test infrastructure. This ensures that any accidental breakages to the
      qemu.[qmp|aqmp|machine|utils] packages will be caught by that test
      suite.
      
      It also ensures that these linters are run with well-known versions and
      test against a wide variety of python versions, which helps to find
      accidental cross-version python compatibility issues.
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: default avatarHanna Reitz <hreitz@redhat.com>
      Message-id: 20211019144918.3159078-15-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      461044ce
  5. Sep 27, 2021
  6. Jul 01, 2021
  7. Jun 01, 2021
    • John Snow's avatar
      python: add avocado-framework and tests · 31622b2a
      John Snow authored
      
      Try using avocado to manage our various tests; even though right now
      they're only invoking shell scripts and not really running any
      python-native code.
      
      Create tests/, and add shell scripts which call out to mypy, flake8,
      pylint and isort to enforce the standards in this directory.
      
      Add avocado-framework to the setup.cfg development dependencies, and add
      avocado.cfg to store some preferences for how we'd like the test output
      to look.
      
      Finally, add avocado-framework to the Pipfile environment and lock the
      new dependencies. We are using avocado >= 87.0 here to take advantage of
      some features that Cleber has helpfully added to make the test output
      here *very* friendly and easy to read for developers that might chance
      upon the output in Gitlab CI.
      
      [Note: ALL of the dependencies get updated to the most modern versions
      that exist at the time of this writing. No way around it that I have
      seen. Not ideal, but so it goes.]
      
      Provided you have the right development dependencies (mypy, flake8,
      isort, pylint, and now avocado-framework) You should be able to run
      "avocado --config avocado.cfg run tests/" from the python folder to run
      all of these linters with the correct arguments.
      
      (A forthcoming commit adds the much easier 'make check'.)
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Reviewed-by: default avatarCleber Rosa <crosa@redhat.com>
      Tested-by: default avatarCleber Rosa <crosa@redhat.com>
      Message-id: 20210527211715.394144-28-jsnow@redhat.com
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      31622b2a
Loading