from:"Hochmuth, Roland M"

Re: [openstack-dev] [release][monasca] Release of openstack/monasca-kibana-plugin failed

2017-04-20 Thread Hochmuth, Roland M

Thanks Doug. My understanding of the issue is that we need to

1. Update the version in package.json, 
https://github.com/openstack/monasca-kibana-plugin/blob/master/package.json, 
from "0.0.5" to "1.0.1". 
2. Cherry pick to Ocata.
3. Then apply a new release tag for Ocata for 1.0.1 in, 
https://review.openstack.org/#/c/433823/1/deliverables/ocata/monasca-kibana-plugin.yaml.

Does that sound correct?

Regards --Roland





On 4/20/17, 1:41 PM, "Doug Hellmann"  wrote:

>Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
>> The version of monasca-kibana-plugin in package.json does not match the
>> new tag, and that caused the publish job to fail. I'm available to help
>> debug or to quickly release an update after the problem is fixed.
>
>https://review.openstack.org/458629 should help us avoid this error in
>the future.
>
>> 
>> Doug
>> 
>> --- Begin forwarded message from jenkins ---
>> From: jenkins 
>> To: release-job-failures 
>> Date: Wed, 19 Apr 2017 10:01:01 +
>> Subject: [Release-job-failures] Release of openstack/monasca-kibana-plugin 
>> failed
>> 
>> Build failed.
>> 
>> - monasca-kibana-plugin-nodejs4-npm-publish-tarball 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/
>>  : SUCCESS in 4m 48s
>> - monasca-kibana-plugin-tarball-signing 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-tarball-signing/28e6145/
>>  : SUCCESS in 10s
>> - monasca-kibana-plugin-npm-upload 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-npm-upload/f3dd81a/
>>  : FAILURE in 9s
>> - monasca-kibana-plugin-announce-release 
>> monasca-kibana-plugin-announce-release : 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
__
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

2017-04-20 Thread 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

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

2017-03-27 Thread 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

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

2017-02-13 Thread Hochmuth, Roland M

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

From: An Qi YL Lu <l...@cn.ibm.com<mailto:l...@cn.ibm.com>>
Date: Sunday, February 12, 2017 at 8:29 PM
To: Roland Hochmuth <roland.hochm...@hpe.com<mailto:roland.hochm...@hpe.com>>
Cc: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
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<mailto:roland.hochm...@hpe.com>
Cc: openstack-dev@lists.openstack.org<mailto: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" 
<roland.hochm...@hpe.com<mailto:roland.hochm...@hpe.com>>
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, 
An Qi YL Lu/

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

2017-02-09 Thread 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

2017-02-08 Thread 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] step-by-step installation guide

2016-06-22 Thread 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 
>
Reply-To: OpenStack List 
>
Date: Wednesday, June 22, 2016 at 4:58 AM
To: OpenStack List 
>
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

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

2016-06-21 Thread 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

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

2016-06-02 Thread Hochmuth, Roland M

Hi László, as another alternative you could achieve something similar in 
Monasca, without using the InfluxDB Relay project, by configuring multiple 
Monasca Persisters each in a different consumer group, and with it's own 
independent InfluxDB server instance. Not sure which is the better approach. I 
believe the answer to your question is that multiple instances of a metrics 
database in Monasca is already supported. Regards --Roland

From: László Hegedüs 
>
Organization: Ericsson AB
Reply-To: OpenStack List 
>
Date: Thursday, June 2, 2016 at 12:51 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Monasca] influxDB clustering and HA will be 
"commercial option".

The blog post also states that:

"For our users looking for free open source options, we’ll be releasing the 
open source InfluxDB Relay project along with a landing page how to achieve 
high availability using pure open source and subscription options with the 
0.12.0 releases and beyond. From that point forward our clustering efforts will 
be focused on the closed source Influx Enterprise offering."

https://github.com/influxdata/influxdb-relay/blob/master/README.md

So there is still an option to have it HA.

Of course it would be nice if multiple databases were supported by Monasca.

On 05/31/2016 09:30 AM, Julien Danjou wrote:

On Mon, May 30 2016, Jaesuk Ahn wrote:

It seems like “clustering” and “high availablity” of influxDB will be
available only in commercial version.
Monasca is currently leveraging influxDB as a metrics and alarm database.
Beside vertical, influxDB is currently only an open source option to use.

Indeed, it's a shame than there's nobody developing an opensource TSDB
based on open technologies that is used in OpenStack, which supports
high availability, clustering, and a ton of other features…

Wait… what about OpenStack Gnocchi?

  http://gnocchi.xyz/

:)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] influxDB clustering and HA will be "commercial option".

2016-06-02 Thread Hochmuth, Roland M

My understanding of Prometheus is that it doesn't support HA, fault-tolerant 
clustering either.

The recommendation from the Prometheus developers for HA and 
fault-tolerance/reliability is to run multiple Prometheus servers with one 
server scraping metrics from another server.

To do something similar in Monasca you could run multiple instances of InfluxDB 
using the Kafka metrics topic and multiple consumer groups to replicate all 
metrics to each InfluxDB server, or use the InfluxDB Relay project at, 
https://github.com/influxdata/influxdb-relay.

The non-clustered version of InfluxDB remains free and open-source. It is only 
the clustered version of InfluxDB that has now moved to a closed source license.

From: Martinx - ジェームズ 
>
Reply-To: OpenStack List 
>
Date: Monday, May 30, 2016 at 7:20 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Monasca] influxDB clustering and HA will be 
"commercial option".

On 30 May 2016 at 11:59, Jaesuk Ahn 
> wrote:
Hi, Monasca developers and users,

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
"For our current and future customers, we’ll be offering clustering and high 
availability through Influx Cloud, our managed hosting offering, and Influx 
Enterprise, our on-premise offering, in the coming months.”

It seems like “clustering” and “high availablity” of influxDB will be available 
only in commercial version.
Monasca is currently leveraging influxDB as a metrics and alarm database. 
Beside vertical, influxDB is currently only an open source option to use.

With this update stating “influxDB open source sw version will not have 
clustering / ha feature”,
I would like to know if there has been any discussion among monasca community 
to add more database backend rather than influxDB, especially OpenTSDB.

Thank you.

--
Jaesuk Ahn, Ph.D.
Software Defined Infra Tech. Lab.
SKT

What about Prometheus?

https://prometheus.io/

https://prometheus.io/docs/introduction/comparison/

Cheers!
Thiago
__
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] influxDB clustering and HA will be "commercial option".

2016-06-02 Thread Hochmuth, Roland M

Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at, 
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/.
 Up until that announcement, InfluxDB was planning on supporting all their 
clustering and HA capabilities in the open-source version, which is one of the 
reasons we had added it to Monasca.

There has been some discussion on supporting other databases in Monasca. Due to 
performance and reliability concerns with InfluxDB, we had started looking at 
Cassandra as an alternative. There are several reviews to look at if you are 
interested at, https://review.openstack.org/#/q/monasca+cassandra. Shinya 
Kawabata has been looking into Cassandra most recently.

I looked at OpenTSDB several years ago. There are several concerns with 
OpenTSDB, but the more significant one for us has been around deployment, as it 
requires HBase which is built on HDFS. If you already have Hadoop, HDFS and 
Hbase deployed then OpenTSDB is an incremental addition, but if you don't, it 
is a significant investment. At the time that I had evaluated OpenTSDB 
performance was not on-par with the other alternatives I considered.

Regards --Roland

From: Jaesuk Ahn >
Reply-To: OpenStack List 
>
Date: Monday, May 30, 2016 at 9:59 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Monasca] influxDB clustering and HA will be 
"commercial option".

Hi, Monasca developers and users,

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
"For our current and future customers, we’ll be offering clustering and high 
availability through Influx Cloud, our managed hosting offering, and Influx 
Enterprise, our on-premise offering, in the coming months.”


It seems like “clustering” and “high availablity” of influxDB will be available 
only in commercial version.
Monasca is currently leveraging influxDB as a metrics and alarm database. 
Beside vertical, influxDB is currently only an open source option to use.

With this update stating “influxDB open source sw version will not have 
clustering / ha feature”,
I would like to know if there has been any discussion among monasca community 
to add more database backend rather than influxDB, especially OpenTSDB.


Thank you.





--
Jaesuk Ahn, Ph.D.
Software Defined Infra Tech. Lab.
SKT
__
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][release] missing build artifacts

2016-04-05 Thread Hochmuth, Roland M

Thanks for the pointer Clark. We will look into using that, although we were 
running out of time on the Mitaka release to get something like that 
implemented.

Craig Bryant is in the process of manually updating the versions in the pom 
files to match the Mitaka tags. A couple of reviews are available at

monasca-common: https://review.openstack.org/#/c/301925/
monasca-api: https://review.openstack.org/#/c/301925


Assuming that is an acceptable method, we can also update 

monasca-thresh
monasca-persister

using the same approach. 

Note, I thought he was going to try and pull the tag from git, but maybe that 
didn't turn out OK.

Assuming those work, then at least we would have jars available that match the 
tags for the Mitaka release.








On 4/5/16, 1:10 PM, "Clark Boylan" <cboy...@sapwetik.org> wrote:

>On Tue, Apr 5, 2016, at 11:56 AM, Hochmuth, Roland M wrote:
>> Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that
>> I've caused.
>> 
>> It sounds like all Python projects/deliverables are in reasonable shape,
>> but if not, please let me know. 
>> 
>> Not sure what we should do about the jars at this point. We had started
>> to discuss a plan to manually copy the jars over to the proper location.
>> I was hoping we could just do this temporarily for Mitaka. Unfortunately,
>> there are a few steps that need to be resolved prior to doing that.
>> 
>> Currently, the java builds overwrite the previous build. The version
>> number of the jar that is built, matches the version in the pom file.
>> See, http://tarballs.openstack.org/ci/monasca-thresh/, for an example.
>> 
>> What we are looking into is modifying the pom files for the java repos,
>> so that the version number of the jar matches the tag when built (not
>> what is in the pom), and modifying the name of the jar, by removing the
>> word SNAPSHOT.
>> 
>> If we do that, we think we can get a name for the jar with a version that
>> matches the latest tag on whatever branch is being used. This should be
>> similar to how the Python wheels that are named.
>> 
>> We could manually copy in the short-term. But the goal is to add an
>> automatic copy to the appropriate location in,
>> http://tarballs.openstack.org/.
>> 
>> Unfortunately, for the java related deliverables, it sounds like we are a
>> little late for all this to get done prior to Mitaka. Not sure if this
>> can be added post Mitaka.
>
>The infra team has to publish jars as well and has a set of jobs for
>that at [0]. It should figure out your versions from git as well and set
>them all automagically with the correct maven configuration. You might
>be able to just add these jobs assuming you use maven.
>
>[0]
>https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/maven-plugin-jobs.yaml
>
>Clark
>
>__
>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][release] missing build artifacts

2016-04-05 Thread Hochmuth, Roland M

Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that I've 
caused.

It sounds like all Python projects/deliverables are in reasonable shape, but if 
not, please let me know. 

Not sure what we should do about the jars at this point. We had started to 
discuss a plan to manually copy the jars over to the proper location. I was 
hoping we could just do this temporarily for Mitaka. Unfortunately, there are a 
few steps that need to be resolved prior to doing that.

Currently, the java builds overwrite the previous build. The version number of 
the jar that is built, matches the version in the pom file. See, 
http://tarballs.openstack.org/ci/monasca-thresh/, for an example.

What we are looking into is modifying the pom files for the java repos, so that 
the version number of the jar matches the tag when built (not what is in the 
pom), and modifying the name of the jar, by removing the word SNAPSHOT.

If we do that, we think we can get a name for the jar with a version that 
matches the latest tag on whatever branch is being used. This should be similar 
to how the Python wheels that are named.

We could manually copy in the short-term. But the goal is to add an automatic 
copy to the appropriate location in, http://tarballs.openstack.org/.

Unfortunately, for the java related deliverables, it sounds like we are a 
little late for all this to get done prior to Mitaka. Not sure if this can be 
added post Mitaka.

Regards --Roland

On 4/5/16, 3:15 AM, "Thierry Carrez"  wrote:

>Davanum Srinivas wrote:
>> Please see below:
>>
>> On Sat, Apr 2, 2016 at 8:41 AM, Doug Hellmann  wrote:
>>> Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +:
 Hi Doug, You had mentioned issues with three repos:

 1. monasca-ceilometer
 2. monasca-log-api
 3. monasca-thresh

 All the repos that have Python code I believe are in reasonable shape with 
 respect to the Python deliverables except for the following two repos:

 1. monasca-ceilometer
 2. monasca-log-api

 I'm not sure we should attempt to resolve these two repos for the Mitaka 
 release, but we can try. It might be too late. They aren't in heavy usage 
 and are relatively new.
>>>
>>> I think for those you were missing the "venv" environment in tox.ini
>>> that the jobs use to run arbitrary commands. Have a look at some of the
>>> other repos for an example of how to set that up, or ask the infra team
>>> (I'm not sure where it's documented, unfortunately, or I would direct
>>> you there).
>>
>> The monasca-log-api venv problem has been fixed in:
>> https://review.openstack.org/#/c/299936/
>
>Thanks dims!
>
>Roland: Now we'll need a 0.0.3 tag request on stable/mitaka to trigger a 
>tarball rebuild.
>
>If done quickly, that should let us keep Monasca deliverables in Mitaka.
>
>-- 
>Thierry Carrez (ttx)
>
>__
>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][release] missing build artifacts

2016-04-01 Thread Hochmuth, Roland M

Hi Doug, You had mentioned issues with three repos:

1. monasca-ceilometer
2. monasca-log-api
3. monasca-thresh

All the repos that have Python code I believe are in reasonable shape with 
respect to the Python deliverables except for the following two repos:

1. monasca-ceilometer
2. monasca-log-api

I'm not sure we should attempt to resolve these two repos for the Mitaka 
release, but we can try. It might be too late. They aren't in heavy usage and 
are relatively new.

monasca-thresh is a pure Java component.

In the process of looking at monasca-thresh it looks like there is a general 
issue with all the Java deliverables. All the Java jars are built and uploaded 
in their respective folders such as, 
http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we 
don't move the jars that are in this directory up a level to 
http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to get 
resolved.

A proposal that I think would resolve this is as follows:

1. Update versions of Java jars in the pom.xml for each project to something 
like 2.0 on the stable/mitaka branch. This will result in a new jar file being 
created with a nice version and name. Note, this step isn't necessary, but if 
we did this we would have a nice version for Mitaka.
2. Figure out how to copy the jars over to their respective folders in 
http://tarballs.openstak.org. For Python I think the script that does this is 
publish-to-pypi, but for Java code, not sure exactly what needs to be done.

I think the two steps above would get us in compliance again for monasca-thresh 
and all the Java code in the other repos.

Does that seem like a reasonable plan at this point?

Regards --Roland

On 4/1/16, 2:36 PM, "Doug Hellmann"  wrote:

>Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
>> Hi Doug, Sorry, this is our first release and we want to do the right thing.
>> 
>> monasca-ceilometer is the code that plugs into the Ceilometer publisher and 
>> Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca 
>> API and use Monasca as a storage backend. We don't create a pypi for this 
>> component.
>
>How do you users receive that code and install it? We at least need
>a tarball built. If you don't want to publish to pypi, you can use
>the job definitions that the Python server projects use to build
>artifacts.
>
>> monasca-log-api is probably not set up completely, but it should be similar 
>> to the monasca-api.
>> 
>> monasca-thresh remains purely Java code. There is a build, but it isn't a 
>> Python build so there isn't a tox.ini. Not sure how to deliver this, but the 
>> current java build overwrites the jar each time it builds so it sounds like 
>> that would need to be fixed.
>
>Are those JAR files going somewhere we could link to?
>
>> 
>> I guess, judging by the issues, I don't quite understand what "deliverables" 
>> are. I was thinking it was the tagged code, but obviously it includes the 
>> build too. It sounds like we have more work ahead of us.
>
>Most of our distributors want a tarball or sdist or other artifact they
>can use to build a package from. For the Python-based apps, we have
>templates you can use in the zuul/layout.yaml file to introduce those
>jobs into the right zuul queues. The release or infra teams can help you
>identify the right template to use.
>
>> Let me know how you want to proceed.
>
>We only want to be linking to things we're actually publishing. The
>first patch I mentioned removes the links so the Monasca projects
>that don't have builds. The second patch removes the projects
>entirely, but if we can update the page to link to a downloadable
>artifact (rather than just a git repo tag) then we can keep the
>projects in the list. We can get downloadable artifacts by having
>you add build jobs and then having the release team tag again as a
>new release candidate, or if there are already artifacts somewhere
>(like the JAR file) we can set up the releases repo to link there.
>
>Doug
>
>> 
>> Regards --Roland
>> 
>> On 4/1/16, 1:21 PM, "Doug Hellmann"  wrote:
>> 
>> >Monasca team,
>> >
>> >We noticed in our audit of the links on
>> >http://releases.openstack.org/mitaka/index.html that the links to
>> >the build artifacts for monasca-ceilometer, monasca-log-api, and
>> >monasca-thresh point to missing files. These repositories either
>> >don't seem to have any real build jobs configured in
>> >openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
>> >set up correctly (or both), so it's not clear how tagging is producing
>> >a release for you.
>> >
>> >For now, we are disabling links to the artifacts for those repos
>> >via https://review.openstack.org/300457 but we're also planning to
>> >remove them from the official Mitaka page since there don't
>> >appear to be any actual related deliverables
>> >(https://review.openstack.org/300619).
>> >
>> >It would be good to

Re: [openstack-dev] [Ceilosca][Neutron][Monasca]

2016-04-01 Thread Hochmuth, Roland M

Hi Rubab, I'm not that knowledge on networking/neutron, and still in learn 
mode, but it sounds like it would be useful. This is an area that I am starting 
to get more involved with. There is a potential design summit session that 
Armando and I are looking into hosting on monitoring Neutron.

Ceilosca was just a name that we created as a combination of Ceilometer and 
Monasca. There isn't an official Ceilosca project/repo. However, there is a 
repo called monasca-ceilometer at, 
https://github.com/openstack/monasca-ceilometer, which contains a Ceilometer 
publisher, that translates/sends samples to the Monasca API. The repo also 
contains a storage driver that allows you to use Monasca as a backend for 
Ceilometer. This code is quite stable, has undergone an extensive amount of 
testing and is ready for deployment.

Regards --Roland

From: Rubab Syed >
Reply-To: OpenStack List 
>
Date: Tuesday, March 1, 2016 at 9:25 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Ceilosca][Neutron][Monasca]

Hi all,

I'm planning to write a plugin for Monasca that would enable router's traffic 
monitoring per subnet per tenant. For that purpose, I'm using Neutron l3 
metering extension [1] that allows you to filter traffic based on CIDRs.

My concerns:

- Now given the fact that this extension can be used to create labels and rules 
for particular set of IPs and ceilometer can be used to meter the bandwidth 
based on this data and monasca publisher for ceilometer is also available, 
would that plugin be useful somehow? Where are we at ceilosca right now?

- Even though ceilometer allows to meter bandwidth at l3 level, we still have 
to create explicit labels and rules for all subnets attached to a router. In a 
production environment where there could be multiple routers belonging to 
multiple tenants, isn't it a bit of a work? I was wondering if I could automate 
the label and rule creation process. My script would automatically detect 
subnets and create rules per interface of router. It would help in ceilosca as 
well and can be used by the router plugin (given plugin is not redundant work). 
Comments?


[1] https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth


Thanks,
Rubab
__
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][release] missing build artifacts

2016-04-01 Thread Hochmuth, Roland M

Hi Doug, Sorry, this is our first release and we want to do the right thing.

monasca-ceilometer is the code that plugs into the Ceilometer publisher and 
Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca 
API and use Monasca as a storage backend. We don't create a pypi for this 
component.

monasca-log-api is probably not set up completely, but it should be similar to 
the monasca-api.

monasca-thresh remains purely Java code. There is a build, but it isn't a 
Python build so there isn't a tox.ini. Not sure how to deliver this, but the 
current java build overwrites the jar each time it builds so it sounds like 
that would need to be fixed.

I guess, judging by the issues, I don't quite understand what "deliverables" 
are. I was thinking it was the tagged code, but obviously it includes the build 
too. It sounds like we have more work ahead of us.

Let me know how you want to proceed.

Regards --Roland

On 4/1/16, 1:21 PM, "Doug Hellmann"  wrote:

>Monasca team,
>
>We noticed in our audit of the links on
>http://releases.openstack.org/mitaka/index.html that the links to
>the build artifacts for monasca-ceilometer, monasca-log-api, and
>monasca-thresh point to missing files. These repositories either
>don't seem to have any real build jobs configured in
>openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
>set up correctly (or both), so it's not clear how tagging is producing
>a release for you.
>
>For now, we are disabling links to the artifacts for those repos
>via https://review.openstack.org/300457 but we're also planning to
>remove them from the official Mitaka page since there don't
>appear to be any actual related deliverables
>(https://review.openstack.org/300619).
>
>It would be good to understand what your intent is for builds. Can
>you follow up here on this thread with some details?
>
>Thanks,
>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 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] Alarm generation from a sequence of events

2016-02-16 Thread Hochmuth, Roland M

Hi Pradip, The focus of that blueprint is to create metrics from logs in the 
LogStash component and then publish them to the Kafka metrics topic. The 
Monasca Threshold Engine can then be used to alarm on the metrics. For example, 
if the number of errors in a log file exceeds some amount, alarm and send a 
notification.

Regards --Roland

From: Pradip Mukhopadhyay 
>
Reply-To: OpenStack List 
>
Date: Monday, February 15, 2016 at 9:58 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Monasca] Alarm generation from a sequence of events

Hello,


We come across the following interesting BP in the last weekly meeting: 
https://blueprints.launchpad.net/monasca/+spec/alarmsonlogs


Understood how the non-periodic nature of log events to be taken care of (by 
introducing period = -1 in value-meta).


Just wondering can it be possible to use this to satisfy the following usecase:
Given a causal or non-causal sequence of events a, b, c – can we determine that 
a condition ‘p’ has occurred and alarm on that.



Thanks,
Pradip



__
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] Anomaly & Prediction Engine

2016-01-22 Thread Hochmuth, Roland M

Hi Pradip, There are several components in Monasca. I'm not sure what the 
acronym APE is stands for. Is that Anomaly and Prediction Engine? The list of 
components in Monasca and the languages that they are implemented in is as 
follows:

  1.  API: Both Java and Python.
  2.  Persister: Both Java and Python
  3.  Threshold Engine: Java only
  4.  Notification Engine: Python
  5.  python-monascaclient: Python

Over the past few months we developed around 120 Tempest tests that test the 
entire API, developed a plugin for Tempest and integrated in the OpenStack CI 
systems. The Tempest tests run to 100% completion against both APIs and 
Persisters.

There was a Python implementation of an anomaly engine developed that was more 
of a proof-of-concept. It is at, 
https://github.com/roland-hochmuth/monasca-anomaly.

Regards --Roland

From: Pradip Mukhopadhyay 
>
Reply-To: OpenStack List 
>
Date: Friday, January 22, 2016 at 5:18 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [monasca] Anomaly & Prediction Engine

(Apology for ignorance) - can anyone from Monasca please point any related 
documentation about the APE micro-service which (whatever be the state 
currently it is) currently we have in Monasca? Its in python or in Java?

--pradip

On Fri, Jan 22, 2016 at 4:12 PM, Osanai, Hisashi 
> wrote:

Monasca folks,

We discussed about Anomaly & Prediction Engine in this week's
irc meeting and decided we would exchange info using this list.
I'm really interested in having this functionality but the status
is prototype now.

We know that there are a lot of related tech around it and the tech
has been growing rapidly.

Let's start to discuss about how to approach this. What do you think?

Best Regards,
Hisashi Osanai

__
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] alarms based on events

2016-01-22 Thread Hochmuth, Roland M

Hi Prema, I assumed that the component that is translating and sending to the 
Monasca API would be sending metrics periodically. If that isn't the case, then 
support for non-periodic metrics would need to be added.

Sorry, I should heave realized this in my previous response.

I don't think it would be difficult to add support for non-periodic 
metrics/alarms. There are a couple of approaches we could take, so a design 
discussion would be good to have if you are interested in implementing this. 
This is feature that we are not working on right now, but it is on our list to 
implement in the near future.

Regards --Roland

From: Premysl Kouril <premysl.kou...@gmail.com<mailto:premysl.kou...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, January 22, 2016 at 7:06 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Monasca] alarms based on events

Hi Roland,

I had a chat with people on IRC about it and I understood that in order for my 
use case to work the Monasca software needs to implement "non-periodic" metrics 
(because the monitored box sends out the event only on health change and not 
periodicaly) and I understood that this enhancement is currently being designed.

Is that correct?

Cheers,
Prema

On 22 Jan 2016 01:04, "Hochmuth, Roland M" 
<roland.hochm...@hpe.com<mailto:roland.hochm...@hpe.com>> wrote:
Hi Prema, SNMP isn't handled in Monasca and I have little experience in
that area. This would be new development.

It is possible to map binary data, such as health/status of a system or
component. The usual way is to use the value 0 for up/OK and 1 for
down/NOT_OK. A component would need to be developed to handle SNMP traps,
then translate and send them to the Monasca API as binary data. Possibly,
this component could be added to the Agent.

Using the Monasca Alarm API, an alarm could be defined, such as
max(snmp{}) > 0.

The latency for a min/max alarm expression in Monasca is very low.

Regards --Roland

On 1/18/16, 9:07 AM, "Premysl Kouril" 
<premysl.kou...@gmail.com<mailto:premysl.kou...@gmail.com>> wrote:

>Hello,
>
>we are just evaluating Monasca for our new cloud infrastructure and I
>would like to ask if there are any possibilities in current Monasca or
>some development plans to address following use case:
>
>We have a box which we need to monitor and when something goes wrong
>with the box, it sends out and SNMP trap indicating that it is in bad
>condition and when the box is fixed it sends out SNMP trap indicating
>that it is OK and operational again (in other words: the box is
>indicating health state transitions by sending events - in this case
>SNMP traps).
>
>Is it possible in Monasca to define such alarm which would work on top
>of such events? In other words - Is it possible to have a Monasca
>alarm which would go red on some external event go back green on some
>other external event? By alarm I really mean a stateful entity in
>monasca database not some notification to administrator.
>
>Best regards.
>Prema
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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] collectd-Monasca Python plugin

2016-01-22 Thread Hochmuth, Roland M

Thanks Alonso. 

On 1/22/16, 2:56 AM, "Alonso Hernandez, Rodolfo"
<rodolfo.alonso.hernan...@intel.com> wrote:

>Hello Roland:
>
>>> How would you map the metric names and fields in collectd to a monasa
>>>name and dimensions?
>I'm on it. I'm reading the API from collectd and monasca, to figure out
>how to connect them. Next week I'll upload a spec and I'll wait for your
>comments.
>
>Thank you for your interest!
>
>Regards.
>
>
>-Original Message-
>From: Hochmuth, Roland M [mailto:roland.hochm...@hpe.com]
>Sent: Thursday, January 21, 2016 11:53 PM
>To: OpenStack Development Mailing List (not for usage questions)
><openstack-dev@lists.openstack.org>
>Subject: Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin
>
>Hi Rodolfo, I think this would be useful work. Collectd has a lot of
>metrics that aren't supported in Monasca yet.
>
>How would you map the metric names and fields in collectd to a monasa
>name and dimensions?
>
>Regards --Roland
>
>From: Jaesuk Ahn <bluejay@gmail.com<mailto:bluejay@gmail.com>>
>Reply-To: OpenStack List
><openstack-dev@lists.openstack.org<mailto:openstack-...@lists.openstack.or
>g>>
>Date: Thursday, January 21, 2016 at 4:49 AM
>To: OpenStack List
><openstack-dev@lists.openstack.org<mailto:openstack-...@lists.openstack.or
>g>>
>Subject: Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin
>
>We are looking into similar plan to have collectd-plugin for Monasca.
>
>There are some env. we cannot deploy monasca agent, but want to put data
>into Monasca. In addition, we wanted to use easily accepted collectd for
>gathering data from legacy env.
>
>It will be interesting to see more detail about your plan.
>
>Cheers,
>
>
>---
>Jaesuk Ahn
>SDI Tech. Lab, SKT
>
>
>2016년 1월 21일 (목) 19:11, Alonso Hernandez, Rodolfo
><rodolfo.alonso.hernan...@intel.com<mailto:rodolfo.alonso.hernandez@intel.
>com>>님이 작성:
>Hello:
>
>We are doing (or at least planning) a collectd-Monasca Python plugin.
>This plugin will receive the data from RPC calls form collectd and will
>write this data in Monasca, using statsd API.
>
>My question is: do you think this development could be useful? Does it
>worth? Any comment?
>
>Thank you in advance. Regards.
>
>Rodolfo Alonso.
>--
>Intel Research and Development Ireland Limited Registered in Ireland
>Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>Registered Number: 308263
>
>
>This e-mail and any attachments may contain confidential material for the
>sole use of the intended recipient(s). Any review or distribution by
>others is strictly prohibited. If you are not the intended recipient,
>please contact the sender and delete all copies.
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://OpenS
>tack-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
>--
>Intel Research and Development Ireland Limited
>Registered in Ireland
>Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>Registered Number: 308263
>
>
>This e-mail and any attachments may contain confidential material for the
>sole
>use of the intended recipient(s). Any review or distribution by others is
>strictly prohibited. If you are not the intended recipient, please
>contact the
>sender and delete all copies.
>__
>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] collectd-Monasca Python plugin

2016-01-21 Thread Hochmuth, Roland M

Hi Rodolfo, I think this would be useful work. Collectd has a lot of metrics 
that aren't supported in Monasca yet.

How would you map the metric names and fields in collectd to a monasa name and 
dimensions?

Regards --Roland

From: Jaesuk Ahn >
Reply-To: OpenStack List 
>
Date: Thursday, January 21, 2016 at 4:49 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Monasca] collectd-Monasca Python plugin

We are looking into similar plan to have collectd-plugin for Monasca.

There are some env. we cannot deploy monasca agent, but want to put data into 
Monasca. In addition, we wanted to use easily accepted collectd for gathering 
data from legacy env.

It will be interesting to see more detail about your plan.

Cheers,


---
Jaesuk Ahn
SDI Tech. Lab, SKT


2016년 1월 21일 (목) 19:11, Alonso Hernandez, Rodolfo 
>님이
 작성:
Hello:

We are doing (or at least planning) a collectd-Monasca Python plugin. This 
plugin will receive the data from RPC calls form collectd and will write this 
data in Monasca, using statsd API.

My question is: do you think this development could be useful? Does it worth? 
Any comment?

Thank you in advance. Regards.

Rodolfo Alonso.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


__
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] alarms based on events

2016-01-21 Thread Hochmuth, Roland M

Hi Prema, SNMP isn't handled in Monasca and I have little experience in
that area. This would be new development.

It is possible to map binary data, such as health/status of a system or
component. The usual way is to use the value 0 for up/OK and 1 for
down/NOT_OK. A component would need to be developed to handle SNMP traps,
then translate and send them to the Monasca API as binary data. Possibly,
this component could be added to the Agent.

Using the Monasca Alarm API, an alarm could be defined, such as
max(snmp{}) > 0.

The latency for a min/max alarm expression in Monasca is very low.

Regards --Roland

On 1/18/16, 9:07 AM, "Premysl Kouril"  wrote:

>Hello,
>
>we are just evaluating Monasca for our new cloud infrastructure and I
>would like to ask if there are any possibilities in current Monasca or
>some development plans to address following use case:
>
>We have a box which we need to monitor and when something goes wrong
>with the box, it sends out and SNMP trap indicating that it is in bad
>condition and when the box is fixed it sends out SNMP trap indicating
>that it is OK and operational again (in other words: the box is
>indicating health state transitions by sending events - in this case
>SNMP traps).
>
>Is it possible in Monasca to define such alarm which would work on top
>of such events? In other words - Is it possible to have a Monasca
>alarm which would go red on some external event go back green on some
>other external event? By alarm I really mean a stateful entity in
>monasca database not some notification to administrator.
>
>Best regards.
>Prema
>
>__
>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] Monasca mid-cycle meetup

2016-01-20 Thread Hochmuth, Roland M

Hi Everyone, The Monasca Mitaka Mid-cycle Meetup will be hosted via WebEx using 
the contact information below on Wednesday February 3rd and Thursday February 
4th, 2016.

The Etherpad with additional information is at, 
https://etherpad.openstack.org/p/monasca_mitaka_midcycle.

The meeting is open to anyone and the contact information is below.

Regards --Roland

Day 1, Wednesday February 3rd, 2016
Time: 1500-2100 UTC

https://cisco.webex.com/ciscosales/j.php?MTID=ma4770b115a04f1476fdf4073c404c60a
Meeting number: 204 442 828
Meeting password: dM3gVJxR

If you are the host, you can use the meeting host key to pass the host 
privilege to another participant or to start the meeting from a video 
conferencing system or application. To find the host key for this meeting, go 
here.

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: 200 279 394
Numeric meeting password: 04704543
Global call-in numbers | Toll-free calling restrictions

Day 2, Wednesday February 4th, 2016
Time: 1500-2100 UTC

https://cisco.webex.com/ciscosales/j.php?MTID=m16a6dddb7c2b5f50fb2dff2b2a9d10a5
Meeting number: 200 279 394
Meeting password: jYxEJ3Gb

If you are the host, you can use the meeting host key to pass the host 
privilege to another participant or to start the meeting from a video 
conferencing system or application. To find the host key for this meeting, go 
here.

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: 200 279 394
Numeric meeting password: 04704543
Global call-in numbers | Toll-free calling restrictions

__
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][vitrage] Vitrage project

2015-11-18 Thread Hochmuth, Roland M

Hi Ifat, Thanks for the heads-up. We will start reviewing your blueprints
and providing feedback.

With respect to the support for AODH, I'm assuming that you are referring
too, 
https://review.openstack.org/#/c/244049/2/specs/mitaka/manage-ceilometer-al
arms.rst. For adding support for Monasca, a Vitrage Notifier would be
developed for Monasca.

In the diagram at, https://wiki.openstack.org/wiki/Vitrage, it shows the
Synchronizer collecting data, such as OpenStack notifications, which
usually implies RabbitMQ. With the Ceilosca effort,
https://www.openstack.org/summit/tokyo-2015/videos/presentation/ceilometer-
monascaceilosca and https://github.com/openstack/monasca-ceilometer, we
are planning on sending OpenStack Notifications from Ceilometer to
Monasca. Monasca will then publish to the Kafka queue. Would you be
interested in consuming events from Kafka by the Synchronizer to reduce
the load on RabbitMQ?

In the use cases you discuss getting health/status information about a
switch and correlating problems to VMs. But, in the diagram only SDN
Controller, Heat, Cinder and Nova are shown. Are you planning on receiving
health/status information from other sources? Monasca is processing
metrics for many components, such as the physical infrastructure used for
running the cloud and for OpenStack resources, and generating alarms. For
example, in your use case, Monasca could be monitoring the physical switch
and creating alarms. Should alarms that Monasca creates be a source for
the Vitrage Synchronizer?

Regards --Roland

On 11/17/15, 3:02 AM, "AFEK, Ifat (Ifat)" 
wrote:

>Hi Monasca developers,
>
>As you might have heard in Mitaka Summit, we have started a new project
>named Vitrage[1]. We would like it to be the Openstack RCA (Root Cause
>Analysis) Engine for organizing, analyzing and expanding OpenStack alarms
>& events, yielding insights regarding the root cause of problems and
>deducing the existence of problems before they are directly detected.
>
>We are now in the process of reviewing the blueprints[2] that we wish to
>implement in mitaka. At the first stage of the implementation we plan to
>integrate with AODH alarms. In the next phase, we would like to check how
>we can integrate with Monasca as well. We would be happy to get your
>reviews for our blueprints, to make sure our architecture matches this
>future integration.
>
>Your feedback would be highly appreciated.
>
>[1] https://wiki.openstack.org/wiki/Vitrage
>[2] https://blueprints.launchpad.net/vitrage
>
>Thanks,
>Ifat Afek.
>
>
>
>__
>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] Monasca weekly meetings in IRC, datetime proposal

2015-08-31 Thread Hochmuth, Roland M

This is just a reminder that the Monasca weekly meeting will be moving to
a new day and use of IRC this week.

See, http://eavesdrop.openstack.org/#Monasca_Team_Meeting for more details

Day: Weekly on Wednesday
Time: 1500 UTC
IRC: openstack-meeting-3
Agenda: https://etherpad.openstack.org/p/monasca-team-meeting-agenda

Please add agenda items to discuss.

Regards --Roland



On 8/25/15, 5:53 PM, "Hochmuth, Roland M" <roland.hochm...@hp.com> wrote:

>We have been asked to host the Monasca weekly meetings in IRC.
>
>The proposal is to run the weekly meeting on Wednesday at 1500 UTC in IRC
>channel openstack-meeting-3. A review has been submitted at,
>https://review.openstack.org/#/c/216904/1/meetings/monasca-team-meeting.ya
>ml. Please +1 if you are OK with the proposed time slot. If not, please
>-1 and propose a new time slot.
>
>OpenStack meetings are hosted in specific IRC channels and archived.
>
>Unfortunately, there wasn't an existing channel available to continue to
>host the meeting on Tuesday's. Hopefully, Wednesday will continue to work
>for everyone.
>
>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 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 weekly meetings in IRC, datetime proposal

2015-08-25 Thread Hochmuth, Roland M

We have been asked to host the Monasca weekly meetings in IRC.

The proposal is to run the weekly meeting on Wednesday at 1500 UTC in IRC 
channel openstack-meeting-3. A review has been submitted at, 
https://review.openstack.org/#/c/216904/1/meetings/monasca-team-meeting.yaml. 
Please +1 if you are OK with the proposed time slot. If not, please -1 and 
propose a new time slot.

OpenStack meetings are hosted in specific IRC channels and archived.

Unfortunately, there wasn't an existing channel available to continue to host 
the meeting on Tuesday's. Hopefully, Wednesday will continue to work for 
everyone.

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] Minutes for Monasca 8-18-2015

2015-08-18 Thread Hochmuth, Roland M

Minutes for the Monasca Weekly Meeting 8-18-2015.

https://etherpad.openstack.org/p/Monasca_Weekly_Meeting_8-18-2015

__
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] Minutes for Monasca mid-cycle meetup

2015-08-16 Thread Hochmuth, Roland M

Hi Ildikó, That will be great if you can attend. If you do, would it be
possible for you to present an overview and current status/plans of the
Ceilometer work around the componentization? I was at the discussion in
Vancouver on this, and several others from Monasca were there too, but I
haven't stayed connected.

The information for the Monasca Meetings as well as minutes is at,
https://wiki.openstack.org/wiki/Meetings/Monasca. If you have any problems
connecting in, please let me know. We recently switched to WebEx, which is
hosted by Cisco. Everything should work, but if there are any problems we
can switch to IRC.

If Tuesday's at 4:00 PM UTC are problematic, then we would consider
setting up a separate time to cover this topic or move the Monasca meeting
the following week.

Regards --Roland



On 8/14/15, 6:57 AM, Ildikó Váncsa ildiko.van...@ericsson.com wrote:

Hi,

I will try to join if I can, I have an overlapping meeting on Tuesdays.

In general I think it would be really good to start a closer
collaboration, the componentization work in Ceilometer gives a really
good opportunity as Chris described.

Best Regards,
Ildikó

 -Original Message-
 From: Chris Dent [mailto:chd...@redhat.com]
 Sent: August 12, 2015 15:45
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle
meetup
 
 On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
 
  It sounds like we should connect up soon. I could attend a Ceilometer
  meeting, or you could attend the Monasca meeting which is held Tuesday
  mornings at 9:00 MST.
 
 I'm away this coming Tuesday, but perhaps some of the other Ceilo
people could show up? I've got it on my schedule to come the
 week after.
 
 I suspect there's a lot we can do over the long run to avoid
duplicating code and effort but that there will be some humps to ride
over
 to different pieces (and people!) talking to one another.
 Should be fun. Looking forward to it.
 
 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent
 
 
_
_
 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] Minutes for Monasca mid-cycle meetup

2015-08-11 Thread Hochmuth, Roland M

Hi Chris,

Thanks for reaching out. I would be interested in joint sessions on
Monasca and Ceilometer at the Tokyo Summit. We had a joint
Ceilometer/Monasca session at the Paris Design Summit and had identified
several areas to work on together. It has been a while since we've sync'd
up though. We should probably get together prior to the Tokyo Summit to
plan further.

The work that you are doing to split-out components is very interesting to
the Monasca project. We were really interested in the direction that this
was headed. As you mention, the Ceilometer data collection pipeline is
extremely interesting to Monasca. The work that we've been doing around
what we refer to as Ceilosca, is where we see immediate utilization. I
think you were at the session in Vancouver where some folks mentioned the
possibility of using the Ceilometer data collection pipeline to send to
Monasca, and that aligns with our thoughts too.

Although the Monasca Agent supports collecting a lot of different metrics,
the one area that it needs additional capabilities is collecting metrics
and events for OpenStack resources. The Monasca Agent supports collecting
metrics for instances/Vms, but we would like to add support for the rest
of the OpenStack resources and don't want to re-create this in our Agent.
Currently, we've been addressing this problem via a Ceilometer to Monasca
publisher in the repo at, https://github.com/stackforge/monasca-ceilometer.

The alarm system, called Aodh, is also potentially interesting. Monasca
also has a alarm/threshold engine that is an in-memory streaming alarm
engine based on Apache Storm. Everything in Monasca has been ported to
Python, except for the Monasca Threshold Engine. As Aodh is written in
Python already, maybe it could be a drop in Python replacement for our
existing Threshold Engine as we would like to get the remaining component
moved over to Python.

It sounds like we should connect up soon. I could attend a Ceilometer
meeting, or you could attend the Monasca meeting which is held Tuesday
mornings at 9:00 MST.

Regards --Roland


On 8/11/15, 1:53 AM, Chris Dent chd...@redhat.com wrote:

On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:

 The minutes for the meetup are at,
 https://etherpad.openstack.org/p/monasca_liberty_mid_cycle. If anyone
 would like to discuss further or would like further clarification please
 let me know.

Thanks for posting that and the linked etherpads.

One thing I noticed was a section on summit activities about joint
sessions with other projects. I'd like to encourage Monasca folk and
Ceilometer folk to have at least one joint session.

Many people within the Ceilometer project are working hard to decompose
its various bits of functionality to make it more usable in diverse
toolchains. Making sure that the extracted alarm system (now called
Aodh) and the forthcoming extracted polling system will be useful to
Monasca is a priority.

Some parts of Ceilometer (the data gathering aspects perhaps?)
presumably have greater potential use to Monasca than others (the
legacy mongodb and SQL-based datastores). Working together to
ensure interoperability of the important parts would be good.

I think present-day Ceilometer and Monasca are working on the same goal:
Making an alternative to the old Ceilometer. It seems likely there is
some productive collaboration that can happen?

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] Minutes for Monasca mid-cycle meetup

2015-08-10 Thread Hochmuth, Roland M

Thanks to all that attended the Monasca Mid-cycle Meetup last week. The
meet-up was well attended and we had good overviews, content and
discussions.

The minutes for the meetup are at,
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle. If anyone
would like to discuss further or would like further clarification please
let me know.

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 mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Chandeep, There are no fees. It would be great if you could join us. Also, 
please feel free to add to the agenda topics that you would like to cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I could just 
come in .

Thanks
CHandeep

__
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 mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Simon, Sorry, we don't have any information on our Wiki. Ceilosca leverages 
the Ceilometer data collection pipeline via a Ceilometer-Monasca Publisher and 
the Ceilometer API via a Ceilometer-Monasca Storage Driver and is completely 
compatible with the Ceilometer v2 API.

Regards --Roland


From: Simon Pasquier spasqu...@mirantis.commailto:spasqu...@mirantis.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, July 22, 2015 at 2:08 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,
I've had a quick look at the Etherpad which mentions Ceilosca. The name is 
quite intriguing but I didn't find any reference to it in the Monasca Wiki. 
Could you tell us a bit more about it? Does it mean that Monasca plans to 
expose an API that would be compatible with the Ceilometer API?
BR,
Simon

On Wed, Jul 22, 2015 at 8:08 PM, Hochmuth, Roland M 
roland.hochm...@hp.commailto:roland.hochm...@hp.com wrote:
The Monasca mid-cycle meet up will be held at the HP campus in Fort Collins, CO 
from August 5-6. Further details on the location, time and tentative agenda can 
be found at

https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

Regards --Roland

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Monasca mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Chandeep, The official dates of the meet up are

When:
August 05-06 2015.

Where:
HP Building 6
Lower level (street level) Room C6/7 (6LC7/9)
3404 E Harmony Rd (Ziegler), Fort Collins, CO 80528, United States

The information is at the Etherpad. We'll probably start at around 8:30 or
9:00 AM MST both days.

Sorry about the short-notice.

Regards --Roland



On 7/23/15, 5:39 PM, Chandeep Khamba ckha...@cray.com wrote:

Roland, 

Could you please specify the time of the meetup , I need to book my
Airtickes accordingly

On 7/23/15, 4:30 PM, Chandeep Khamba ckha...@cray.com wrote:

Hi Roland,

I am still a newbie to Monasca  , but would like to hear and participate
in the agenda items we already have.
If I have something specific would definitely add it.

Thanks

On 7/23/15, 1:58 PM, Hochmuth, Roland M roland.hochm...@hp.com wrote:

Hi Chandeep, There are no fees. It would be great if you could join us.
Also, please feel free to add to the agenda topics that you would like
to
cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.
o
r
g
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.
o
r
g
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I
could just come in .

Thanks
CHandeep


_
_
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


__
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 meetup

2015-07-22 Thread Hochmuth, Roland M

The Monasca mid-cycle meet up will be held at the HP campus in Fort Collins, CO 
from August 5-6. Further details on the location, time and tentative agenda can 
be found at

https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

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] [Marconi] Kafka support and high throughput

2014-06-04 Thread Hochmuth, Roland M

Hi Flavio, In your discussions around a developing Kafka plugin for
Marconi would that be potentially be done by adding a Kafka transport to
oslo.messaging? That is something that I'm very interested in for the
monitoring as a service project I'm working on.

Thanks --Roland


On 6/4/14, 3:06 AM, Flavio Percoco fla...@redhat.com wrote:

On 02/06/14 07:52 -0700, Keith Newstadt wrote:
Thanks for the responses Flavio, Roland.

Some background on why I'm asking:  we're using Kafka as the message
queue for a stream processing service we're building, which we're
delivering to our internal customers as a service along with OpenStack.
We're considering building a high throughput ingest API to get the
clients' data streams into the stream processing service.  It occurs to
me that this API is simply a messaging API, and so I'm wondering if we
should consider building this high throughput API as part of the Marconi
project.

Has this topic come up in the Marconi team's discussions, and would it
fit into the vision of the Marconi roadmap?

Yes it has and I'm happy to see this coming up in the ML, thanks.

Some things that we're considering in order to have a more flexible
architecture that will support a higher throughput are:

- Queue Flavors (Terrible name). This is for marconi what flavors are
  for Nova. It basically defines a set of properties that will belong
  to a queue. Some of those properties may be related to the messages
  lifetime or the storage capabilities (in-memory, freaking fast,
  durable, etc). This is yet to be done.

- 2 new drivers (AMQP, redis). The former adds support to brokers and
  the later to well, redis, which brings in support for in-memory
  queues. Work In Progress.

- A new transport. This is something we've discussed but we haven't
  reached an agreement yet on when this should be done nor what it
  should be based on. The gist of this feature is adding support for
  another protocol that can serve Marconi's API alongside the HTTP
  one. We've considered TCP and websocket so far. The former is
  perfect for lower level communications without the HTTP overhead
  whereas the later is useful for web apps.

That said. A Kafka plugin is something we heard a lot about at the
summit and we've discussed it a bit. I'd love to see that happening as
an external plugin for now. There's no need to wait for the rest to
happen.

I'm more than happy to help with guidance and support on the repo
creation, driver structure etc.

Cheers,
Flavio


Thanks,
Keith Newstadt
keith_newst...@symantec.com
@knewstadt


Date: Sun, 1 Jun 2014 15:01:40 +
From: Hochmuth, Roland M roland.hochm...@hp.com
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi] Kafka support and high
  throughput
Message-ID: cfae6524.762da%roland.hochm...@hp.com
Content-Type: text/plain; charset=us-ascii

There are some folks in HP evaluating different messaging technologies
for
Marconi, such as RabbitMQ and Kafka. I'll ping them and maybe they can
share
some information.

On a related note, the Monitoring as a Service solution we are working
on uses Kafka. This was just open-sourced at,
https://github.com/hpcloud-mon,
and will be moving over to StackForge starting next week. The
architecture
is at,
https://github.com/hpcloud-mon/mon-arch.

I haven't really looked at Marconi. If you are interested in
throughput, low latency, durability, scale and fault-tolerance Kafka
seems like a great choice.

It has been also pointed out from various sources that possibly Kafka
could be another oslo.messaging transport. Are you looking into that as
that would be very interesting to me and something that is on my task
list that I haven't gotten to yet.


On 5/30/14, 7:03 AM, Keith Newstadt keith_newst...@symantec.com
wrote:

Has anyone given thought to using Kafka to back Marconi?  And has there
been discussion about adding high throughput APIs to Marconi.

We're looking at providing Kafka as a messaging service for our
customers, in a scenario where throughput is a priority.  We've had good
luck using both streaming HTTP interfaces and long poll interfaces to
get
high throughput for other web services we've built.  Would this use case
be appropriate in the context of the Marconi roadmap?

Thanks,
Keith Newstadt
keith_newst...@symantec.com





Keith Newstadt
Cloud Services Architect
Cloud Platform Engineering
Symantec Corporation
www.symantec.com


Office: (781) 530-2299  Mobile: (617) 513-1321
Email: keith_newst...@symantec.com
Twitter: @knewstadt




This message (including any attachments) is intended only for the use of
the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential,
and exempt from disclosure under applicable law or may constitute as
attorney work product. If you are not the intended recipient, you are
hereby notified that any use, dissemination

Re: [openstack-dev] [Marconi] Kafka support and high throughput

2014-06-01 Thread Hochmuth, Roland M

There are some folks in HP evaluating different messaging technologies for
Marconi, such as RabbitMQ and Kafka. I'll ping them and maybe they can
share
some information.

On a related note, the Monitoring as a Service solution we are working
on uses Kafka. This was just open-sourced at,
https://github.com/hpcloud-mon,
and will be moving over to StackForge starting next week. The architecture
is at,
https://github.com/hpcloud-mon/mon-arch.

I haven't really looked at Marconi. If you are interested in
throughput, low latency, durability, scale and fault-tolerance Kafka
seems like a great choice.

It has been also pointed out from various sources that possibly Kafka
could be another oslo.messaging transport. Are you looking into that as
that would be very interesting to me and something that is on my task
list that I haven't gotten to yet.


On 5/30/14, 7:03 AM, Keith Newstadt keith_newst...@symantec.com wrote:

Has anyone given thought to using Kafka to back Marconi?  And has there
been discussion about adding high throughput APIs to Marconi.

We're looking at providing Kafka as a messaging service for our
customers, in a scenario where throughput is a priority.  We've had good
luck using both streaming HTTP interfaces and long poll interfaces to get
high throughput for other web services we've built.  Would this use case
be appropriate in the context of the Marconi roadmap?

Thanks,
Keith Newstadt
keith_newst...@symantec.com



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Monitoring as a Service

2014-05-06 Thread Hochmuth, Roland M

It sounds like there is some interest in this topic. With the Summit
just around the corner, I propose we get together while many
of us are there and explore this area further. I'm in the process of
researching the availability of a time and place, shooting for early
morning, prior to when the conference starts. I recognized a lot of names
on this thread, but not all, including the original poster, Alexandre. A
face-to-face I think would really help in this case and I'm assuming most
of the Ceilometer team will be at the Summit.

As a team, it would be good to understand and identify the primary
goals, areas of overlap and differences between where Ceilometer is
focused right now and monitoring as a service.

From an HP perspective, I can share what we've done with Jahmon so far and
our plans. We've given this area and our direction considerable thought.
We see
Ceilometer as synergistic with our direction and have developed
a Ceilometer pipeline publisher to send samples to Jahmon. Jahmon
will be open-sourced and has a significant amount of code and the backing
of 
a strong team right now, but we would like to start working in earnest
with the open-source community.

--Roland


On 5/6/14, 10:25 AM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Sandy Walsh's message of 2014-05-06 07:02:05 -0700:
 On 5/6/2014 10:04 AM, Thierry Carrez wrote:
  John Dickinson wrote:
  One of the advantages of the program concept within OpenStack is
that separate code projects with complementary goals can be managed
under the same program without needing to be the same codebase. The most
obvious example across every program are the server and client
projects under most programs.
 
  This may be something that can be used here, if it doesn't make
sense to extend the ceilometer codebase itself.
  +1
 
  Being under the Telemetry umbrella lets you make the right technical
  decision between same or separate codebase, as both would be supported
  by the organizational structure.
 
  It also would likely give you an initial set of contributors
interested
  in the same end goals. So at this point I'd focus on engaging with the
  Telemetry program folks and see if they would be interested in that
  capability (inside or outside of the Ceilometer code base).
 
 This is interesting.
 
 I'd be curious to know more what managed means in this situation? Is
 the core project expected to allocate time in the IRC meeting to the
 concerns of these adjacent projects? What if the core project doesn't
 agree with the direction or deems there's too much overlap? Does the
 core team instantly have sway over the adjacent project?
 

Yes, the core team instantly has sway. It is not to be taken lightly.

We absorbed Tuskar into the Deployment program, and our PTL, Robert
Collins, was able to get involved with the design of Tuskar early and
convince them to stay more aligned with other OpenStack projects. So
the benefit is now Tuskar can focus on the thing that they _do_ need
to do that are unique.  Likewise, their core team was given core status
in the deployment program, and was able to influence the pieces of the
Deployment program that they needed to work better.

This has created a nice cycle of contribution where many aspects of the
Deployment program's projects have been improved as a result. Had Tuskar
decided to just stay out of the Deployment program, they might have
reimplemented many of the things we had already done, and thus would
be less adoptable by users and they would receive less contribution as
a whole.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Monitoring as a Service

2014-05-05 Thread Hochmuth, Roland M

Alexandre, Great timing on this question and I agree with your proposal. I
work for HP and we are just about to open-source a project for Monitoring
as a Service (MaaS), called Jahmon. Jahmon is based on our
customer-facing monitoring as a service solution and internal monitoring
projects.

Jahmon is a multi-tenant, highly performant, scalable, reliable and
fault-tolerant monitoring solution that scales to service provider levels
of metrics throughput. It has a RESTful API that is used for
storing/querying metrics, creating compound alarms, querying alarm
state/history, sending notifications and more.

I can go over the project with you as well as others that are interested.
We would like to start working with other open-source developers. I'll
also be at the Summit next week.

Regards --Roland

On 5/4/14, 1:37 PM, John Dickinson m...@not.mn wrote:

One of the advantages of the program concept within OpenStack is that
separate code projects with complementary goals can be managed under the
same program without needing to be the same codebase. The most obvious
example across every program are the server and client projects under
most programs.

This may be something that can be used here, if it doesn't make sense to
extend the ceilometer codebase itself.

--John

On May 4, 2014, at 12:30 PM, Denis Makogon dmako...@mirantis.com wrote:

Hello to All.

I also +1 this idea. As I can see, Telemetry program (according to
Launchpad) covers the process of the infrastructure metrics (networking,
etc) and in-compute-instances metrics/monitoring.
So, the best option, I guess, is to propose add such great feature to
Ceilometer. In-compute-instance monitoring will be the great value-add
to upstream Ceilometer.
As for me, it's a good chance to integrate well-known production ready
monitoring systems that have tons of specific plugins (like Nagios etc.)

Best regards,
Denis Makogon

воскресенье, 4 мая 2014 г. пользователь John Griffith написал:

On Sun, May 4, 2014 at 9:37 AM, Thomas Goirand z...@debian.org wrote:
On 05/02/2014 05:17 AM, Alexandre Viau wrote:
Hello Everyone!

My name is Alexandre Viau from Savoir-Faire Linux.

We have submited a Monitoring as a Service blueprint and need
feedback.

Problem to solve: Ceilometer's purpose is to track and
*measure/meter* usage information collected from OpenStack components
(originally for billing). While Ceilometer is usefull for the cloud
operators and infrastructure metering, it is not a *monitoring* solution
for the tenants and their services/applications running in the cloud
because it does not allow for service/application-level monitoring and
it ignores detailed and precise guest system metrics.

Proposed solution: We would like to add Monitoring as a Service to
Openstack

Just like Rackspace's Cloud monitoring, the new monitoring service -
lets call it OpenStackMonitor for now - would let users/tenants keep
track of their ressources on the cloud and receive instant notifications
when they require attention.

This RESTful API would enable users to create multiple monitors with
predefined checks, such as PING, CPU usage, HTTPS and SMTP or custom
checks performed by a Monitoring Agent on the instance they want to
monitor.

Predefined checks such as CPU and disk usage could be polled from
Ceilometer. Other predefined checks would be performed by the new
monitoring service itself. Checks such as PING could be flagged to be
performed from multiple sites.

Custom checks would be performed by an optional Monitoring Agent.
Their results would be polled by the monitoring service and stored in
Ceilometer.

If you wish to collaborate, feel free to contact me at
alexandre.v...@savoirfairelinux.com
The blueprint is available here:
https://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-servi
ce

Thanks!

I would prefer if monitoring capabilities was added to Ceilometer rather
than adding yet-another project to deal with.

What's the reason for not adding the feature to Ceilometer directly?

Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I'd also be interested in the overlap between your proposal and
Ceilometer. It seems at first thought that it would be better to
introduce the monitoring functionality in to Ceilometer and make that
project more diverse as opposed to yet another project.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

38 matches

Mail list logo