config/sysinv/sysinv/sysinv/sysinv/tests
Tyler Smith f69b131294 Changes to stx-openstack application automatic re-apply behaviour
The stx-openstack application is no longer automatically reapplied
on node unlock. The new behaviour is handled with a reapply flag:

 - When a node is unlocked, or a runtime manifest is applied,
   overrides are regenerated and compared to
   their old values.  If there is a difference a reapply flag is raised
   along with a warning alarm
 - A check was added to the kubernetes audit in the sysinv conductor
   to check if the reapply flag has been raised and to trigger a reapply
   if the system is in a stable state (no hosts currently
   locking/unlocking/booting)
 - This check is also done when a runtime manifest reports success

Test cases:
AIO-SX, AIO-DX, and Standard:
 - When a lock/unlock is done with no changes the application is
   not reapplied
 - When a lock/unlock is done after a config change is made the
   application waits until after the unlock and then triggers a reapply
STANDARD
 - Enabled ceph-rgw chart and ensured that the application was reapplied upon
   config success (likewise for chart disable)
 - If there is a pending reapply, and the user triggers it before the
   system is stable the reapply flag and alarm are removed
 - Provisioning a new compute node and unlocking it for the
   first time triggers an application reapply after it comes online
 - App is reapplied when a node is deleted
 - Compute added without node labels and unlocked results in no reapply
 - Compute locked, labels applied, then unlocked results in a reapply
   pods launch on compute only when labels present (likewise for label removal)
 - Pending reapply flag and alarm persist over a controller swact

Change-Id: I1ae9fdc2afcdf831cf0e7d96f8af14fcb5f6b579
Closes-Bug: 1837750
Depends-On: https://review.opendev.org/#/c/678232
Signed-off-by: Tyler Smith <tyler.smith@windriver.com>
(cherry picked from commit b1895200a4)
2019-08-23 13:54:52 +00:00
..
api Changes to stx-openstack application automatic re-apply behaviour 2019-08-23 13:54:52 +00:00
conductor Fix: "asserts" issue for Python 2/3 compatible code 2018-12-19 10:19:08 +08:00
db Create host state for determining initial inventory complete 2019-07-30 11:13:56 -04:00
objects Create basic set of unit tests for sysinv ihosts API 2019-07-24 11:35:15 -05:00
puppet Initial framework and unit tests for puppet plugins 2019-07-24 09:08:52 -04:00
README.txt Create basic set of unit tests for sysinv ihosts API 2019-07-24 11:35:15 -05:00
__init__.py Fix: "__builtin__" issue for Python 2/3 compatible code 2018-12-19 10:21:57 +08:00
base.py Application update support 2019-06-07 12:29:14 -04:00
conf_fixture.py StarlingX open source release updates 2018-05-31 07:35:52 -07:00
events_for_testing.yaml Removal of infrastructure network code 2019-05-06 16:57:10 -04:00
fake_policy.py StarlingX open source release updates 2018-05-31 07:35:52 -07:00
keyring_fixture.py Initial framework and unit tests for puppet plugins 2019-07-24 09:08:52 -04:00
matchers.py Enable Bad String Formatting Linting 2019-07-17 14:36:37 -04:00
policy.json StarlingX open source release updates 2018-05-31 07:35:52 -07:00
policy_fixture.py StarlingX open source release updates 2018-05-31 07:35:52 -07:00
stubs.py Fix: "map" issue for Python 2/3 compatible code 2018-12-18 11:03:00 +08:00
test_dbsync.py StarlingX open source release updates 2018-05-31 07:35:52 -07:00
test_images.py Enable python3.5 sysinv unit test 2019-01-30 08:51:07 +08:00
test_sysinv_deploy_helper.py Enable python3.5 sysinv unit test 2019-01-30 08:51:07 +08:00
test_utils.py Cleanup keystone service parameters 2019-07-09 09:01:34 -05:00
utils.py Fix: "dict" issue for Python 2/3 compatible code 2018-12-18 11:03:00 +08:00

README.txt

This file discusses the current status of sysinv tests and areas where issues
still exist and what to do in order to test them.

--------------------------------------------------------------------------------
RUNNING TESTS:

To actually run the tests, in console navigate to
$MY_REPO/stx/stx-config/sysinv/sysinv/sysinv

On your first ever run of tox tests enter:
tox --recreate -e py27
This will make sure tox's environment is fresh and fully built.

To test both py27 (the actual unit tests), and check the flake8 formatting:
tox

You can also run both py27 and flake8 by entering the following instead:
tox -e flake8,py27
The above order of environments matters. If py27 comes first, flake8 won't run.

To run either individually enter:
tox -e py27
tox -e flake8

--------------------------------------------------------------------------------
RUNNING TESTS WITH POSTGRESQL:

The default behaviour is to run the sysinv tests with the mySQL database. This
should be fine in most cases.

If you really want to test with postgreSQL, in a local Ubuntu VM or similar:
- go to test_migrations.py and in the function
  test_postgresql_opportunistically, comment out the self.skipTest line to
  enable the test to be run.
- Also go to the function test_postgresql_connect_fail and comment out the
  self.skipTest line so that test can be run as well.
- Lastly, in the function _reset_databases, go to the bottom and uncomment
  self._reset_pg(conn_pieces) so the postgres DB can be reset between runs.
  If this last line is not uncommented, your first run of the py27 tests will
  work, but after that you will get
  migrate.exceptions.DatabaseAlreadyControlledError

Do not push these lines uncommented upstream to the repo.

To set up the postgres db for the first time enter the following in console:
sudo apt-get install postgresql postgresql-contrib
pip install psycopg2

sudo -u postgres psql
CREATE USER openstack_citest WITH CREATEDB LOGIN PASSWORD 'openstack_citest';
CREATE DATABASE openstack_citest WITH OWNER openstack_citest;
\q

--------------------------------------------------------------------------------
OUTSTANDING ISSUES:

tests/api/test_acl.py
    test_authenticated
        Fails due HTTPS connection failure as a result of an invalid user token
        which causes webtest.app.AppError:
        Bad response: 401 Unauthorized 'Authentication required'

    test_non_admin
        Fails due to invalid user token resulting in
        raise mismatch_error testtools.matchers._impl.MismatchError: 401 != 403
        Occurs against Www-Authenticate: Keystone uri='https://127.0.0.1:5000'

    test_non_admin_with_admin_header
        Fails due to invalid user token resulting in
        raise mismatch_error testtools.matchers._impl.MismatchError: 401 != 403

tests/conductor/test_manager.py
    test_configure_ihost_new
        IOError: [Errno 13] Permission denied: '/tmp/dnsmasq.hosts'
        This directory does not exist. I am not sure if this directory is
        still supposed to exist, if it has moved, or if this entire test is
        based on deprecated/replaced functionality.

    test_configure_ihost_no_hostname
        os.rename(temp_dnsmasq_hosts_file, dnsmasq_hosts_file)
        OSError: [Errno 1] Operation not permitted
        Fails because the dnsmasq files don't exist.

    test_configure_ihost_replace
        IOError: [Errno 13] Permission denied: '/tmp/dnsmasq.hosts'
        This dnsmasq file doesn't exist. Same issue as in the first test.

There also exists the issue of using postgres for db migrations in
tests/db/sqlalchemy/test_migrations.py. The issue with this is that these
migrations can only be run on local VMs such as Ubuntu, and not on the build
servers or on Jenkins because it would require that someone manually set up
the database on those systems, and the issue with putting it on the build server
is that because there presently exist no ways of getting postgres running in a
virtual environment (e.g. tox's), it must be set up on the actual system. This
means that multiple people running these tests at the same time would interact
with the same db and could run into issues. The reason postgres is being used
is because between versions, some columns of enumerated types are being altered
and SQLite doesn't support ALTER COLUMN or ALTER TABLE functionality. Alembic
and sqlalchemy-migrate offer solutions to this, but presently there is no
intention to incorporate either of these packages.

--------------------------------------------------------------------------------
TESTING DECISIONS:

We've chosen to use flake8 instead of PEP8 because PEP8 results in a lot more
insignificant issues being found, and flake8 combines PEP8 with PyFlakes which
combines code formatting with syntax and import checking, additionally, flake8
provides the option to test code complexity and return warnings if the
complexity exceeds whatever limit you've set.

--------------------------------------------------------------------------------