Go to file
Craig Bryant 493267eff1 Restrict changes to existing Alarm Definitions
Once an Alarm Definition has been created, match_by and any metrics
in the expression cannot be changed. This is because those fields
control the metrics used to create Alarms and Alarms may already
have been created. The function, operator, period, periods and any
boolean operators can change, but not the metrics in subexpressions
or of the number sub expressions.  All other fields in an Alarm
Definition can be changed

Add tests for new functionality and some old for patch and update

Fix a bug where match-by was being cleared in patch if not given

Update api docs for the restrictions

Fix minor typos in api docs

Change-Id: I89a46838847b9cb73a073f9dd91db8f9391b6019
2015-01-13 12:41:00 -07:00
2014-12-04 14:07:28 -05:00
2014-09-15 13:18:10 -04:00
2014-09-15 13:18:10 -04:00
2014-07-15 15:35:50 -06:00
2014-09-15 13:18:10 -04:00
2014-09-15 13:18:10 -04:00
2014-05-01 16:22:11 -07:00
2014-12-11 11:40:29 -07:00
2014-12-04 14:07:28 -05:00
2014-09-15 13:18:10 -04:00
2014-11-17 15:38:47 -07:00

Overview

monasca-api is a RESTful API server that is designed with a layered architecture layered architecture.

The full API Specification can be found in docs/monasca-api-spec.md

Build

Requires monasca-common from https://github.com/stackforge/monasca-common. Download and do mvn install.

mvn clean install

Usage

java -jar target/monasca-api.jar server config-file.yml

Keystone Configuration

For secure operation of the Monasca API, the API must be configured to use Keystone in the configuration file under the middleware section. Monasca only works with a Keystone v3 server. The important parts of the configuration are explained below:

  • serverVIP - This is the hostname or IP Address of the Keystone server
  • serverPort - The port for the Keystone server
  • useHttps - Whether to use https when making requests of the Keystone API
  • truststore - If useHttps is true and the Keystone server is not using a certificate signed by a public CA recognized by Java, the CA certificate can be placed in a truststore so the Monasca API will trust it, otherwise it will reject the https connection. This must be a JKS truststore
  • truststorePassword - The password for the above truststore
  • connSSLClientAuth - If the Keystone server requires the SSL client used by the Monasca server to have a specific client certificate, this should be true, false otherwise
  • keystore - The keystore holding the SSL Client certificate if connSSLClientAuth is true
  • keystorePassword - The password for the keystore
  • defaultAuthorizedRoles - An array of roles that authorize a user to access the complete Monasca API. User must have at least one of these roles. See below
  • agentAuthorizedRoles - An array of roles that authorize only the posting of metrics. See Keystone Roles below
  • adminAuthMethod - "password" if the Monasca API should adminUser and adminPassword to login to the Keystone server to check the user's token, "token" if the Monasca API should use adminToken
  • adminUser - Admin user name
  • adminPassword - Admin user password
  • adminToken - A valid admin user token if adminAuthMethod is token
  • timeToCacheToken - How long the Monasca API should cache the user's token before checking it again

Keystone Roles

The Monasca API has two levels of access:

Full access - user can read/write metrics and Alarm Definitions and Alarms

Agent access - user can only write metrics

The reason for the "Agent access" level is because the Monasca Agent must be configured to use a Keystone user. Since the user and password are configured onto the all of the systems running the Monasca Agent, this user is most in danger of being compromised. If this user is limited to only writing metrics, then the damage can be limited.

To configure the user to have full access, the user must have a role that is listed in defaultAuthorizedRoles. To configure a user to have only "Agent access", the user must have a role in agentAuthorizedRoles and none of the roles in defaultAuthorizedRoles.

Design Overview

Architectural layers

Requests flow through the following architectural layers from top to bottom:

  • Resource
    • Serves as the entrypoint into the service.
    • Responsible for handling web service requests, and performing structural request validation.
  • Application
    • Responsible for providing application level implementations for specific use cases.
  • Domain
    • Contains the technology agnostic core domain model and domain service definitions.
    • Responsible for upholding invariants and defining state transitions.
  • Infrastructure
    • Contains technology specific implementations of domain services.

Documentation

python monasca api implementation

To install the python api implementation, git clone the source and run the following command::

sudo python setup.py install

If it installs successfully, you will need to make changes to the following two files to reflect your system settings, especially where kafka server is located::

/etc/monasca/monasca.ini
/etc/monasca/monasca.conf

Once the configurations are modified to match your environment, you can start up the server by following the following instructions.

To start the server, run the following command:

Running the server in foreground mode
gunicorn -k eventlet --worker-connections=2000 --backlog=1000
         --paste /etc/monasca/monasca.ini

Running the server as daemons
gunicorn -k eventlet --worker-connections=2000 --backlog=1000
         --paste /etc/monasca/monasca.ini -D

To check if the code follows python coding style, run the following command from the root directory of this project

tox -e pep8

To run all the unit test cases, run the following command from the root directory of this project

tox -e py27   (or -e py26, -e py33)

License

Copyright (c) 2014 Hewlett-Packard Development Company, L.P.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Description
RETIRED, Monasca Events REST API
Readme 3.3 MiB
Languages
Python 76.6%
Shell 23.4%