The change updates the imports to use simplejson instead of ujson and
monasca_log_api.common.rest instead of monasca_common.rest
Temporarily set monascalog-python3-tempest as voting false
This is an alternative to this change
https://review.opendev.org/#/c/724658/
Change-Id: Iae94376b38cae8a1eb8aa6a704fc2ca5d383adaf
Story: 2007549
Task: 39601
Use rpartition instead of replace to do a more targeted stripping of
path to render a correct base_uri.
Change-Id: Idc2a5a6bd0e9e2675883f2188d4856b01ba5fdb8
Story: 2006147
Task: 35643
Falcon 2.0.0 introduces some breaking changes. The relevant ones here are:
- falcon.testing.TestCase.api property was removed
- falcon.testing.TestBase class was removed
- falcon.HTTPRequestEntityTooLarge exception was renamed to
falcon.HTTPPayloadTooLarge
Additionally, the default behaviour for handling trailing slashes on
URIs also changed:
https://falcon.readthedocs.io/en/latest/user/faq.html#how-does-falcon-
handle-a-trailing-slash-in-the-request-path
This commit adds support for using the new release.
Story: 2005695
Task: 33474
Change-Id: I2379522efef81b919098a0143b66cc259a184e70
Added policies and used policy enforcement engine
from monasca-common.
- Updated role_middleware to remove authorization into the routes.
- Updated unit tests and implemented some new tests.
- Added a new entry point for generating sample policy file by tox.
story: 2001233
task: 22086
Change-Id: I3d199fac244eca94fc434d19c78bc5a17e804c37
Signed-off-by: Amir Mofakhar <amofakhar@op5.com>
The builtin type 'unicode' does not exist under python 3. The runtime
check here is already looking at the python version, but the linter
does not perform the same check and it fails because the name is not
defined. Replace the explicit use of unicode here with six.text_type
so that the linter is happy.
Change-Id: I22a13fddaed1338c0f3e670d199bb6aa5f99bbf7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
* Partial revert of 0a82af18ab
to restore main() method
* Add global `application` variable which will be set by main method to
problem to preserve the fix from 0a82af18ab.
* Add check for application name starting with '_mod_wsgi' to ensure
application runs in Devstack as well (Devstack does not use the entry point)
* Modify Devstack plugin to run WSGI entry point rather than app/wsgi.py from
module directory.
Change-Id: I07001dccb663ed4e6e3347089ab96e6f8ec196d4
Story: 2001197
Task: 5702
Old project tree had everything mixed up
in different locations. Not to mention
that actual REST controllers resided in
package that's name did not reflect the content.
Reorganized the tree to be more predictable
and easier to maintain.
Change-Id: Ic9acc80a4cf7416394702d43141c96953c03beea
Passing any CLI arguments to log-api is not possible
for the case where it runs under gunicorn server.
Gunicorn's argument parsing processes clashes with oslo's.
Effectivelly that means that either of them cannot understand
the arguments of another. However log-api is capable of being launched
under, for example, apache_mod-wsgi.
That permits passing oslo CLI arguments.
Added simple method that detect the executable that was used to run
log-api. If that is not gunicorn, CLI opts will be enabled.
Otherwise log-api will print out warning and proceed as it was.
Extra:
* reworked to use fixtures
Change-Id: I6b2fc386aeb823ab735270ffc1d3f7e15985830f
It is common for OpenStack projects to use oslo-config-generator to generate
a sample config file which contains all available configuration options.
Work items:
* removed etc/monasca/log-api.conf (it is autogenerated)
* keep all config in one place to mimic the configuration file
* added configuration files to documentation
Story: 2000970
Task: 4121
Change-Id: I8777ed6cd38739e87b19be248b9c120e84626ad1
Currently mod_wsgi returns the following error:
Target WSGI script '/var/www/monasca-log-api/monasca_log_api'
does not contain WSGI application 'application'.
Also fix a type in README.
Change-Id: Ic70c3ddb8aaa076c09fc2434f6e890be24b599d5
Following commit introduces using composite
paste file to describe application pipelines.
With the help of composite feature it was possible to
define 4 distinct supapplications, each having different
pipeline setup:
* version_app => no keystoneauth, simple data return with error trap
* healthcheck_app => no keystoneauth, simple data return with error trap
* api_v2 => as it was, added error_trap though
* api_v3 => as it was, added error_trap though
Following approach opens up the possibilities of modelling an API
in far more flexible way and removes the need of any hacking inside
the codebase.
Note:
Keeps backward compatibility with older codebase.
Extra:
* removed dirty hack around skipping certain request.path
in keystonemiddleware (now described in paste file)
* removed 404 when issuing ```curl api_host:api_port/```. Request
is redirected down to VersionApp
Depends-On: I0323eacb5cbba8418550e3322189104c35cf4c36
Change-Id: I873e1376665c8cf66c8ee503975324f9b93ddb45
Martin Chacon Piza