monasca-log-api

Commit Graph

Author	SHA1	Message	Date
Martin Chacon Piza	91022f3e80	Remove project content on master branch This is step 2b of repository deprecation process as described in [1]. [1] https://docs.openstack.org/project-team-guide/repository.html#step-2b-remove-project-content Change-Id: Ie446c1cd447789d189a9e723fff9ee783dd3cf4f	2021-02-22 14:57:15 +01:00
Tomasz Trębski	5e7ebdd9c5	Composite paste for monasca-log-api 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	2017-06-02 14:20:43 +00:00

Author

SHA1

Message

Date

Martin Chacon Piza

91022f3e80

Remove project content on master branch

This is step 2b of repository deprecation process as described in [1].

[1] https://docs.openstack.org/project-team-guide/repository.html#step-2b-remove-project-content

Change-Id: Ie446c1cd447789d189a9e723fff9ee783dd3cf4f

2021-02-22 14:57:15 +01:00

Tomasz Trębski

5e7ebdd9c5

Composite paste for monasca-log-api

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

2017-06-02 14:20:43 +00:00

2 Commits