Re: [openstack-dev] [Monasca] Where Monasca stores collected Data?

[Bedyk, Witold]

Hi Amal,

please check if you collect and persist the measurements correctly.
Check agent forwarder logs.
Check the logs of API, with DEBUG log level you should see all the messages 
sent to Kafka.
Check persister logs. You should see information about consuming messages from 
`metrics` topic.

Hope it helps
Witek

From: amal kammoun 
Sent: Donnerstag, 25. Oktober 2018 17:10
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] Where Monasca stores collected Data?

Hello Monasca team,

I'm experiencing several problems with monasca.
I have Monasca running with OpenStack.
I added alarms to my system but I cannot see where monasca stores the collected 
data.
With Grafana I cannot see any datapoints from the influxdb datasource.
In the influxdb I have all the tables with the measurments that monasca will 
collect but with no vlues.

How can I fix this problem?

Thank you!
Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Where Monasca stores collected Data?

[amal kammoun]

Hello Monasca team,

I'm experiencing several problems with monasca.
I have Monasca running with OpenStack.
I added alarms to my system but I cannot see where monasca stores the
collected data.
With Grafana I cannot see any datapoints from the influxdb datasource.
In the influxdb I have all the tables with the measurments that monasca
will collect but with no vlues.

How can I fix this problem?

Thank you!
Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][tc] Seeking feedback on the OpenStack cloud vision

[Zane Bitter]

Greetings, Monasca team!
As you may be aware, I've been working with other folks in the community 
on documenting a vision for OpenStack clouds (formerly known as the 
'Technical Vision') - essentially to interpret the mission statement in 
long-form, in a way that we can use to actually help guide decisions. 
You can read the latest draft here: https://review.openstack.org/592205


We're trying to get feedback from as many people as possible - in many 
ways the value is in the process of coming together to figure out what 
we're trying to achieve as a community with OpenStack and how we can 
work together to build it. The document is there to help us remember 
what we decided so we don't have to do it all again over and over.


The vision is structured with two sections that apply broadly to every 
project in OpenStack - describing the principles that we believe are 
essential to every cloud, and the ones that make OpenStack different 
from some other clouds. The third section is a list of design goals that 
we want OpenStack as a whole to be able to meet - ideally each project 
would be contributing toward one or more of these design goals.


Monasca is a project that has both user-facing and operator-facing 
functions, so it straddles the border of the scope of the vision 
document (which, to be clear, is not the same as the scope of OpenStack 
itself). The user-facing part is covered by the vision, and would 
probably fit under the 'Customisable Integration' design goal. I think 
the design principle for Monasca to be aware of here, as I mentioned at 
the PTG, is that alarms should work in such a way that it is up to the 
user where to direct them to - it could be autoscaling in Heat, 
autoscaling in Senlin, or something else that is completely 
application-specific.


If you would like me or another TC member to join one of your team IRC 
meetings to discuss further what the vision means for your team, please 
reply to this thread to set it up. You are also welcome to bring up any 
questions in the TC IRC channel, #openstack-tc - there's more of us 
around during Office Hours 
(https://governance.openstack.org/tc/#office-hours), but you can talk to 
us at any time.


Feedback can also happen either in this thread or on the review 
https://review.openstack.org/592205


If the team is generally happy with the vision as it is and doesn't have 
any specific feedback, that's cool but I'd like to request that at least 
the PTL leave a vote on the review. It's important to know whether we 
are actually developing a consensus in the community or just talking to 
ourselves :)


many thanks,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] [monasca-Agent] Monasca agent problem

[Bedyk, Witold]

Hi Amal,

I guess, the mailing list doesn’t accept attachments.

Could you please check if you’re using the right project? Monasca is 
multi-tenant and stores all the measurements and alarm definitions per project. 
If alarm definition is created, let’s say for project ‘admin’ and the agent is 
configured to send the measurements for project ‘customer1’, the alarm won’t 
get triggered in either of them.

Best regards
Witek


From: amal kammoun 
Sent: Montag, 8. Oktober 2018 12:03
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] [monasca-Agent] Monasca agent problem

Hello,

I have an issue with the monasca Agent.
In fact, I installed monasca with Openstack using devstack.
I want to minitor now the instances deployed using Openstack. For that I 
installed on each instance the monasca agent with the following link: 
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md
The problem is that I cannot define alarms for the concerned instance.
Example on my agent:
[image.png]

On my monitoring system I found the alam defintion but it is not activated. 
also the instance on where the agent is running is not declared as a server on 
the monasca servers list.

Regards,
Amal Kammoun.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] [monasca-Agent] Monasca agent problem

[amal kammoun]

Hello,

I have an issue with the monasca Agent.
In fact, I installed monasca with Openstack using devstack.
I want to minitor now the instances deployed using Openstack. For that I
installed on each instance the monasca agent with the following link:
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md
The problem is that I cannot define alarms for the concerned instance.
Example on my agent:
[image: image.png]

On my monitoring system I found the alam defintion but it is not activated.
also the instance on where the agent is running is not declared as a server
on the monasca servers list.

Regards,
Amal Kammoun.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Monasca agent problem

[amal kammoun]

Hello,

I have an issue with the monasca Agent.
In fact, I installed monasca with Openstack using devstack.
I want to minitor now the instances deployed using Openstack. For that I
installed on each instance the monasca agent with the following link:
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md
The problem is that I cannot define alarms for the concerned instance.
Example on my agent:
[image: image.png]

On my monitoring system I found the alam defintion but it is not activated.
also the instance on where the agent is running is not declared as a server
on the monasca servers list.

Regards,
Amal Kammoun.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Berlin Forum brainstorming

[Bedyk, Witold]

Hi everyone,

As discussed in the team meeting yesterday I've created a brainstorming 
etherpad [1] for the Forum in Berlin.
Please add your ideas and add your name to the list if you're interested in 
participating.

Thanks
Witek

[1] https://etherpad.openstack.org/p/berlin-monasca-forum-brainstorming

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca]

[Bedyk, Witold]

Hi Amal,


The status buttons in the monitoring tab correspond to the alarm states for a 
given service or node. After installing devstack plugin no alarms are defined 
yet. You have to do it manually and alarms should appear.


Take care

Witek



From: amal kammoun 
Sent: Monday, September 10, 2018 10:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [monasca]

Hello,

I'm using devstack to have openstack. I installed also monasca using the 
following link: https://github.com/openstack/monasca-api/tree/master/devstack

The problem is that when I log in from horizon, The openstack services and 
servers are empty on the monitoring tab.

What should I do in order to get information about all my openstack servers and 
services?

Thank you!

Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca]

[amal kammoun]

Hello,

I'm using devstack to have openstack. I installed also monasca using the
following link:
https://github.com/openstack/monasca-api/tree/master/devstack

The problem is that when I log in from horizon, The openstack services and
servers are empty on the monitoring tab.

What should I do in order to get information about all my openstack servers
and services?

Thank you!

Amal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][goal][python3] monasca's zuul migration is only partially complete

[Doug Szumski]

On 23/08/18 13:34, Doug Hellmann wrote:

Excerpts from Doug Szumski's message of 2018-08-23 09:53:35 +0100:


Thanks Doug, we had a discussion and we agreed that the best way to
proceed is for you to submit your patches and we will carefully review them.

I proposed those patches this morning. With the aid of your exemplary
repository naming conventions, you can find them all at:

https://review.openstack.org/#/q/topic:python3-first+project:%255E.*monasca.*+is:open

Thanks, we will start going through them.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][goal][python3] monasca's zuul migration is only partially complete

[Doug Hellmann]

Excerpts from Doug Szumski's message of 2018-08-23 09:53:35 +0100:

> Thanks Doug, we had a discussion and we agreed that the best way to 
> proceed is for you to submit your patches and we will carefully review them.

I proposed those patches this morning. With the aid of your exemplary
repository naming conventions, you can find them all at:

https://review.openstack.org/#/q/topic:python3-first+project:%255E.*monasca.*+is:open

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][goal][python3] monasca's zuul migration is only partially complete

[Doug Szumski]

Reply in-line.


On 23/08/18 00:32, Doug Hellmann wrote:

Monasca team,

It looks like you have self-proposed some, but not all, of the
patches to import the zuul settings into monasca repositories.

I found these:

+-++--++-+---+
| Subject | Repo
   | Tests | Workflow   | URL | Branch  
  |
+-++--++-+---+
| Removed dependency on supervisor| openstack/monasca-agent 
   | VERIFIED | MERGED | https://review.openstack.org/554304 | master   
 |
| fix tox python3 overrides   | openstack/monasca-agent 
   | VERIFIED | MERGED | https://review.openstack.org/574693 | master   
 |
| fix tox python3 overrides   | openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/572970 | master   
 |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/590698 | 
stable/ocata  |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/590355 | 
stable/pike   |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/589928 | 
stable/queens |
| fix tox python3 overrides   | 
openstack/monasca-common   | VERIFIED | MERGED | 
https://review.openstack.org/572910 | master|
| ignore python2-specific code under python3 for pep8 | 
openstack/monasca-common   | VERIFIED | MERGED | 
https://review.openstack.org/573002 | master|
| fix tox python3 overrides   | 
openstack/monasca-log-api  | VERIFIED | MERGED | 
https://review.openstack.org/572971 | master|
| replace use of 'unicode' builtin| 
openstack/monasca-log-api  | VERIFIED | MERGED | 
https://review.openstack.org/573015 | master|
| fix tox python3 overrides   | 
openstack/monasca-statsd   | VERIFIED | MERGED | 
https://review.openstack.org/572911 | master|
| fix tox python3 overrides   | 
openstack/python-monascaclient | VERIFIED | MERGED | 
https://review.openstack.org/573344 | master|
| replace unicode with six.text_type  | 
openstack/python-monascaclient | VERIFIED | MERGED | 
https://review.openstack.org/575212 | master|
| | 
   |   || | 
  |
| | 
   | VERIFIED: 13 | MERGED: 13 | |  
 |
+-++--++-+———+

They do not include the monasca-events-api, monasca-specs,
monasca-persister, monasca-tempest-plugin, monasca-thresh, monasca-ui,
monasca-ceilometer, monasaca-transform, monasca-analytics,
monasca-grafana-datasource, and monasca-kibana-plugin repositories.

It also looks like they don’t include some necessary changes for
some branches in some of the other repos, although I haven’t checked
if those branches actually exist so maybe they’re fine.

We also need a patch to project-config to remove the settings for
all of the monasca team’s repositories.

I can generate the missing patches, but doing that now is likely
to introduce some bad patches into the repositories that have had
some work done, so you’ll need to review everything carefully.

In all, it looks like we’re missing around 80+ patches, although
some of the ones I have generated locally may be bogus because of
the existing changes.

I realize Witold is OOO for a while, so I'm emailing the list to
ask the team how you want to proceed. Should I go ahead and propose
the patches I have?
Thanks Doug, we had a discussion and we agreed that the best way to 
proceed is for you to submit your patches and we will carefully review them.


Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][goal][python3] monasca's zuul migration is only partially complete

[Doug Hellmann]

Monasca team,

It looks like you have self-proposed some, but not all, of the
patches to import the zuul settings into monasca repositories.

I found these:

+-++--++-+---+
| Subject | Repo
   | Tests | Workflow   | URL | Branch  
  |
+-++--++-+---+
| Removed dependency on supervisor| openstack/monasca-agent 
   | VERIFIED | MERGED | https://review.openstack.org/554304 | master   
 |
| fix tox python3 overrides   | openstack/monasca-agent 
   | VERIFIED | MERGED | https://review.openstack.org/574693 | master   
 |
| fix tox python3 overrides   | openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/572970 | master   
 |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/590698 | 
stable/ocata  |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/590355 | 
stable/pike   |
| import zuul job settings from project-config| openstack/monasca-api   
   | VERIFIED | MERGED | https://review.openstack.org/589928 | 
stable/queens |
| fix tox python3 overrides   | 
openstack/monasca-common   | VERIFIED | MERGED | 
https://review.openstack.org/572910 | master|
| ignore python2-specific code under python3 for pep8 | 
openstack/monasca-common   | VERIFIED | MERGED | 
https://review.openstack.org/573002 | master|
| fix tox python3 overrides   | 
openstack/monasca-log-api  | VERIFIED | MERGED | 
https://review.openstack.org/572971 | master|
| replace use of 'unicode' builtin| 
openstack/monasca-log-api  | VERIFIED | MERGED | 
https://review.openstack.org/573015 | master|
| fix tox python3 overrides   | 
openstack/monasca-statsd   | VERIFIED | MERGED | 
https://review.openstack.org/572911 | master|
| fix tox python3 overrides   | 
openstack/python-monascaclient | VERIFIED | MERGED | 
https://review.openstack.org/573344 | master|
| replace unicode with six.text_type  | 
openstack/python-monascaclient | VERIFIED | MERGED | 
https://review.openstack.org/575212 | master|
| | 
   |   || | 
  |
| | 
   | VERIFIED: 13 | MERGED: 13 | |  
 |
+-++--++-+———+

They do not include the monasca-events-api, monasca-specs,
monasca-persister, monasca-tempest-plugin, monasca-thresh, monasca-ui,
monasca-ceilometer, monasaca-transform, monasca-analytics,
monasca-grafana-datasource, and monasca-kibana-plugin repositories.

It also looks like they don’t include some necessary changes for
some branches in some of the other repos, although I haven’t checked
if those branches actually exist so maybe they’re fine.

We also need a patch to project-config to remove the settings for
all of the monasca team’s repositories.

I can generate the missing patches, but doing that now is likely
to introduce some bad patches into the repositories that have had
some work done, so you’ll need to review everything carefully.

In all, it looks like we’re missing around 80+ patches, although
some of the ones I have generated locally may be bogus because of
the existing changes.

I realize Witold is OOO for a while, so I'm emailing the list to
ask the team how you want to proceed. Should I go ahead and propose
the patches I have?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Vacation

[Bedyk, Witold]

Hello everyone,

I'll be on vacation until August 31st. My deputies in that time will be:

* Doug Szumski (dougsz)  and
* Dobrosław Żybort (Dobroslaw) 

Thanks a lot
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Etharpad for Stein PTG in Denver

[Bedyk, Witold]

Hello,

I've just created an etherpad [1] for planning our sessions at the next PTG in 
Denver.
Please add the topics you'd like to discuss. The main goal of the sessions is 
to agree on development priorities and coordinate the work for the next release 
cycle.
Please also don't forget to add yourself to the attendance list, on-site or 
remote.


Cheers
Witek

[1] https://etherpad.openstack.org/p/monasca-ptg-stein

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Nominating Doug Szumski as Monasca core

[Bedyk, Witold]

Hello Monasca team,

I would like to nominate Doug Szumski (dougsz) for Monasca core team.

He actively contributes to the project and works on adding Monasca to 
kolla-ansible. He has good project overview which he shares in his reviews.

Best greetings
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Monasca PTG participation survey

[Bedyk, Witold]

Hello everyone,

The next PTG will take place September 10-14, 2018 in Denver, Colorado [1]. 
Again we have to decide if Monasca will participate and gather together with 
other projects. The last PTG was a great success which is measurable in new 
code already submitted and number of reviews. But I also understand that it's 
not always easy to travel.
Please take a minute, consider all the pros and cons, and fill out this form 
[2] until Wednesday, May 2nd.

Cheers
Witek

[1] https://www.openstack.org/ptg
[2] https://goo.gl/forms/z2Bu5RlXin30wTpA3

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] PTG follow-up

[Bedyk, Witold]

Hello everyone,

I hope all of you attending the PTG in Dublin could meanwhile get safely home. 
For those not attending, a short update, because of Storm Emma red alert had 
been introduced last week in Ireland and the conference venue had to be closed 
on Thursday and Friday. We have decided to schedule an additional short session 
on Wednesday, 7th March, via GoToMeeting [1] to finish the discussion on the 
remaining topics and to do the tasks prioritization. Everyone is welcome to 
join. The topics are at the bottom of the etherpad [2]. The IRC team meeting is 
cancelled this week.
The table for prioritization game [3] is filled with topics. Please review them 
and make your thoughts about which are important for you. Please also let me 
know if anything is missing.

See you on Wednesday
Witek

P.S. Team photos are available here [4].

[1] https://global.gotomeeting.com/join/664699565
[2] https://etherpad.openstack.org/p/monasca-ptg-rocky
[3] 
https://docs.google.com/spreadsheets/d/10yNylReIaIAINPBDb9IuASpGfuJg2f-hU9K2jpVxlyk/edit?usp=sharing
[4] https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB6nLiArw8fYBiO-X_vDGyna?dl=0

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][congress] help configuring monasca for gate

[Eric K]

Thank Witek =)

We're looking at getting pushed alarm data from Monasca via webhook.
Fabiog started that quite a while back and we're hoping to revive it. Not
sure there is any feature requests. But I do want to understand the
authentication situation in Monasca webhook. Wondering whether Congress
should require keystone auth in the webhook request or expect
unauthenticated requests.

On a much more ambitious and speculative front, we're also thinking about
how Congress may be able to leverage Monasca to evaluate certain policies.
It's also something we explored with fabiog before. For example, if there
is a rule that identifies low usage servers:
  underutilized_servers(server_id) :-
  ceilometer:statistics(meter_name='cpu_util',resource_id=server_id,
avg=avg),builtin:lt(avg, 10)
There may be a way for Congress to (semi) automatically create a
corresponding Monasca alarm and rewrite the rule to depend on the alarm.

I'd also love to hear if there are any other thoughts for how one project
may benefit from the other.

Eric Kao (ekcs)

On 2/13/18, 6:45 AM, "Bedyk, Witold" <witold.be...@est.fujitsu.com> wrote:

>Hi Eric,
>
>glad to hear the problems are solved :)
>
>What are your plans around integration with Monasca? Please let us know
>if you have related feature requests.
>
>Cheers
>Witek
>
>
>> -Original Message-
>> From: Eric K [mailto:ekcs.openst...@gmail.com]
>> Sent: Dienstag, 13. Februar 2018 03:59
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [monasca][congress] help configuring
>>monasca
>> for gate
>> 
>> Oops. Nevermind. Looks like it's working now.
>> 
>> On 2/12/18, 5:00 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:
>> 
>> >Hi Monasca folks,
>> >I'm trying to configure monasca in congress gate [1] and modeled it
>> >after this monasca playbook [2]. But I get:
>> >rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed:
>> >No such file or directory (2)
>> >
>> >http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql
>> >/16
>> >6
>> >d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-
>> 30_01_53_41
>> >_60
>> >7
>> >
>> >
>> >Any hints on what I need to do differently? Thanks!
>> >
>> >[1] https://review.openstack.org/#/c/530522/
>> >[2]
>> >https://github.com/openstack/monasca-
>> api/blob/master/playbooks/legacy/m
>> >ona
>> >s
>> >ca-tempest-base/run.yaml
>> >
>> >
>> 
>> 
>> 
>> __
>> 
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][congress] help configuring monasca for gate

[Bedyk, Witold]

Hi Eric,

glad to hear the problems are solved :)

What are your plans around integration with Monasca? Please let us know if you 
have related feature requests.

Cheers
Witek


> -Original Message-
> From: Eric K [mailto:ekcs.openst...@gmail.com]
> Sent: Dienstag, 13. Februar 2018 03:59
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [monasca][congress] help configuring monasca
> for gate
> 
> Oops. Nevermind. Looks like it's working now.
> 
> On 2/12/18, 5:00 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:
> 
> >Hi Monasca folks,
> >I'm trying to configure monasca in congress gate [1] and modeled it
> >after this monasca playbook [2]. But I get:
> >rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed:
> >No such file or directory (2)
> >
> >http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql
> >/16
> >6
> >d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-
> 30_01_53_41
> >_60
> >7
> >
> >
> >Any hints on what I need to do differently? Thanks!
> >
> >[1] https://review.openstack.org/#/c/530522/
> >[2]
> >https://github.com/openstack/monasca-
> api/blob/master/playbooks/legacy/m
> >ona
> >s
> >ca-tempest-base/run.yaml
> >
> >
> 
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][congress] help configuring monasca for gate

[Eric K]

Oops. Nevermind. Looks like it's working now.

On 2/12/18, 5:00 PM, "Eric K"  wrote:

>Hi Monasca folks,
>I'm trying to configure monasca in congress gate [1] and modeled it after
>this monasca playbook [2]. But I get:
>rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
>such file or directory (2)
>
>http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/16
>6
>d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_60
>7
>
>
>Any hints on what I need to do differently? Thanks!
>
>[1] https://review.openstack.org/#/c/530522/
>[2] 
>https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/mona
>s
>ca-tempest-base/run.yaml
>
>



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][congress] help configuring monasca for gate

[Eric K]

Hi Monasca folks,
I'm trying to configure monasca in congress gate [1] and modeled it after
this monasca playbook [2]. But I get:
rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
such file or directory (2)

http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/166
d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_607


Any hints on what I need to do differently? Thanks!

[1] https://review.openstack.org/#/c/530522/
[2] 
https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/monas
ca-tempest-base/run.yaml



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Feature freeze lifted

[Bedyk, Witold]

Hello,

Yesterday I have created stable/queens branches for our repos. It will be used 
to create the final Queens release.
We can continue the work on new features on master.

Cheers
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Remove MySQL Connector from monasca-thresh

[Bedyk, Witold]

Hello,

During the internal legal check we've noticed that monasca-threshold Java 
archive includes MySQL Connector which is licensed under GPLv2. This license 
restricts the distribution of the consuming project and is not aligned with 
OpenStack licensing requirements [1].

I'm proposing to remove this library in Rocky release and use the already 
included Drizzle JDBC [2].

Best greetings
Witek


[1] https://governance.openstack.org/tc/reference/licensing.html
[2] https://storyboard.openstack.org/#!/story/2001522

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] PTL candidacy

[Bedyk, Witold]

Hello everyone,

I would like to announce my candidacy to continue as PTL of Monasca for the
Rocky release.

I have worked for the project as core reviewer since 2015, acted as Release
Management Liaison in Ocata and Pike and had a privilege of being PTL in Queens
release cycle. I have learnt a lot in this new role and it's a real pleasure to
work with the great team and improve the project. Thank you for all your
support.

In the next release I would like to focus on following topics:

* continue the work on Cassandra support
* strengthen the community and improve active participation and contribution
* improve tenant monitoring
* accomplish Python 3 migration

Apart from that I'll do my best to promote Monasca, coordinate community work
and interact with other OpenStack teams.

Thank you for considering my candidacy and I'm looking forward to another very
productive cycle.

Best greetings

Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Contribution from T-Systems

[Bedyk, Witold]

Hi Yuan,

Thanks for reaching out to us in the team meeting. I'm happy to hear you want 
to contribute your changes to the project. You can find our contribution 
guidelines here [1]. The general OpenStack Developer's Guide is here [2].
Which components/topics are you interested in, in terms of contribution? Also 
feature requests or improvement proposals are very welcome.

As you have probably noticed we will be planning the work for the next release 
during the Project Teams Gathering in Dublin end of this month [3, 4]. It's a 
perfect opportunity to engage in the project.

Best regards
Witek

[1] https://docs.openstack.org/monasca-api/latest/contributor/index.html
[2] https://docs.openstack.org/infra/manual/developers.html
[3] https://www.openstack.org/ptg
[4] https://etherpad.openstack.org/p/monasca-ptg-rocky

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] RE: alarm transition events are missing in kafka queue - mysql alarm state is updated properly

[Bedyk, Witold]

Hi Yuan,

please compare similar issue described in this bug report [1] and the 
corresponding fix [2].
As Craig explained in his comment to patch set 4, Kafka server closes idle 
connections after around 10 minutes, which causes first write to the topic fail.

I hope it helps.
Witek

[1] https://storyboard.openstack.org/#!/story/2001386
[2] https://review.openstack.org/525669


From: yuan@t-systems.com [mailto:yuan@t-systems.com]
Sent: Freitag, 12. Januar 2018 19:36
To: roland.hochm...@hpe.com
Cc: Bedyk, Witold ; mona...@lists.launchpad.net; 
Trebski, Tomasz ; bradley.kl...@charter.com
Subject: alarm transition events are missing in kafka queue - mysql alarm state 
is updated properly

Hi Roland,
This is Yuan Pen from Deutsche Telekom. I am sending this email to the monasca 
community asking for help on monasca threshold engine. We have found that when 
sometime alarm state transitions happened, the threshold engine updated mysql 
alarm state properly, but failed to put  state transition events  in kafka 
queue (alarm-state-transitions).  Does this ring a bell to anyone in the 
community? If this is a real problem, is there anything we can do to make sure 
the event in transition queue and state in mysql is synched? Any comments or 
help are greatly appreciated.
Best Regard,

Yuan Pen

571-594-6155

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Nominate Amir Mofakhar to Monasca core

[Bedyk, Witold]

Hello everyone,

I would like to nominate Amir Mofakhar to the Monasca core reviewers team.

Welcome onboard,
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Monasca at PTG in Dublin

[Bedyk, Witold]

Hello,

As discussed in the meeting today I would like to ask for your opinion if 
Monasca team should gather at the Project Teams Gathering (PTG) event in 
Dublin, February 26 - March 2nd [1]. The goal of the PTG is "to discuss 
priorities for the upcoming cycle, iterate quickly on solutions for complex 
issues, and make fast progress on critical items". Alternatively we can hold a 
remote video conference, as we have done previously.

Please fill in the following form until Dec 4th if you want to participate in 
planning the work for the next release:
https://goo.gl/forms/yLn0vi1A03OXfO843

[1] https://www.openstack.org/ptg/

Best greetings
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] New Team Meeting Time doodle

[Bedyk, Witold]

Hello,

I'm sorry for the late notice. I have moved the meeting one hour later. The new 
meeting time is:

Wednesday, 1500 UTC
#openstack-meeting-3


See you there,
Witek



> -Original Message-
> From: Bedyk, Witold
> Sent: Mittwoch, 15. November 2017 17:16
> To: 'OpenStack Development Mailing List (not for usage questions)'
> 
> Subject: [monasca] New Team Meeting Time doodle
> 
> Hello everyone,
> 
> We would like to choose the optimal time for our Team Meeting. I have
> created a doodle [1] for that. Please put your preferences until Monday 1200
> UTC if you want to attend the meeting.
> 
> Cheers
> Witek
> 
> [1] https://doodle.com/poll/s5fwqtu7ik898p57

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] New Team Meeting Time doodle

[Bedyk, Witold]

Hello everyone,

We would like to choose the optimal time for our Team Meeting. I have created a 
doodle [1] for that. Please put your preferences until Monday 1200 UTC if you 
want to attend the meeting.

Cheers
Witek

[1] https://doodle.com/poll/s5fwqtu7ik898p57

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] [wiki] Where is GUI tutorial of Monasca

[Bedyk, Witold]

Hi Takeyuki,

I'm afraid we don't have documentation for the GUI. The concepts of alarm 
definitions, alarms and notifications are explained here [1]. You may also want 
to have a look at practical examples of working with the API using the Python 
client [2, 3].

I know that our documentation is far from complete and spread between different 
locations. We'll try to improve that.


Best regards
Witek


[1] 
https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#alarm-definitions-and-alarms
[2] https://github.com/openstack/python-monascaclient#usage
[3] 
https://github.com/witekest/monasca-bootcamp/blob/master/Monasca%20Bootcamp.ipynb



> -Original Message-
> From: Kodama, Takeyuki [mailto:kodama.takey...@jp.fujitsu.com]
> Sent: Mittwoch, 4. Oktober 2017 09:01
> To: 'openstack-dev@lists.openstack.org'  d...@lists.openstack.org>
> Subject: [openstack-dev] [Monasca] [wiki] Where is GUI tutorial of Monasca
> 
> Hi
> 
> I'm very grateful that if you consider my request.
> 
> 
> Would you tell me where the tutorial of Monasca is, especially after
> installation?
> If it does not exist, it is helpful for us to add the tutorial on wiki page.
>  https://wiki.openstack.org/wiki/Monasca
> Especially,  I would like to know the GUI operation on dashboard.
> 
> In the tutorial, I want to know following situations.
> 
> - how to make an alarm definition and to activate it
> - how to set notification
> - the example when an alarm is generated
> 
> Best regard,
> T. Kodama
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] Query for the official document of Monasca manual installation on openstack

[Bedyk, Witold]

Hi Manik,

I would recommend you installing Monasca components using Docker Compose [1] 
and manually installing the agents [2] on your controller and compute nodes.
You will also have to add/configure Monasca users in Keystone with roles as 
configured by default_authorized_roles and agent_authorized_roles in security 
section of api-config.conf [3, 4].


I hope it helps.
Witek



[1] https://github.com/monasca/monasca-docker
[2] 
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md#installing
[3] 
https://github.com/openstack/monasca-api/blob/master/monasca_api/conf/security.py
[4] 
https://github.com/monasca/monasca-docker/tree/master/monasca-api-python#configuration




> -Original Message-
> From: manik bindlish [mailto:manikbindlis...@gmail.com]
> Sent: Dienstag, 3. Oktober 2017 15:21
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Monasca] Query for the official document of
> Monasca manual installation on openstack
> 
> Hi,
> 
> I have a query regarding manual installation of Monasca on Openstack.
> 
> Please let me know the official document or link for manually node wise
> installation of Monasca(completely) on Openstack
> 
> I have to integrate Monasca with Congress(Openstack: Newton).
> Configuration is: 1 Controller node + 3 Compute node
> 
> 
> Thanks,
> Manik
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] [wiki] Where is GUI tutorial of Monasca

[Kodama, Takeyuki]

Hi

I'm very grateful that if you consider my request.


Would you tell me where the tutorial of Monasca is, especially after 
installation?
If it does not exist, it is helpful for us to add the tutorial on wiki page.
 https://wiki.openstack.org/wiki/Monasca
Especially,  I would like to know the GUI operation on dashboard.

In the tutorial, I want to know following situations.

- how to make an alarm definition and to activate it
- how to set notification
- the example when an alarm is generated

Best regard,
T. Kodama


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Query for the official document of Monasca manual installation on openstack

[manik bindlish]

Hi,

I have a query regarding manual installation of Monasca on Openstack.

Please let me know the official document or link for manually node
wise installation of Monasca(completely) on Openstack

I have to integrate Monasca with Congress(Openstack: Newton).
Configuration is: 1 Controller node + 3 Compute node


Thanks,
Manik

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Stefano Canepa and Dobrosław Żybort in Monasca core team

[Stefano Canepa]

On Tue, Sep 26, 2017 at 11:26:55AM +, Bedyk, Witold wrote:
> Hello everyone,
> 
> I would like to nominate Stefano Canepa and Dobrosław Żybort to Monasca core 
> reviewers team.
> Welcome and thank you for your contribution to the project.
> 
> 
> Best regards
> Witek

Thanks Witek.

Bye
sc

-- 
Stefano Canepa

Three great virtues of a programmer: laziness, impatience, and hubris.
(Larry Wall)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Stefano Canepa and Dobrosław Żybort in Monasca core team

[Bedyk, Witold]

Hello everyone,

I would like to nominate Stefano Canepa and Dobrosław Żybort to Monasca core 
reviewers team.
Welcome and thank you for your contribution to the project.


Best regards
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Queens Mid-Cycle

[witold.be...@est.fujitsu.com]

Hello everyone,

Monasca team will hold a Mid-Cycle meeting for the Queens release on Sep. 20th 
and 21st via remote conferencing. Please add the topics you would like to 
discuss or features you would like to see in the next release to the etherpad 
[1].
The connection details are included in the etherpad.


Best regards
Witek

[1] https://etherpad.openstack.org/p/monasca_queens_midcycle

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[gordon chung]

On 28/08/17 10:32 AM, witold.be...@est.fujitsu.com wrote:
> The number looks good but the test you have referenced was performed with the 
> file storage driver which is not really scalable. It would be great if you 
> could provide numbers for the Ceph backend.
> Please keep us updated.

these are numbers i got using a ceph backend with gnocchi v3[1]. i 
should mention that v3 wasn't targeting write performance improvements 
(not directly). for reference, i think my ceph cluster had 30 OSDs.

the actual write throughput will depend on the driver you select (redis 
probably fastest, ceph a close second) and as jd mentioned, the batch sizes.

[1] https://www.slideshare.net/GordonChung/gnocchi-v3/18

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[witold.be...@est.fujitsu.com]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Montag, 28. August 2017 16:03
> To: Bedyk, Witold <witold.be...@est.fujitsu.com>
> Cc: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Monasca] GridDB repository support
> 
> On Mon, Aug 28 2017, witold.be...@est.fujitsu.com wrote:
> 
> > Can you give some reference to Gnocchi's performance measurements?
> > I have seen you presentation from the last Summit [1] but I cannot
> > find information about Gnocchi's write throughput. In the issues slide
> > you note the slow post API. The API responsiveness test shows that the
> > API can handle correctly up to 2500 instances. You collect around 60
> > metrics per instance and use polling interval of 10 minutes. That would
> translate to:
> >
> > 2500 instances * 60 metrics/instance / 600 s = 250 metrics/s
> >
> > Are these assumptions correct?
> 
> It really depends on the number of measures you include in each of your API
> requests. Ceilometer does very little batching.
> 
> If you batch those measurements, you could achieve up to 120k measures/s
> in Gnocchi already 2 years ago¹. Considering the various improvement we did
> over that timeframe, you can likely go higher.
> 
> And since it scales horizontally, you can double the request handling by
> adding another node. :)
> 
> I'll probably try to do some benchmark one of these days, but I don't have
> proper hardware to do so for now. :)
> 
> ¹  https://julien.danjou.info/blog/2015/gnocchi-benchmarks


The number looks good but the test you have referenced was performed with the 
file storage driver which is not really scalable. It would be great if you 
could provide numbers for the Ceph backend.
Please keep us updated.

Cheers
Witek
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[Julien Danjou]

On Mon, Aug 28 2017, witold.be...@est.fujitsu.com wrote:

> Can you give some reference to Gnocchi's performance measurements?
> I have seen you presentation from the last Summit [1] but I cannot find
> information about Gnocchi's write throughput. In the issues slide you note the
> slow post API. The API responsiveness test shows that the API can handle
> correctly up to 2500 instances. You collect around 60 metrics per instance and
> use polling interval of 10 minutes. That would translate to:
>
> 2500 instances * 60 metrics/instance / 600 s = 250 metrics/s
>
> Are these assumptions correct?

It really depends on the number of measures you include in each of your
API requests. Ceilometer does very little batching.

If you batch those measurements, you could achieve up to 120k measures/s
in Gnocchi already 2 years ago¹. Considering the various improvement we
did over that timeframe, you can likely go higher.

And since it scales horizontally, you can double the request handling by
adding another node. :)

I'll probably try to do some benchmark one of these days, but I don't
have proper hardware to do so for now. :)

¹  https://julien.danjou.info/blog/2015/gnocchi-benchmarks

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[witold.be...@est.fujitsu.com]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Dienstag, 22. August 2017 15:50
> To: Bedyk, Witold <witold.be...@est.fujitsu.com>
> Cc: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Monasca] GridDB repository support



> We don't have any recent comparison with InfluxDB but last time we tried,
> Gnocchi was already getting faster than it. And scalable horizontally, so…


Hi Julien,

Can you give some reference to Gnocchi's performance measurements?
I have seen you presentation from the last Summit [1] but I cannot find 
information about Gnocchi's write throughput. In the issues slide you note the 
slow post API. The API responsiveness test shows that the API can handle 
correctly up to 2500 instances. You collect around 60 metrics per instance and 
use polling interval of 10 minutes. That would translate to:

2500 instances * 60 metrics/instance / 600 s = 250 metrics/s

Are these assumptions correct?

Best greetings
Witek


[1] 
https://julien.danjou.info/talks/OpenStack_Telemetry_and_the_1_Instances.pdf
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[Akira Yoshiyama]

Hi Witek,

Thank you for your interest.

2017-08-22 21:25 GMT+09:00 witold.be...@est.fujitsu.com
<witold.be...@est.fujitsu.com>:
> Hi Akira,
>
> thank you for your contribution. We indeed urgently need a scalable open 
> source TSDB.

I see. Kawabata-san from NEC was my co-worker and he told me about the
problem. So, I've been interested in open source TSDBs and found
GridDB at an open source event in Tokyo last fall. But there was no
python binding at the time, so I had waited for it.

> Do you use this database in your Monasca deployment? Have you made write/read 
> performance measurements when used with Monasca? I couldn't find much 
> information about this database apart from the references you have provided.

I have a small Monasca deployment on 2 VMs for development. Actually,
I've started building Monasca and GridDB environment on Aug. 11th and
then made the drivers in 5 days. So, I have no my own benchmark result
yet.

> In the recent weeks James Gu and his team have re-evaluated using Cassandra 
> as Monasca backend [1]. They have measured write throughput of 64 kmetrics/s 
> when storing 200 mil unique metric definitions and 50 bil measurements on the 
> two nodes cluster. It's way below what InfluxDB can on the single node, but 
> that's a number we can live with, I guess. Can GridDB perform better?

Some papers[1] (in english) are available and one of them is about
performance[2]. See page 24-25 of it, and you will find below:
---
   Throughput with Large Data Set (12M Records Per Node)
   Load / 1 node:
GridDB13,082 (ops/sec)
Cassandra 4,325 (ops/sec)

Latency with Large Data Set (12M Records Per Node) -- 1 Node
Load / Insert
GridDB  9.7 (ms)
Cassandra 7.0 (ms)
---

[1]https://griddb.net/en/downloads/
[2]https://griddb.net/en/docs/Fixstars_NoSQL_Benchmarks.pdf

> What do the others think? Should we experiment and add support for different 
> backend drivers or rather choose one or two and concentrate on these?
>
>
> Best greetings
> Witek

There are some other TSDBs like Gnocchi and Prometheus. I'll consider
making other drivers if GridDB isn't so good for Monasca.

Best,
Akira

> [1] https://etherpad.openstack.org/p/cassandra_monasca
>
>
>
>> -Original Message-
>> From: Akira Yoshiyama [mailto:akirayoshiy...@gmail.com]
>> Sent: Samstag, 19. August 2017 15:31
>> To: OpenStack Development Mailing List > d...@lists.openstack.org>
>> Subject: [openstack-dev] [Monasca] GridDB repository support
>>
>> Hi all,
>>
>> Toshiba GridDB[1][2] is a highly scalable distributed NoSQL database for IoT
>> and Big Data. It has very good scalability and performance[3].
>> It also has Community Edition licensed under GNU AGPL v3 and the source
>> code is available at Github[4][5][6].
>>
>> It looks suitable for Monasca repository, so I'm writing GridDB repository
>> drivers for monasca-api/-persister[7][8]. They work well but need unit tests.
>> Anyone interested?
>>
>> Thank you,
>> Akira Yoshiyama
>>
>> [1]http://solutions.toshiba.com/overview.html
>> [2]https://griddb.net/en/docs/documents/1-1_what-is-griddb.php
>> [3]https://griddb.net/ja/blog/griddb-and-cassandra-ycsb-benchmarks/
>> [4]https://github.com/griddb/griddb_nosql
>> [5]https://github.com/griddb/c_client
>> [6]https://github.com/griddb/griddb_client
>> [7]https://review.openstack.org/#/c/495504/
>> [8]https://review.openstack.org/#/c/495505/
>>
>> __
>> 
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
吉山あきら <akirayoshiy...@gmail.com>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[Julien Danjou]

On Tue, Aug 22 2017, witold.be...@est.fujitsu.com wrote:

Hi Witek,

> thank you for your contribution. We indeed urgently need a scalable open 
> source TSDB.

Did you look at Gnocchi? It's exactly that.

  http://gnocchi.xyz/

> In the recent weeks James Gu and his team have re-evaluated using Cassandra as
> Monasca backend [1]. They have measured write throughput of 64 kmetrics/s when
> storing 200 mil unique metric definitions and 50 bil measurements on the two
> nodes cluster. It's way below what InfluxDB can on the single node, but that's
> a number we can live with, I guess. Can GridDB perform better?
> 
> What do the others think? Should we experiment and add support for different
> backend drivers or rather choose one or two and concentrate on these?

We don't have any recent comparison with InfluxDB but last time we
tried, Gnocchi was already getting faster than it. And scalable
horizontally, so…

You might want to give it a try.

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] GridDB repository support

[witold.be...@est.fujitsu.com]

Hi Akira,

thank you for your contribution. We indeed urgently need a scalable open source 
TSDB.

Do you use this database in your Monasca deployment? Have you made write/read 
performance measurements when used with Monasca? I couldn't find much 
information about this database apart from the references you have provided.

In the recent weeks James Gu and his team have re-evaluated using Cassandra as 
Monasca backend [1]. They have measured write throughput of 64 kmetrics/s when 
storing 200 mil unique metric definitions and 50 bil measurements on the two 
nodes cluster. It's way below what InfluxDB can on the single node, but that's 
a number we can live with, I guess. Can GridDB perform better?

What do the others think? Should we experiment and add support for different 
backend drivers or rather choose one or two and concentrate on these?


Best greetings
Witek



[1] https://etherpad.openstack.org/p/cassandra_monasca



> -Original Message-
> From: Akira Yoshiyama [mailto:akirayoshiy...@gmail.com]
> Sent: Samstag, 19. August 2017 15:31
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] [Monasca] GridDB repository support
> 
> Hi all,
> 
> Toshiba GridDB[1][2] is a highly scalable distributed NoSQL database for IoT
> and Big Data. It has very good scalability and performance[3].
> It also has Community Edition licensed under GNU AGPL v3 and the source
> code is available at Github[4][5][6].
> 
> It looks suitable for Monasca repository, so I'm writing GridDB repository
> drivers for monasca-api/-persister[7][8]. They work well but need unit tests.
> Anyone interested?
> 
> Thank you,
> Akira Yoshiyama
> 
> [1]http://solutions.toshiba.com/overview.html
> [2]https://griddb.net/en/docs/documents/1-1_what-is-griddb.php
> [3]https://griddb.net/ja/blog/griddb-and-cassandra-ycsb-benchmarks/
> [4]https://github.com/griddb/griddb_nosql
> [5]https://github.com/griddb/c_client
> [6]https://github.com/griddb/griddb_client
> [7]https://review.openstack.org/#/c/495504/
> [8]https://review.openstack.org/#/c/495505/
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] GridDB repository support

[Akira Yoshiyama]

Hi all,

Toshiba GridDB[1][2] is a highly scalable distributed NoSQL database
for IoT and Big Data. It has very good scalability and performance[3].
It also has Community Edition licensed under GNU AGPL v3 and the
source code is available at Github[4][5][6].

It looks suitable for Monasca repository, so I'm writing GridDB
repository drivers for monasca-api/-persister[7][8]. They work well
but need unit tests. Anyone interested?

Thank you,
Akira Yoshiyama

[1]http://solutions.toshiba.com/overview.html
[2]https://griddb.net/en/docs/documents/1-1_what-is-griddb.php
[3]https://griddb.net/ja/blog/griddb-and-cassandra-ycsb-benchmarks/
[4]https://github.com/griddb/griddb_nosql
[5]https://github.com/griddb/c_client
[6]https://github.com/griddb/griddb_client
[7]https://review.openstack.org/#/c/495504/
[8]https://review.openstack.org/#/c/495505/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Mid-cycle project team meeting

[witold.be...@est.fujitsu.com]

Hello everyone,

as discussed yesterday in the Team Meeting there will be no Monasca planning 
session during the PTG. Instead we will hold a video conference one week later. 
The goal is to discuss the priorities and coordinate the work in the next 
release cycle. Please mark the dates which would work for you in the attached 
doodle [1]. We would like to meet from 2pm to 6pm UTC on one or two days 
depending on how full the agenda will be.
After the dates are set I will create an etherpad where we can work on agenda.


Best greetings
Witek

[1] http://doodle.com/poll/bca7tsz484faefn8

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] PTL candidacy for Queens

[witold.be...@est.fujitsu.com]

Hello everyone,

I would like to propose my candidacy for the role of Monasca PTL for Queens
release.

I would like to thank Roland, who has been the PTL for several releases now and
has always pushed the project forward. Your working quota seems to be unlimited,
I reckon you work at sleep as well :) I'm sure that anyone who wants to lead
Monasca will need your support and expertise. Thanks for your commitment.

To my person, I have worked for the project as core member for two years now and
acted as Release Management Liason in Ocata and Pike cycles. I have participated
in my first OpenStack Summit in Tokyo where I forgot the password to the demo
machine during the presentation. Then followed Austin, Barcelona and Boston with
presentations, design sessions, workshops and mid-cycle meetings. During this
time I have met tremendous people, learnt a great deal about Monasca and
OpenStack and had many sleepless nights :)

As PTL, in the next release I would like to focus on following topics:

* easy deployment of Monasca using Docker and Kubernetes
* improve documentation
* search for new scalable time-series database
* strengthen the community and improve active participation and contribution
* metrics aggregation
* alarms correlation
* events processing

I hope to get the support of the entire team and good cooperation in Queens
cycle.


Best greetings

Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Stable branch for Pike

[Doug Hellmann]

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 13:27:14 
+:
> Hello Monasca team,
> 
> Following the Pike release schedule I would like to cut the stable branch for 
> Pike release early next week. We will use it to create the final release at 
> the end of August.
> 
> Please let me know of release-critical bugs which should be merged before.
> 
> 
> Cheers
> Witek
> 

Please coordinate with the release team to create the stable branches
based on your release candidates.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Stable branch for Pike

[witold.be...@est.fujitsu.com]

Hello Monasca team,

Following the Pike release schedule I would like to cut the stable branch for 
Pike release early next week. We will use it to create the final release at the 
end of August.

Please let me know of release-critical bugs which should be merged before.


Cheers
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Skip next team meeting

[witold.be...@est.fujitsu.com]

Hello folks,

due to holiday time in US I suggest to skip the next Monasca team meeting on 
Wednesday, July the 5th.

Please reply here if you have important topics to discuss and would like to 
hold the meeting anyway.


Cheers
Witek


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] New time and place of Monasca Team Meeting

[witold.be...@est.fujitsu.com]

Hello,

this is just a reminder of the new place and time of the Monasca Team Meeting. 
It takes place

weekly on Wednesday at 1400 UTC in #openstack-meeting


See you there
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Monasca at PTG in Denver

[witold.be...@est.fujitsu.com]

Hi,

I wanted to ask who of you would be interested in attending dedicated Monasca 
sessions during the next Project Teams Gathering in Denver, September 11-15, 
2017 [1]. The team room would probably be booked for one or two days. 
Alternatively we could organize the remote mid-cycle meeting, as we did 
previously.

Please fill the form as soon as possible:
https://goo.gl/forms/7xpgZFrcUCWhqnEg2

[1] https://www.openstack.org/ptg/



Cheers
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Monasca with out openstack

[Shah Zaib]

Hi all,

I want to install the monsaca with out openstack.

for the alternative of  keystone, i want to use the openladap.

but i didn't find any configuration and any help on web.

any thoughts and suggestions on this ??



Best Regards
 *Shahzaib*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][swift][storyboard] migration experience

[Jeremy Stanley]

On 2017-04-21 09:00:47 + (+), witold.be...@est.fujitsu.com wrote:
> one thing which hasn't been migrated are the blueprints. We have
> noticed this after the migration. Storyboard team has said they
> had not planned on migrating blueprints because most of the
> projects use the specs server.

An option here might be to amend the migration script to also
create new stories from open blueprints and add a story tag like
"blueprint" to them. Part of the reason StoryBoard wasn't designed
with a separate blueprint feature is that its story model is
intended to be flexible enough to handle a lot of the same sorts of
use cases for which blueprints were used (since unlike LP, you can
have multiple tasks in a story for the same project without having
to predefine a separate branch or series).

But as you noted, the migration script didn't originally consider
blueprints because there was a general trend within the community to
move away from LP blueprints in favor of repos under code review
where they could curate more detailed and structured specifications
instead... so we weren't sure if anyone would still be using
blueprints at all by the time we were ready to start on the majority
migration.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][swift][storyboard] migration experience

[witold.be...@est.fujitsu.com]

> >2) Are you missing anything from the migration? How do you manage
> >security bugs that are embargoed?


Hi John,

one thing which hasn't been migrated are the blueprints. We have noticed this 
after the migration. Storyboard team has said they had not planned on migrating 
blueprints because most of the projects use the specs server.


Cheers
Witek
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][swift][storyboard] migration experience

[Hochmuth, Roland M]

Hi John, Comments in-line below. I'm hoping that someone else will add more 
details.




On 4/17/17, 2:50 PM, "John Dickinson"  wrote:

>Moasca-teers
>
>As the migration away from Launchpad and to Storyboard moves forward,
>the Swift team has been considering making the move. Monasca has
>already made the move, so I'd love to hear your thoughts on that
>process.
>
>1) How did you do the change? All at once or gradually? If you did it
>over again, would you do it the same way?

[RH]: The change was done all at once and yes I would do it the same way. The 
migration went smoothly.
>
>2) Are you missing anything from the migration? How do you manage
>security bugs that are embargoed?

[RH]: It hasn't been very long since the change. I don't believe we've run into 
any issues other than folks getting used to it. For example, getting the story 
and task ID in the commit message.
>
>3) How are you managing being "different" in the OpenStack community
>for where to go file bugs or track work?

[RH]: It takes a bit of reminding as the old habits are hard to change. Since 
our community of developers is rather small we are able to track this. However, 
we have had some bugs get created in launchpad after the merge, which we'll 
need to migrate to storyboard. 
>
>4) Have you had any negative impact from old links to Launchpad bugs?
>What about links in commit messages? How did you manage links in
>patches that were open at the time of migration?

[RH]: It has been a little painful getting links in commit messages updated.
>
>5) What other thoughts do you have on the move?

[RH]: That is a good question. Maybe we should do a retrospective on this topic 
during our next meeting.
>
>Thank you for your time and thoughts,
>
>
>John
>
>
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][swift][storyboard] migration experience

[John Dickinson]

Moasca-teers

As the migration away from Launchpad and to Storyboard moves forward,
the Swift team has been considering making the move. Monasca has
already made the move, so I'd love to hear your thoughts on that
process.

1) How did you do the change? All at once or gradually? If you did it
over again, would you do it the same way?

2) Are you missing anything from the migration? How do you manage
security bugs that are embargoed?

3) How are you managing being "different" in the OpenStack community
for where to go file bugs or track work?

4) Have you had any negative impact from old links to Launchpad bugs?
What about links in commit messages? How did you manage links in
patches that were open at the time of migration?

5) What other thoughts do you have on the move?


Thank you for your time and thoughts,


John







signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Grafana "app" for Monasca

[Steve Simpson]

Hi Roland,

That's great to hear. Initially it was only an experiment to see what
could be done inside Grafana with its "app plugin" concept, but
progressed quite fast into something quite usable, so thought we'd
share it early on.

Yes I've been following the Grafana progress quite closely. So as it
happens, because of the way the plugin makes requests (via the
datasource), it takes advantage of the current Keystone fork, so will
hopefully be ready to take advantage of any future development in this
area.

To get parity with the Horizon UI (which we think is great BTW -
deploying it is just a hard sell in our environment), there's a few
things left to do at a minimum:

- Alarm history page
- "Show series" dashboard/link
- Paging/filtering/sorting options
- Better alarm definition editor

I'm sure there's plenty of UI improvements to be had too - we're not
particularly wedded to the design and would appreciate feedback. We'd
love some help getting it into shape - even if it's just tyre kicking,
bug finding, or code review/refactoring.

Cheers,
Steve

On Mon, Mar 27, 2017 at 11:59 PM, Hochmuth, Roland M
 wrote:
> Hi Steve, This is awesome. We are very interested in this work! I was just 
> talking to Grafana Labs about this.
>
> I should also mention that we are in the process of getting Keystone 
> authentication built-in to Grafana so that we don't have to maintain a 
> separate fork. I'm assuming that work will proceed, but it is contingent on a 
> contract that I'm working through. Grafana Labs needed to be involved on the 
> authentication plugin that is being added to Grafana.
>
> How much work do you believe is remaining to complete this? I would also be 
> very interested in reviewing this and helping out where I can on code. We 
> could potentially create an upstream repo in the openstack org.
>
> Regards --Roland
>
>
>
>
> On 3/27/17, 4:40 PM, "Brandt, Ryan"  wrote:
>
>>
>>
>>On 3/27/17, 10:01 AM, "Steve Simpson"  wrote:
>>
>>>Hi,
>>>
>>>We have been working on prototyping an "app" for Grafana which can be
>>>used to view/configure alarm definitions, notifications and alarms.
>>>This is still work-in-progress (insert normal disclaimer here), but is
>>>usable enough to get a feel for what we would like to achieve. We
>>>would like some feedback on whether this is something Monasca would be
>>>interested in collaborating on or adopting upstream. If so, we may be
>>>able to commit more development resource to get it polished.
>>>
>>>https://github.com/stackhpc/monasca-grafana-app
>>>
>>>In particular what spurred this was a discussion at the mid-cycle
>>>around using Monasca outside an OpenStack environment or for
>>>monitoring bare-metal. As it happens this aligns with our
>>>requirements; in the environment we will be deploying in, we will
>>>likely not be able to deploy the Horizon UI component.
>>>
>>>Cheers,
>>>Steve
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Grafana "app" for Monasca

[Hochmuth, Roland M]

Hi Steve, This is awesome. We are very interested in this work! I was just 
talking to Grafana Labs about this.

I should also mention that we are in the process of getting Keystone 
authentication built-in to Grafana so that we don't have to maintain a separate 
fork. I'm assuming that work will proceed, but it is contingent on a contract 
that I'm working through. Grafana Labs needed to be involved on the 
authentication plugin that is being added to Grafana.

How much work do you believe is remaining to complete this? I would also be 
very interested in reviewing this and helping out where I can on code. We could 
potentially create an upstream repo in the openstack org.

Regards --Roland




On 3/27/17, 4:40 PM, "Brandt, Ryan"  wrote:

>
>
>On 3/27/17, 10:01 AM, "Steve Simpson"  wrote:
>
>>Hi,
>>
>>We have been working on prototyping an "app" for Grafana which can be
>>used to view/configure alarm definitions, notifications and alarms.
>>This is still work-in-progress (insert normal disclaimer here), but is
>>usable enough to get a feel for what we would like to achieve. We
>>would like some feedback on whether this is something Monasca would be
>>interested in collaborating on or adopting upstream. If so, we may be
>>able to commit more development resource to get it polished.
>>
>>https://github.com/stackhpc/monasca-grafana-app
>>
>>In particular what spurred this was a discussion at the mid-cycle
>>around using Monasca outside an OpenStack environment or for
>>monitoring bare-metal. As it happens this aligns with our
>>requirements; in the environment we will be deploying in, we will
>>likely not be able to deploy the Horizon UI component.
>>
>>Cheers,
>>Steve
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Grafana "app" for Monasca

[Steve Simpson]

Hi,

We have been working on prototyping an "app" for Grafana which can be
used to view/configure alarm definitions, notifications and alarms.
This is still work-in-progress (insert normal disclaimer here), but is
usable enough to get a feel for what we would like to achieve. We
would like some feedback on whether this is something Monasca would be
interested in collaborating on or adopting upstream. If so, we may be
able to commit more development resource to get it polished.

https://github.com/stackhpc/monasca-grafana-app

In particular what spurred this was a discussion at the mid-cycle
around using Monasca outside an OpenStack environment or for
monitoring bare-metal. As it happens this aligns with our
requirements; in the environment we will be deploying in, we will
likely not be able to deploy the Horizon UI component.

Cheers,
Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] future of thresholder on Storm

[Brandt, Ryan]

Hello Joachim, all,

I’m not aware of an upcoming or existing replacement for the thresholding 
engine, Roland may be able to speak on that, but the Monasca query language is 
currently expected to be implemented in the existing engine.

Thanks,
Ryan

From: "Barheine, Joachim" 
<joachim.barhe...@sap.com<mailto:joachim.barhe...@sap.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, March 13, 2017 at 2:10 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [monasca] future of thresholder on Storm

Hi all,

What are your plans for the Monasca thresholder on Apache Storm, especially 
with respect to the upcoming Monasca query language?

I saw that there is a component monasca-transform that is based on Apache Spark.

Are there plans to build a new alarming engine on Spark that is for example 
supporting mathematical expressions and multiple metrics in alarm rules?

Thanks and regards
Joachim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] future of thresholder on Storm

[Barheine, Joachim]

Hi all,

What are your plans for the Monasca thresholder on Apache Storm, especially 
with respect to the upcoming Monasca query language?

I saw that there is a component monasca-transform that is based on Apache Spark.

Are there plans to build a new alarming engine on Spark that is for example 
supporting mathematical expressions and multiple metrics in alarm rules?

Thanks and regards
Joachim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] cassandra support in Monasca

[witold.be...@est.fujitsu.com]

Hi Pradeep,

HPE has investigated the use of Cassandra for Monasca and came to the 
conclusion that it is not a good choice. One of the problems is that Cassandra 
is not performant when querying across big data sets with many dimension 
key-value combinations. As KairosDB is based on Cassandra it suffers from the 
same problems.

The excerpt from KariosDB documentation [1]:

“So if you have a million tag/value combinations, phase 1 will always take a 
few seconds to complete. Phase 2 could be fast if you filter by tags so that 
only a few partitions are read or it could be slow if you have to read the data 
from all one million partitions.

How do you know if what you are planning is going to be fast enough? From our 
experience if you have 10's of thousands of tag combinations you will be fine. 
Once you start getting towards a million you will be in for trouble.”


The existing code for Cassandra is planned to be removed.


Greetings
Witek

[1] https://github.com/kairosdb/kairosdb/wiki/Query-Performance


From: Pradeep Singh [mailto:ps4openst...@gmail.com]
Sent: Mittwoch, 1. März 2017 06:51
To: Shinya Kawabata <s-kawab...@wx.jp.nec.com>
Cc: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; roland.hochm...@hpe.com
Subject: Re: [openstack-dev] [monasca] cassandra support in Monasca

Hello,

I have registered a BP[1] for that.
Please let me know if you have any concerns.

[1]https://blueprints.launchpad.net/monasca/+spec/kairosdb-support


Thanks,
Pradeep Singh

On Fri, Feb 24, 2017 at 2:20 PM, Shinya Kawabata 
<s-kawab...@wx.jp.nec.com<mailto:s-kawab...@wx.jp.nec.com>> wrote:
Hi Pradeep

Basic Cassandra support is already implemented.
But there are some performance problems.
These performance problems are difficult to enhance.
So we are planning to switch other DB and will let Cassandra deprecated.
KariosDB is one of candidates and not implemented yet.
KariosDB is build-on Cassandra so you might have problems we had.

Regards
Shinya Kawabata

> -Original Message-
> From: Pradeep Singh 
> [mailto:ps4openst...@gmail.com<mailto:ps4openst...@gmail.com>]
> Sent: Thursday, February 23, 2017 2:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Cc: Kawabata Shinya 
> <s-kawab...@wx.jp.nec.com<mailto:s-kawab...@wx.jp.nec.com>>;
> santhosh.fernan...@gmail.com<mailto:santhosh.fernan...@gmail.com>
> Subject: [openstack-dev][monasca] cassandra support in Monasca
>
> Hello,
>
> Could you please suggest status of Cassandra support in Monasca.
> Is there any plan to support  kairosdb?
> If it is not implemented then we can take kairosdb support work.
>
> Thanks,
> Pradeep Singh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] cassandra support in Monasca

[Pradeep Singh]

Hello,

I have registered a BP[1] for that.
Please let me know if you have any concerns.

[1]https://blueprints.launchpad.net/monasca/+spec/kairosdb-support


Thanks,
Pradeep Singh

On Fri, Feb 24, 2017 at 2:20 PM, Shinya Kawabata <s-kawab...@wx.jp.nec.com>
wrote:

> Hi Pradeep
>
> Basic Cassandra support is already implemented.
> But there are some performance problems.
> These performance problems are difficult to enhance.
> So we are planning to switch other DB and will let Cassandra deprecated.
> KariosDB is one of candidates and not implemented yet.
> KariosDB is build-on Cassandra so you might have problems we had.
>
> Regards
> Shinya Kawabata
>
> > -Original Message-
> > From: Pradeep Singh [mailto:ps4openst...@gmail.com]
> > Sent: Thursday, February 23, 2017 2:39 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev@lists.openstack.org>
> > Cc: Kawabata Shinya <s-kawab...@wx.jp.nec.com>;
> > santhosh.fernan...@gmail.com
> > Subject: [openstack-dev][monasca] cassandra support in Monasca
> >
> > Hello,
> >
> > Could you please suggest status of Cassandra support in Monasca.
> > Is there any plan to support  kairosdb?
> > If it is not implemented then we can take kairosdb support work.
> >
> > Thanks,
> > Pradeep Singh
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Baremetal and LXD monitoring

[Santhosh Fernandes]

Hi All,

Do we have support for Baremetal and LXD monitoring in monasca?
Are we planning this support ?

Thanks,
Santhosh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] cassandra support in Monasca

[Shinya Kawabata]

Hi Pradeep

Basic Cassandra support is already implemented.
But there are some performance problems.
These performance problems are difficult to enhance.
So we are planning to switch other DB and will let Cassandra deprecated.
KariosDB is one of candidates and not implemented yet.
KariosDB is build-on Cassandra so you might have problems we had.

Regards
Shinya Kawabata

> -Original Message-
> From: Pradeep Singh [mailto:ps4openst...@gmail.com]
> Sent: Thursday, February 23, 2017 2:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Cc: Kawabata Shinya <s-kawab...@wx.jp.nec.com>;
> santhosh.fernan...@gmail.com
> Subject: [openstack-dev][monasca] cassandra support in Monasca
> 
> Hello,
> 
> Could you please suggest status of Cassandra support in Monasca.
> Is there any plan to support  kairosdb?
> If it is not implemented then we can take kairosdb support work.
> 
> Thanks,
> Pradeep Singh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] cassandra support in Monasca

[Pradeep Singh]

Hello,

Could you please suggest status of Cassandra support in Monasca.
Is there any plan to support  kairosdb?
If it is not implemented then we can take kairosdb support work.

Thanks,
Pradeep Singh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Ideas to work on

[An Qi YL Lu]

Hi Roland
I went on holiday for last week. I’ll send you a notification next time. Sorry for being absent from last weekly meeting.
According to the comments that you gave, I can see the retention policy partly depends on metrics deleting. There can also be an option that we make a patch for influxDB to enable the basic support for retention on series. But this option seems take great effort. So in my opinion, we should implement metrics deleting before retention policy.
If we decide to run a scheduled job to simulate the retention policy, what tools will you suggest to host the job? I know there is a schedule module in python. (https://docs.python.org/2/library/sched.html) But it doesn’t seem appropriate for our consequence.
I think we can begin from metrics deleting. You talked about changing the storage of metrics. Shall we start from redesign the data storage structure? What is in your mind? I am going to study the current storage structure for a bit further now.
What shall I do next if I decide to work on metrics deleting? Do I need to write a whiteboard describing the detailed design?
Best,Anqi
 
 
- Original message -From: "Hochmuth, Roland M" To: "openstack-dev@lists.openstack.org" Cc: An Qi YL Lu/China/IBM@IBMCNSubject: Re: [monasca] Ideas to work onDate: Tue, Feb 14, 2017 10:05 AM 
Hi Anqi, See my comments listed below. Regards --Roland
 
  
From: An Qi YL Lu Date: Sunday, February 12, 2017 at 8:29 PMTo: Roland Hochmuth Cc: OpenStack List Subject: Re: [monasca] Ideas to work on 
  
Hi Roland
 
I am not sure whether you received my last email because I got a delivery failure notification. I am sending this again to ensure that you can see this email.
 
Best,
Anqi
 
- Original message -From: An Qi YL Lu/China/IBMTo: roland.hochm...@hpe.comCc: openstack-dev@lists.openstack.orgSubject: Re: [monasca] Ideas to work onDate: Fri, Feb 10, 2017 5:14 PM  
Hi Roland
 
Thanks for your suggestions. The list you made is useful, helping me get clues in areas that I can work on. I spent some time doing investigation in the bps that you introduced.
 
I am most interested in data retention and metrics deleting.
 
Data retention: I had a quick look into the data retention policy of influxDB. It apparently support different retention policy for different series. To my understanding, the whiteboard in this bp has a straightforward design for this feature. I didn't quite get what is the complex point. Could you please shed some light so I can learn where the complicated part is?  
The retention policy specified in the bp, https://blueprints.launchpad.net/monasca/+spec/per-project-data-retention,  is per project. InfluxDB allows retention policies to be set per database, https://docs.influxdata.com/influxdb/v1.2/query_language/database_management/#create-retention-policies-with-create-retention-policy.
 
Currently, we store all metrics for all tenants in one database. One approach, which would involve a bit of re-engineering if we choose to do it, would be to store metrics for a project in a database for each project.
 
I could also imagine having retention policies per metric per tenant. For example, there might be metrics for metering that should be stored for a longer period than operational metrics. There isn't a way to do this directly in InfluxDB using the built-in data retention policy. However, it could possibly be done using delete and scheduling jobs that periodically run that prune the database.
 
For the Vertica database, we, as in HPE, simulate retention policies by running a cron job that drops partitions after some period of time, such as 45 days. Charter has a more sophisticated cron job that deletes metrics from specific tenants at different periods than the operational metrics. For example, tenants of the cloud might have their metrics deleted every two weeks. Metering metrics might be deleted every 13 months.
 
The problem with deleting specific metrics is the performance. Dropping partitions is extremely fast. However, deleting metrics might be slow and also lock the database and prevent writes and/or queries to it. Therefore, to delete metrics, you could trickle deletes in, reducing the overall impact for any period of time, or do in the Charter case, run the deletion script at 2:00 AM in the morning, when usage of the system is light. 
 
Metrics deleting: In influxDB 1.1 (or any version after 0.9), it supports deleting series, though you cannot specify time interval for this operation. It simply deletes all points from a series in a database. I think one of the tricky parts is to decide the data dependent on a metric to be deleted, such as measurements, alarms. Please point it out if my understanding is not precise. 
The problem I believe is that a single series in InfluxDB has the data for multiple tenants. Deleting a single series would then 

Re: [openstack-dev] [monasca] Ideas to work on

[Hochmuth, Roland M]

Hi Anqi, See my comments listed below. Regards --Roland

From: An Qi YL Lu >
Date: Sunday, February 12, 2017 at 8:29 PM
To: Roland Hochmuth >
Cc: OpenStack List 
>
Subject: Re: [monasca] Ideas to work on

Hi Roland

I am not sure whether you received my last email because I got a delivery 
failure notification. I am sending this again to ensure that you can see this 
email.

Best,
Anqi

- Original message -
From: An Qi YL Lu/China/IBM
To: roland.hochm...@hpe.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [monasca] Ideas to work on
Date: Fri, Feb 10, 2017 5:14 PM

Hi Roland

Thanks for your suggestions. The list you made is useful, helping me get clues 
in areas that I can work on. I spent some time doing investigation in the bps 
that you introduced.

I am most interested in data retention and metrics deleting.

Data retention: I had a quick look into the data retention policy of influxDB. 
It apparently support different retention policy for different series. To my 
understanding, the whiteboard in this bp has a straightforward design for this 
feature. I didn't quite get what is the complex point. Could you please shed 
some light so I can learn where the complicated part is?
The retention policy specified in the bp, 
https://blueprints.launchpad.net/monasca/+spec/per-project-data-retention,  is 
per project. InfluxDB allows retention policies to be set per database, 
https://docs.influxdata.com/influxdb/v1.2/query_language/database_management/#create-retention-policies-with-create-retention-policy.

Currently, we store all metrics for all tenants in one database. One approach, 
which would involve a bit of re-engineering if we choose to do it, would be to 
store metrics for a project in a database for each project.

I could also imagine having retention policies per metric per tenant. For 
example, there might be metrics for metering that should be stored for a longer 
period than operational metrics. There isn't a way to do this directly in 
InfluxDB using the built-in data retention policy. However, it could possibly 
be done using delete and scheduling jobs that periodically run that prune the 
database.

For the Vertica database, we, as in HPE, simulate retention policies by running 
a cron job that drops partitions after some period of time, such as 45 days. 
Charter has a more sophisticated cron job that deletes metrics from specific 
tenants at different periods than the operational metrics. For example, tenants 
of the cloud might have their metrics deleted every two weeks. Metering metrics 
might be deleted every 13 months.

The problem with deleting specific metrics is the performance. Dropping 
partitions is extremely fast. However, deleting metrics might be slow and also 
lock the database and prevent writes and/or queries to it. Therefore, to delete 
metrics, you could trickle deletes in, reducing the overall impact for any 
period of time, or do in the Charter case, run the deletion script at 2:00 AM 
in the morning, when usage of the system is light.

Metrics deleting: In influxDB 1.1 (or any version after 0.9), it supports 
deleting series, though you cannot specify time interval for this operation. It 
simply deletes all points from a series in a database. I think one of the 
tricky parts is to decide the data dependent on a metric to be deleted, such as 
measurements, alarms. Please point it out if my understanding is not precise.
The problem I believe is that a single series in InfluxDB has the data for 
multiple tenants. Deleting a single series would then result in deleting series 
for all tenants. Similar to data retention policies, to support deletion of 
metrics, by metric name and optional dimensions, the storage of metrics would 
need to be handled differently and/or some other solution designed.


I would like to look at logs publishing as well. But unfortunately I did not 
find the monasca-log-api doc, which is supposed to be at 
https://github.com/openstack/monasca-log-api/tree/master/docs . I don't know 
how this log-api works now. Please share me a copy of the doc if you have one.
The new changes proposed by Steve Simpson are in the review that he just 
published at, https://review.openstack.org/#/c/433016/.

The current documentation is now under a slightly different directory than the 
link above at, 
https://github.com/openstack/monasca-log-api/blob/master/documentation/monasca-log-api-spec.md.

Best,
Anqi

- Original message -
From: "Hochmuth, Roland M" 
>
To: OpenStack List 
>, 
An Qi YL Lu/China/IBM@IBMCN
Cc:
Subject: [monasca] Ideas to work on
Date: Fri, Feb 10, 2017 

[openstack-dev] [monasca] Log Query API Design

[Steve Simpson]

Hi,

For those interested, I have been expanding on the initial design for
a simple query API to add to monasca-log-api. The design is available
here:

https://wiki.openstack.org/wiki/Monasca/Logging/Query_API_Design#Design:_Log_Listing

I have proposed the initial "Log Listing" part of the API here:

https://review.openstack.org/#/c/433016/

Would appreciate comments especially from those currently deploying
the monasca-log-api.

Cheers,
Steve Simpson
(stevejims Launchpad/IRC)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Ideas to work on

[witold.be...@est.fujitsu.com]

Hi,

Here the URL to monasca-log-api documentation [1].

Cheers
Witek


[1] https://github.com/openstack/monasca-log-api/tree/master/documentation



I would like to look at logs publishing as well. But unfortunately I did not 
find the monasca-log-api doc, which is supposed to be at 
https://github.com/openstack/monasca-log-api/tree/master/docs . I don't know 
how this log-api works now. Please share me a copy of the doc if you have one.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Failed to upgrade monasca source code in devstack

[An Qi YL Lu]

Hi all
I failed to do the unstack and stack operations with devstack when I want to pull the latest Monasca code and upgrade related projects.
I took following steps:
go to /opt/stackgo to the monasca project folder that I want to upgraderun git pullrun unstack.shrun stack.sh
The full error trace is shown as below:
ubuntu@monasca-devstack:~/devstack$ bash stack.sh
+ unset GREP_OPTIONS
+ unset LANG
+ unset LANGUAGE
+ LC_ALL=C
+ export LC_ALL
+ umask 022
+ PATH=/home/ubuntu/.nvm/versions/node/v4.0.0/bin:/opt/monasca/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/sbin:/usr/sbin:/sbin
+++ dirname stack.sh
++ cd .
++ pwd
+ TOP_DIR=/home/ubuntu/devstack
+ NOUNSET=
+ [[ -n '' ]]
++ date +%s
+ DEVSTACK_START_TIME=1486958013
+ [[ -r /home/ubuntu/devstack/.stackenv ]]
+ rm /home/ubuntu/devstack/.stackenv
+ FILES=/home/ubuntu/devstack/files
+ '[' '!' -d /home/ubuntu/devstack/files ']'
+ '[' '!' -d /home/ubuntu/devstack/inc ']'
+ '[' '!' -d /home/ubuntu/devstack/lib ']'
+ [[ '' == \y ]]
+ [[ 1000 -eq 0 ]]
+ [[ -n /opt/monasca ]]
+ set +o xtrace
You appear to be running under a python virtualenv.
DevStack does not support this, as we may break the
virtualenv you are currently in by modifying
external system-level components the virtualenv relies on.
We recommend you use a separate virtual-machine if
you are worried about DevStack taking over your system.

I checked $VIRTUAL_ENV variable, which pointed to /opt/monasca. So I simply took a rm -rf /opt/monasca* operation, thinking that these virtual environment workspace lead to the failure. But after that, when I rerun stack.sh, I am blocked by this error:
/home/ubuntu/devstack/functions-common: line 511: cd: /opt/stack/monasca-statsd: No such file or directory

Could you please shed some light on how to correctly upgrade Monasca project in devstack environment? Cheers :)
Best,Anqi
​


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] Ideas to work on

[An Qi YL Lu]

Hi Roland
 
I am not sure whether you received my last email because I got a delivery failure notification. I am sending this again to ensure that you can see this email.
 
Best,
Anqi
 
- Original message -From: An Qi YL Lu/China/IBMTo: roland.hochm...@hpe.comCc: openstack-dev@lists.openstack.orgSubject: Re: [monasca] Ideas to work onDate: Fri, Feb 10, 2017 5:14 PM 
Hi Roland
 
Thanks for your suggestions. The list you made is useful, helping me get clues in areas that I can work on. I spent some time doing investigation in the bps that you introduced.
 
I am most interested in data retention and metrics deleting.
 
Data retention: I had a quick look into the data retention policy of influxDB. It apparently support different retention policy for different series. To my understanding, the whiteboard in this bp has a straightforward design for this feature. I didn't quite get what is the complex point. Could you please shed some light so I can learn where the complicated part is?
 
Metrics deleting: In influxDB 1.1 (or any version after 0.9), it supports deleting series, though you cannot specify time interval for this operation. It simply deletes all points from a series in a database. I think one of the tricky parts is to decide the data dependent on a metric to be deleted, such as measurements, alarms. Please point it out if my understanding is not precise.
 
I would like to look at logs publishing as well. But unfortunately I did not find the monasca-log-api doc, which is supposed to be at https://github.com/openstack/monasca-log-api/tree/master/docs . I don't know how this log-api works now. Please share me a copy of the doc if you have one.
 
Best,
Anqi
 
- Original message -From: "Hochmuth, Roland M" To: OpenStack List , An Qi YL Lu/China/IBM@IBMCNCc:Subject: [monasca] Ideas to work onDate: Fri, Feb 10, 2017 11:13 AM 
Hi Anqi, You had expressed a strong interest in working on Monasca the other day in our Weekly Monasca Team Meeting. I owed you a response. The team had also asked me to also keep them in the loop. Here is a list that I feel is interesting, that is not trivial or extremely complex (just right hopefully), and doesn't overlap with some of the areas that other developers are working on, and consequently difficult to coordinate in a limited time.
RBAC: Currently, the Python API doesn't fully support Role Based Access Controls (RBAC) in the API. We've had discussions on this topic, but oddly, there isn't a blueprint written for this. But, this would be very useful to implement in the APIs similar to what other OpenStack projects support.Data retention: https://blueprints.launchpad.net/monasca/+spec/per-project-data-retention. We haven't completely reviewed and or approved this blueprint, but it would be very useful to add support for per-project, or per-metric data retention. This would involve understanding how data retention works in InfluxDB. We would also want to have some design discussion prior to proceeding, as it is probably more complex than described in the bp.Publish logs and/or metrics to topics selectively. https://blueprints.launchpad.net/monasca/+spec/publish-logs-to-topic-selectively. In the context of metrics, this would be useful to identifying specific metrics as metering as opposed to monitoring metrics and allow them to be published to different Kafka topics as a result. The way this would be used is that the downstream Monasca Transform Engine would only get metrics sent to it that will be transformed and therefore doesn't need to filter them, which would help improve performance dramatically. For logging, it would help identity operational logs from audit logs. It could also be used to identity high priority metrics such that they could be published to a high-priority metrics topic in Kafka. There are several more contexts in which this is useful.Delete metrics: https://blueprints.launchpad.net/monasca/+spec/delete-metrics. Basically adding the ability to delete metrics using the Monasca API. Typically, time series databases are not very good at deletes. We haven't tried to do this with InfluxDB, and while this might seem an easy task, it is a lot more involved than issuing the obvious and straight-forward DELETE command.
I hope this helps. Let me know if you want to discuss further or want more ideas.
 
Regards --Roland
 
 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Ideas to work on

[Hochmuth, Roland M]

Hi Anqi, You had expressed a strong interest in working on Monasca the other 
day in our Weekly Monasca Team Meeting. I owed you a response. The team had 
also asked me to also keep them in the loop. Here is a list that I feel is 
interesting, that is not trivial or extremely complex (just right hopefully), 
and doesn't overlap with some of the areas that other developers are working 
on, and consequently difficult to coordinate in a limited time.

  1.  RBAC: Currently, the Python API doesn't fully support Role Based Access 
Controls (RBAC) in the API. We've had discussions on this topic, but oddly, 
there isn't a blueprint written for this. But, this would be very useful to 
implement in the APIs similar to what other OpenStack projects support.
  2.  Data retention: 
https://blueprints.launchpad.net/monasca/+spec/per-project-data-retention. We 
haven't completely reviewed and or approved this blueprint, but it would be 
very useful to add support for per-project, or per-metric data retention. This 
would involve understanding how data retention works in InfluxDB. We would also 
want to have some design discussion prior to proceeding, as it is probably more 
complex than described in the bp.
  3.  Publish logs and/or metrics to topics selectively. 
https://blueprints.launchpad.net/monasca/+spec/publish-logs-to-topic-selectively.
 In the context of metrics, this would be useful to identifying specific 
metrics as metering as opposed to monitoring metrics and allow them to be 
published to different Kafka topics as a result. The way this would be used is 
that the downstream Monasca Transform Engine would only get metrics sent to it 
that will be transformed and therefore doesn't need to filter them, which would 
help improve performance dramatically. For logging, it would help identity 
operational logs from audit logs. It could also be used to identity high 
priority metrics such that they could be published to a high-priority metrics 
topic in Kafka. There are several more contexts in which this is useful.
  4.  Delete metrics: 
https://blueprints.launchpad.net/monasca/+spec/delete-metrics. Basically adding 
the ability to delete metrics using the Monasca API. Typically, time series 
databases are not very good at deletes. We haven't tried to do this with 
InfluxDB, and while this might seem an easy task, it is a lot more involved 
than issuing the obvious and straight-forward DELETE command.

I hope this helps. Let me know if you want to discuss further or want more 
ideas.

Regards --Roland
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Monasca Ocata midcycle

[Hochmuth, Roland M]

Hi Everyone, We will be holding a Monasca Midcycle on Wednesday February 22nd, 
and Thursday February 23rd, 2017, via Lync/Skype video conferencing. The 
etherpad for the midcycle is located at, 
https://etherpad.openstack.org/p/monasca_ocata_midcycle. The etherpad has the 
Lync/Skype connection details and time.

There is also a tentative agenda that is posted in the etherpad, but the 
details need to be organized further. There are a large number of topics 
already, but please feel free to add more to the agenda.

Sorry that we didn't have enough members from the Monasca team that were able 
to attend the PTG. However, if there are others that are attending the PTG 
would like to connect with the Monasca Team, this would be a good time to do 
that, as we will all be available online. Please let us know if you are 
interested in a discussion. And if the PTG isn't a good time either, then we 
can schedule a discussion for another time.

Regards --Roland
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] Monasca devstack installation is failing

[Brandt, Ryan]

I think this is going to require more time and information. Perhaps you could 
open a launchpad bug to track this?

I just brought up a new vagrant successfully yesterday, would you mind checking 
if you have the latest code and trying again? Also, if there is anything else 
relating to storm or monasca-thresh in that last log you provided, could you 
include that as well?

Thanks,
Ryan

From: Pradeep Singh <ps4openst...@gmail.com<mailto:ps4openst...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, January 4, 2017 at 11:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Monasca] Monasca devstack installation is failing


Hello,

I am trying to install Monasca devstack using vagrant file given in monasca-ui 
repo.

And its failing again and again with below error.

Could you please help me, i will really appreciate your help.


==> default: 2017-01-05 06:28:06.125 | ++ functions-common:start_service:2306   
   :   sudo /bin/systemctl start monasca-thresh

==> default: 2017-01-05 06:28:27.440 | Job for monasca-thresh.service failed 
because the control process exited with error code. See "systemctl status 
monasca-thresh.service" and "journalctl -xe" for details.

==> default: 2017-01-05 06:28:27.444 | ++ 
/opt/stack/monasca-api/devstack/plugin.sh:start_monasca_services:235 :   
restart_service monasca-thresh

==> default: 2017-01-05 06:28:27.447 | ++ functions-common:restart_service:2282 
   :   '[' -x /bin/systemctl ']'

==> default: 2017-01-05 06:28:27.450 | ++ functions-common:restart_service:2283 
   :   sudo /bin/systemctl restart monasca-thresh

==> default: 2017-01-05 06:28:47.368 | Job for monasca-thresh.service failed 
because the control process exited with error code. See "systemctl status 
monasca-thresh.service" and "journalctl -xe" for details.

vagrant@devstack:~$ systemctl status monasca-thresh.service

● monasca-thresh.service - LSB: Monitoring threshold engine running under storm

   Loaded: loaded (/etc/init.d/monasca-thresh; bad; vendor preset: enabled)

   Active: failed (Result: exit-code) since Thu 2017-01-05 06:28:47 UTC; 27s ago

 Docs: man:systemd-sysv-generator(8)

  Process: 28638 ExecStart=/etc/init.d/monasca-thresh start (code=exited, 
status=1/FAILURE)


Jan 05 06:28:47 devstack monasca-thresh[28638]: main()

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File 
"/opt/storm/current/bin/storm.py", line 766, in main

Jan 05 06:28:47 devstack monasca-thresh[28638]: (COMMANDS.get(COMMAND, 
unknown_command))(*ARGS)

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File 
"/opt/storm/current/bin/storm.py", line 248, in jar

Jan 05 06:28:47 devstack monasca-thresh[28638]: os.remove(tmpjar)

Jan 05 06:28:47 devstack monasca-thresh[28638]: OSError: [Errno 2] No such file 
or directory: '/tmp/30c1980ed31011e68cd3080027b55b5e.jar'

Jan 05 06:28:47 devstack systemd[1]: monasca-thresh.service: Control process 
exited, code=exited status=1

Jan 05 06:28:47 devstack systemd[1]: Failed to start LSB: Monitoring threshold 
engine running under storm.

Jan 05 06:28:47 devstack systemd[1]: monasca-thresh.service: Unit entered 
failed state.

Jan 05 06:28:47 devstack systemd[1]: monasca-thresh.service: Failed with result 
'exit-code'.


Thanks,

Pradeep



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Monasca devstack installation is failing

[Pradeep Singh]

*Hello,*

*I am trying to install Monasca devstack using vagrant file given in
monasca-ui repo.*

*And its failing again and again with below error.*

*Could you please help me, i will really appreciate your help.*


==> default: 2017-01-05 06:28:06.125 | ++
functions-common:start_service:2306  :   sudo /bin/systemctl start
monasca-thresh

==> default: 2017-01-05 06:28:27.440 | Job for monasca-thresh.service
failed because the control process exited with error code. See "systemctl
status monasca-thresh.service" and "journalctl -xe" for details.

==> default: 2017-01-05 06:28:27.444 | ++
/opt/stack/monasca-api/devstack/plugin.sh:start_monasca_services:235 :
restart_service monasca-thresh

==> default: 2017-01-05 06:28:27.447 | ++
functions-common:restart_service:2282:   '[' -x /bin/systemctl ']'

==> default: 2017-01-05 06:28:27.450 | ++
functions-common:restart_service:2283:   sudo /bin/systemctl restart
monasca-thresh

==> default: 2017-01-05 06:28:47.368 | Job for monasca-thresh.service
failed because the control process exited with error code. See "systemctl
status monasca-thresh.service" and "journalctl -xe" for details.

*vagrant@devstack*:*~*$ systemctl status monasca-thresh.service

*●* monasca-thresh.service - LSB: Monitoring threshold engine running under
storm

   Loaded: loaded (/etc/init.d/monasca-thresh; bad; vendor preset: enabled)

   Active: *failed* (Result: exit-code) since Thu 2017-01-05 06:28:47 UTC;
27s ago

 Docs: man:systemd-sysv-generator(8)

  Process: 28638 ExecStart=/etc/init.d/monasca-thresh start *(code=exited,
status=1/FAILURE)*


Jan 05 06:28:47 devstack monasca-thresh[28638]: main()

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File
"/opt/storm/current/bin/storm.py", line 766, in main

Jan 05 06:28:47 devstack monasca-thresh[28638]: (COMMANDS.get(COMMAND,
unknown_command))(*ARGS)

Jan 05 06:28:47 devstack monasca-thresh[28638]:   File
"/opt/storm/current/bin/storm.py", line 248, in jar

Jan 05 06:28:47 devstack monasca-thresh[28638]: os.remove(tmpjar)

Jan 05 06:28:47 devstack monasca-thresh[28638]: OSError: [Errno 2] No such
file or directory: '/tmp/30c1980ed31011e68cd3080027b55b5e.jar'

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Control
process exited, code=exited status=1*

Jan 05 06:28:47 devstack systemd[1]: *Failed to start LSB: Monitoring
threshold engine running under storm.*

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Unit entered
failed state.*

Jan 05 06:28:47 devstack systemd[1]: *monasca-thresh.service: Failed with
result 'exit-code'.*


*Thanks,*

*Pradeep*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca]Monasca event handling capabilities

[Brandt, Ryan]

Hello,

Monasca events handling is an early work in progress, see 
https://wiki.openstack.org/wiki/Monasca/Events for some information.

Information on what metrics are available from each plugin can be found at 
https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md

Custom checks are at 
https://github.com/openstack/monasca-agent/tree/master/monasca_agent/collector/checks_d
Detection plugins are at 
https://github.com/openstack/monasca-agent/tree/master/monasca_setup/detection/plugins

For reference, detection plugins are used to configure check plugins which 
actually collect the metrics. Neutron doesn't have a check plugin, instead it's 
detection plugin configures some standard check plugins to monitor processes 
and http health.

Ryan

From: Pradeep Singh <ps4openst...@gmail.com<mailto:ps4openst...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 3, 2017 at 11:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [monasca]Monasca event handling capabilities

Hello,

Please excuse  me if i asked this question on wrong mailing list.

I have few queries related to Monasca.

1) How do Monasca collects events releases by other openstack services like 
Nova and Cinder?
2) Can monasca collects the metrics from Neutron and other SDN controllers?

please guide me for any documentation if available.

I will be really thankful to you.

Thanks,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca]

[Brandt, Ryan]

Apologies for the delay in response, just returning from the holidays.

>From the trace, it would appear the monasca API is unable to authenticate with 
>keystone. The API’s admin credentials may not be valid (either they do not 
>exist in keystone or are configured incorrectly for the API) which would cause 
>the API to be unable to validate tokens on incoming requests. The admin 
>credentials for the python monasca API are under [keystone_authtoken] in 
>‘/etc/monasca/api-config.conf’.

Ryan

From: Sanjana Pai Nagarmat <sanj...@hitachi.co.in<mailto:sanj...@hitachi.co.in>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, January 2, 2017 at 1:48 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Monasca]

Hello,


I have a clean install of monasca-api and monasca-log-management plugins with 
devstack on ubuntu 14.04.
However when I try using the monasca CLI, I get HTTP 503:Service Unavailable 
error.
I tried accessing the monasca dashboard in Horizon, but that also throws error.

ubuntu@monasca:~$ monasca metric-list
ERROR (exc:80) exception: {"message": "The server is currently unavailable. 
Please try again at a later time.\n\n\n", "code": "503 Service 
Unavailable", "title": "Service Unavailable"}
HTTPException code=503 message={"message": "The server is currently 
unavailable. Please try again at a later time.\n\n\n", "code": "503 
Service Unavailable", "title": "Service Unavailable"}
ubuntu@monasca:~$


The monasca-api log file has the following contents:
2017-01-02 08:15:20,158 DEBUG [gunicorn.error][GreenThread-2] Closing 
connection.
2017-01-02 08:15:24,952 DEBUG [gunicorn.error][GreenThread-5] GET /v2.0/metrics
2017-01-02 08:15:24,954 DEBUG [keystonemiddleware.auth_token][GreenThread-5] 
Authenticating user token
2017-01-02 08:15:24,957 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:24,964 INFO 
[requests.packages.urllib3.connectionpool][GreenThread-5] Resetting dropped 
connection: 127.0.0.1
2017-01-02 08:15:27,342 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,343 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,345 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,346 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,346 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Retrying validation
2017-01-02 08:15:27,347 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:27,535 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,536 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,536 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,536 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,536 CRITICAL [keystonemiddleware.auth_token][GreenThread-5] 
Unable to validate token: Identity server rejected authorization necessary to 
fetch token data
2017-01-02 08:15:27,539 DEBUG [gunicorn.error][GreenThread-5] Closing 
connection.


Further the AUTH_URL is set
ubuntu@monasca:/var/log/monasca/api$ echo $OS_AUTH_URL
http://127.0.0.1:35357/v3/

I would like to mention the status of services:
ubuntu@monasca:~$ sudo service monasca-log-api status
monasca-log-api start/running, process 7938

ubuntu@monasca:~$ sudo service monasca-api status
monasca-api start/running, process 21465

ubuntu@monasca:~/devstack$ keystone service list
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domai

[openstack-dev] [monasca]Monasca event handling capabilities

[Pradeep Singh]

Hello,

Please excuse  me if i asked this question on wrong mailing list.

I have few queries related to Monasca.

1) How do Monasca collects events releases by other openstack services like
Nova and Cinder?
2) Can monasca collects the metrics from Neutron and other SDN controllers?

please guide me for any documentation if available.

I will be really thankful to you.

Thanks,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca]

[Sanjana Pai Nagarmat]

Hello,


I have a clean install of monasca-api and monasca-log-management plugins with 
devstack on ubuntu 14.04.
However when I try using the monasca CLI, I get HTTP 503:Service Unavailable 
error.
I tried accessing the monasca dashboard in Horizon, but that also throws error.

ubuntu@monasca:~$ monasca metric-list
ERROR (exc:80) exception: {"message": "The server is currently unavailable. 
Please try again at a later time.\n\n\n", "code": "503 Service 
Unavailable", "title": "Service Unavailable"}
HTTPException code=503 message={"message": "The server is currently 
unavailable. Please try again at a later time.\n\n\n", "code": "503 
Service Unavailable", "title": "Service Unavailable"}
ubuntu@monasca:~$


The monasca-api log file has the following contents:
2017-01-02 08:15:20,158 DEBUG [gunicorn.error][GreenThread-2] Closing 
connection.
2017-01-02 08:15:24,952 DEBUG [gunicorn.error][GreenThread-5] GET /v2.0/metrics
2017-01-02 08:15:24,954 DEBUG [keystonemiddleware.auth_token][GreenThread-5] 
Authenticating user token
2017-01-02 08:15:24,957 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:24,964 INFO 
[requests.packages.urllib3.connectionpool][GreenThread-5] Resetting dropped 
connection: 127.0.0.1
2017-01-02 08:15:27,342 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,343 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,345 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,346 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,346 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Retrying validation
2017-01-02 08:15:27,347 DEBUG [keystoneauth.identity.v2][GreenThread-5] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens
2017-01-02 08:15:27,535 DEBUG 
[requests.packages.urllib3.connectionpool][GreenThread-5] "POST /v2.0/tokens 
HTTP/1.1" 401 114
2017-01-02 08:15:27,536 DEBUG [keystoneauth.session][GreenThread-5] Request 
returned failure status: 401
2017-01-02 08:15:27,536 INFO [keystonemiddleware.auth_token][GreenThread-5] 
Identity server rejected authorization
2017-01-02 08:15:27,536 WARNING [keystonemiddleware.auth_token][GreenThread-5] 
Identity response: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}
2017-01-02 08:15:27,536 CRITICAL [keystonemiddleware.auth_token][GreenThread-5] 
Unable to validate token: Identity server rejected authorization necessary to 
fetch token data
2017-01-02 08:15:27,539 DEBUG [gunicorn.error][GreenThread-5] Closing 
connection.


Further the AUTH_URL is set
ubuntu@monasca:/var/log/monasca/api$ echo $OS_AUTH_URL
http://127.0.0.1:35357/v3/

I would like to mention the status of services:
ubuntu@monasca:~$ sudo service monasca-log-api status
monasca-log-api start/running, process 7938

ubuntu@monasca:~$ sudo service monasca-api status
monasca-api start/running, process 21465

ubuntu@monasca:~/devstack$ keystone service list
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
Ignoring domain related config project_domain_name because identity API version 
is 2.0
Ignoring domain related config user_domain_name because identity API version is 
2.0
+--+-++
| ID   | Name| Type   |
+--+-++
| 301f29e503c845828ce4a24d61924ded | cinderv3| volumev3   |
| 36ee63e1df644d4780cc2f16e93bc379 | monasca | monitoring |
| 448e665048314cc2af41bbfc99bdf7af | cinderv2| volumev2   |
| 68db6f5f85be4007b0c6550b3fd8468e | neutron | network|
| 7b9313963b094fa0986016adbd6b92fd | cinder  | volume |
| 7fccd72315ba4f6cbd400274054a5c88 | keystone| identity   |
| 8cd5c25a911e468797bad4d709ff1adf | glance  | image  |
| b4c2a0986f674a93b7636d18ef4e81cb | nova| compute|
| f19e24d3633141c4892d10cdead98f20 | nova_legacy | compute_legacy |
+--+-++

Please let me know how I can fix this issue. I want to use monasca logging 
service for my openstack environment.
Thanks in advance.



--Sanjana





__
OpenStack Development Mailing List 

[openstack-dev] [monasca] Team meeting on 28 Dec

[witold.be...@est.fujitsu.com]

Hello everyone, 

should we cancel the team meeting on 28 Dec? Most of us will be in vacation I 
assume.

Greetings
Witek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][oslo] (Re: [oslo] Should we drop kafka driver ?)

[Mehdi Abaakouk]

On Wed, Nov 30, 2016 at 05:44:25PM +0100, Mehdi Abaakouk wrote:

Also, capping libraries is always a bad idea, this is one more example
of why. The lib was capped due to an python-kafka upstream bugs and not
API breakage. Something like != 1.0.0 would be sufficient.


I have proposed to uncap python-kafka https://review.openstack.org/404878

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca][oslo] (Re: [oslo] Should we drop kafka driver ?)

[Mehdi Abaakouk]

Le 2016-11-30 16:56, Davanum Srinivas a écrit :
Problem is with Monasca team having concerns with later python-kafka 
versions

https://bugs.launchpad.net/oslo.messaging/+bug/1639264


Good point, the bug is 1 month old, but the issue is known since 7
months.

At this point I think if we want to keep kafka in oslo.messaging we have
to raise this dep and merge this upgrade patch whatever the Monasca status is.

We can't continue to use thing deprecated since 1 year.

Also, capping libraries is always a bad idea, this is one more example
of why. The lib was capped due to an python-kafka upstream bugs and not
API breakage. Something like != 1.0.0 would be sufficient.

The deprecated API is still in last release of python-kafka, so even it's
slower than with old version, we should not break anything.

sileht

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][oslo] (Re: [oslo] Should we drop kafka driver ?)

[Davanum Srinivas]

Mehdi,

Problem is with Monasca team having concerns with later python-kafka versions
https://bugs.launchpad.net/oslo.messaging/+bug/1639264

Adding them to the subject line

-- Dims

On Wed, Nov 30, 2016 at 10:28 AM, Mehdi Abaakouk  wrote:
> Hi,
>
> I think my subject is clear :) , but I will add some facts that can help
> to the decision:
> * It uses only deprecated python-kafka API [1] [2]
> * It's not python3 compatible [3]
> * We still don't have kafka testing in gate
> So, one year after the driver introduction, this one is still in bad shape
> and doesn't match the requirements [4].
>
> These reviews looks abandoned/outdated/unmaintained:
>
> [1] https://review.openstack.org/#/c/297994/ [2]
> https://review.openstack.org/#/c/332105/
>
> Other links:
>
> [3] https://review.openstack.org/#/c/404802/
> [4]
> http://docs.openstack.org/developer/oslo.messaging/supported-messaging-drivers.html#testing
>
> And of course, we will not drop the code now, but just deprecate it for
> removal.
> Cheers,
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca][release] Release of openstack/monasca-grafana-datasource 1.0.0 failed

[Doug Hellmann]

It looks like the monasca-grafana-datasource repository isn't set up in
the way our release job expects for publishing nodejs projects.

>From the log:

2016-11-15 14:03:26.945891 | + npm install
2016-11-15 14:03:27.287904 | npm ERR! install Couldn't read dependencies
2016-11-15 14:03:27.289483 | npm ERR! Linux 4.4.0-47-generic
2016-11-15 14:03:27.289836 | npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" 
"install"
2016-11-15 14:03:27.290082 | npm ERR! node v4.6.2
2016-11-15 14:03:27.290267 | npm ERR! npm  v2.15.11
2016-11-15 14:03:27.290433 | npm ERR! path 
/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/package.json
2016-11-15 14:03:27.290483 | npm ERR! code ENOPACKAGEJSON
2016-11-15 14:03:27.290750 | npm ERR! errno -2
2016-11-15 14:03:27.290821 | npm ERR! syscall open
2016-11-15 14:03:27.291690 | 
2016-11-15 14:03:27.291865 | npm ERR! package.json ENOENT: no such file or 
directory, open 
'/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/package.json'
2016-11-15 14:03:27.291893 | npm ERR! package.json This is most likely not a 
problem with npm itself.
2016-11-15 14:03:27.291921 | npm ERR! package.json npm can't find a 
package.json file in your current directory.
2016-11-15 14:03:27.297776 | 
2016-11-15 14:03:27.297870 | npm ERR! Please include the following file with 
any support request:
2016-11-15 14:03:27.297901 | npm ERR!  
/home/jenkins/workspace/monasca-grafana-datasource-nodejs4-npm-publish-tarball/npm-debug.log

I don't really know anything about nodejs packaging, so I'm not sure
what the issue is. I do see a plugin.json file, so perhaps this repo is
a different type of nodejs thing than the job expects and we need a
different job?

Doug

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Tue, 15 Nov 2016 14:03:43 +
Subject: [Release-job-failures] Release of openstack/monasca-grafana-datasource 
failed

Build failed.

- monasca-grafana-datasource-nodejs4-npm-publish-tarball 
http://logs.openstack.org/4e/4e822c25c5ce85a55d04ece0e59c7a0bb34c0dd5/release/monasca-grafana-datasource-nodejs4-npm-publish-tarball/2023b67/
 : FAILURE in 2m 02s
- monasca-grafana-datasource-npm-upload monasca-grafana-datasource-npm-upload : 
SKIPPED

--- End forwarded message ---

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?

To increase visibility with the Monasca team, I've also opened this
as:

https://launchpad.net/bugs/1639265

...and for additional safety, the Release Team has decided to hold
off further releases of Monasca deliverables until the copyright
situation you've raised gets sorted out:

http://eavesdrop.openstack.org/meetings/releaseteam/2016/releaseteam.2016-11-04-14.00.html
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] License for monasca-statsd

[Doug Hellmann]

Excerpts from Chuck Short's message of 2016-11-03 15:03:44 -0400:
> Hi,
> 
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?
> 
> Thanks
> chuck

In the release team meeting today we agreed to freeze Monasca releases
until this question is resolved, just to avoid making the situation
"worse" with more releases. Given how close we are to the summit, I
don't expect that to really cause any issues.

When it is fixed, we should go ahead and backport the change to any open
stable branches and prepare new releases from those, too.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 18:17:42 -0400 (-0400), Chuck Short wrote:
> I have checked the version on pypi and tarballs.openstack.org and all the
> versions from monasca-statsd from 1.0.0 onwards provide the incorrect
> LICENSE file.

Right, I'm saying I hope the files which have Apache license headers
in them aren't actually derivatives of something which had a Datadog
license, which would be unfortunate from a legal/copyright
standpoint. Ideally that LICENSE file is just wrong and can be
deleted/replaced, but someone from the Monasca team would need to
weigh in on whether that's the case.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] License for monasca-statsd

[Chuck Short]

On Thu, Nov 3, 2016 at 3:55 PM, Jeremy Stanley  wrote:

> On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> > I was looking at packaging monasca-statsd since it is a dependency for
> > designate, however when I look at the license for it,it says Apache-2.
> > However the LICENSE file included in the source  is that the software is
> > provided as is...etc etc. Could we get some clarification please?
>
> It looks like https://review.openstack.org/123315 added that
> LICENSE file when originally setting up the monasca-statsd repo a
> couple years ago. I see a variety of Datadog repositories in
> circulation using that license, and they seem to refer to it as "a
> simplified BSD license" (which is certainly what it looks like to me
> as well). However, all the individual files added in that change
> which declare a license in their headers seem to use Apache License
> 2.0, which I agree is confusing. Hopefully the Datadog license was
> added here in error, and we've not actually been shipping an
> incorrectly-licensed derivative of their software this entire time?
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

Hi,

I have checked the version on pypi and tarballs.openstack.org and all the
versions from monasca-statsd from 1.0.0 onwards provide the incorrect
LICENSE file.

chuck
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?

It looks like https://review.openstack.org/123315 added that
LICENSE file when originally setting up the monasca-statsd repo a
couple years ago. I see a variety of Datadog repositories in
circulation using that license, and they seem to refer to it as "a
simplified BSD license" (which is certainly what it looks like to me
as well). However, all the individual files added in that change
which declare a license in their headers seem to use Apache License
2.0, which I agree is confusing. Hopefully the Datadog license was
added here in error, and we've not actually been shipping an
incorrectly-licensed derivative of their software this entire time?
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] License for monasca-statsd

[Chuck Short]

Hi,

I was looking at packaging monasca-statsd since it is a dependency for
designate, however when I look at the license for it,it says Apache-2.
However the LICENSE file included in the source  is that the software is
provided as is...etc etc. Could we get some clarification please?

Thanks
chuck
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Virtual Mid Cycle Coordinates - July 20

[Fabio Giannetti (fgiannet)]

>Monasca Mid Cycle Day 2
>July 20 2016
>7am to noon PDT
>
>Webex
>
>
>Join WebEx meeting:
>https://cisco.webex.com/ciscosales/j.php?MTID=m84f9f81d7c1c171be6365716522
>d
>e15e
>
>Meeting number: 205 141 519
>Meeting password: 8VyzUiyr
>
>Join by phone  
>+1-408-525-6800 Call-in toll number (US/Canada)
>+1-866-432-9903 Call-in toll-free number (US/Canada)
>Access code: 205 141 519
>Numeric meeting password: 01558880


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Monasca Mid-Cycle Minutes

[Fabio Giannetti (fgiannet)]

Notes for Monasca July Mid Cycle 2016

Minutes July 19 from 10:30am PDT to

Dimensions Names/Values resources

This blueprint needs to be updated. The PATCH part needs to be updated. The new 
URL is metrics/dimensions/names/values
The use case is driven by Grafana and is part of the templating. In order to 
get the list of unique dimension names you have to do a query for all the 
metrics.
The blueprint is implemented already in Java and Python and the implementation 
has been gone through a good testing. It has been implemented for Vertica and 
InfluxDB.
Brad to update the blueprint to relect the latest design changes.

Open Discussion
Is the vision for this project to be only for Openstack or it is possible to 
extend it to other projects?
The only dependency of the project is on Keystone and once that is removed the 
project can be used.
It is possible in the Python version to remove Keystone from the Pipeline and 
manually provide the header data so then the API will find the context.
Making Monasca more separate from Openstack. This will require a pluggable 
authentication mechanism.
Grafana already supports various Multitenancy capabilties but Kibana is not 
that flexible. It seems both support LDAP.

Retrospective

What we have done good
Cool New feature added. Logging API, deterministic alarms, periodic 
notificaitons
Good progress in adding new features
Multiple metrics was a good perfomance improvement. From 60s to 1s.
Well integrated in the Openstack process.
Good/Flexible architecture
More visibility in the community. Limited contributions from the "other" teams.

What we could have done better
Installation is still complex and cumbersome, not well documented. Need of a 
Monasca administration guide. Better docs in general would help.
Create an official tutorial.
Replacing Java API in Persister. It is difficult for new contributor to come to 
the project. Single API change can take 2 weeks. Java+Python and 3 databases.
Focus on polishing what is already available instead of expanding the scope.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] Announcing Monasca Analytics

[Vaquero Gonzalez, Luis Miguel]

Dear all,

I have the pleasure to introduce you to Monasca analytics, a seamless extension 
of Monanas that enables sharing of infrastructure analytic  recipes across the 
community.

Some of you are probably already familiar with it after we, in a 
"well-orchestrated marketing campaign", pushed 200 commits in one go, making 
Mr. Jenkins very upset.

The time has come to get you back some of your time and speed up complex and 
tedious error finding tasks that can be partially automated and shared in the 
community to make our lives a bit easier.

We are super excited about being part of the OpenStack community.

In the meantime, please feel free to have a look and start contributing :) or 
asking questions!!

https://github.com/openstack/monasca-analytics

Best regards,

Monasca-analytics team


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] metering interval, global/local

[László Hegedüs]

Hi,

as far as I can tell, Monasca does not support different metering intervals for 
different meters. There is the check_freq value in agent.yaml, which is global.
Am I right about this?

Did you consider the option of specifying check_freq for specific meters?

BR,
Laszlo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [monasca] step-by-step installation guide

[Hochmuth, Roland M]

Hi Laszlo, There isn't an official install guide for Monasca. This is one of 
the missing pieces in the Monasca project and I would love to see it added.

There were some blog's written by Victor Munteanu over a year ago that might be 
good referring too.

http://blog.zhaw.ch/icclab/how-to-install-and-setup-monasca-1-3/
http://blog.zhaw.ch/icclab/how-to-install-and-setup-monasca-2-3/
http://blog.zhaw.ch/icclab/how-to-install-and-setup-monasca-3-3/

Regards --Roland


From: László Hegedüs 
<laszlo.hege...@ericsson.com<mailto:laszlo.hege...@ericsson.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, June 22, 2016 at 4:58 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [monasca] step-by-step installation guide

Hi,

does there exist a step-by-step manual installation guide for Monasca? 
Something that is independent of DevStack.

I have manually installed it recently for testing purposes and I could not find 
an up-to-date description.
In case there is a need for it, I can prepare a guide to share on the wiki page 
or in some module's (e.g., monasca-api's) doc.

BR,
Laszlo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [monasca] step-by-step installation guide

[László Hegedüs]

Hi,

does there exist a step-by-step manual installation guide for Monasca? 
Something that is independent of DevStack.

I have manually installed it recently for testing purposes and I could not find 
an up-to-date description.
In case there is a need for it, I can prepare a guide to share on the wiki page 
or in some module's (e.g., monasca-api's) doc.

BR,
Laszlo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] Locked (latched) alarms

[Hochmuth, Roland M]

Hi Witek, Thanks for the blueprint. We can review tomorrow if you would like. 
Personally, I like the term "locked". The alarm definition makes more sense 
(option 2). I don't think an operator will want to lock/latch an alarm 
sub-expression. The operator will want to lock/latch an entire alarm. 
Therefore, what seems to make sense is adding the new capability to the alarm 
definition as it applies to the entire alarm. We had a similar internal 
discussion a couple of months ago, and that is the same conclusion that we came 
too.

Regards --Roland







On 6/21/16, 4:38 AM, "witold.be...@est.fujitsu.com" 
 wrote:

>Hello everyone,
>
>I have written a short blueprint on locked/latched alarms for Monasca [1]. The 
>functionality allows the operator to define an alarm which after transition to 
>ALARM state, stays in that state until it is manually reset.
>
>What name should we use for that? Locked, lockable, latched, sticky? Something 
>else?
>
>I would also welcome feedback on a general implementation idea. Should we make 
>it in the same way as the deterministic alarms, by extending the 
>AlarmExpression? Or would it be enough to add the property to AlarmDefinition 
>(option 2)? I tend to the second solution. The change in the logic of 
>monasca-thresh would then be limited to AlarmThresholdingBolt. 
>evaluateThreshold as far as I understand. Craig and Roland, could you comment 
>on that please?
>
>
>Cheers
>Witek
>
>
>[1] https://blueprints.launchpad.net/monasca/+spec/locked-alarms
>
>
>Witold Bedyk
>Senior Software Engineer
>
>FUJITSU Enabling Software Technology GmbH
>Schwanthalerstr. 75a, 80336 München
>
>Telefon: +49 89 360908-547
>Telefax: +49 89 360908-8547
>COINS: 7941-6547
>
>Sitz der Gesellschaft: München
>AG München, HRB 143325
>Geschäftsführer: Dr. Yuji Takada, Hans-Dieter Gatzka, Christian Menk
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev