Thanks!!!
I was actually going to ask this issue :)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
regards,
Paulo J. Nascimento Oliveira
http://about.me/pnascimento
Advanced Telecommunications and Networks Group - http://atnog.av.it.pt
Follow us - @ATNoG_ITAv
From: Eoghan Glynn < egl...@redhat.com >
Subject: Re: [openstack-dev] Monitoring as a Service
Date: 7 Ma
Hi Alexandre,
I wanted to let this discussion develop a little before jumping in, as
we've already had many circular debates about the cross-over between
ceilometer and monitoring infrastructure in general.
Personally I'm in favor of the "big tent/broad church" interpretation of
ceilometer's pro
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 conf
On 5/6/2014 1:48 PM, Thierry Carrez wrote:
> Sandy Walsh wrote:
>> 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 th
Sandy Walsh wrote:
> 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? Do
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
> >> s
On 05/06/2014 12:00 AM, Hochmuth, Roland M wrote:
> for Monitoring as a Service (MaaS)
Great care with MaaS, as it also means Metal as a Service.
Just my 2 cents.
Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op
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
>> ex
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 "c
Thanks to everyone for the feedback. I agree that this falls under the
Telemetry Program and I have moved the blueprint.
You can find it here:
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service
Wiki page: https://wiki.openstack.org/wiki/MaaS
Etherpad: https://etherpad.openst
Excerpts from John Dickinson's message of 2014-05-04 12:37:55 -0700:
> 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
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.
Jahm
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 pro
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-i
On Sun, May 4, 2014 at 9:37 AM, Thomas Goirand 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
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 colle
+1
I like this idea.
Best regards to you.
Ricky
> -Original Message-
> From: Alexandre Viau [mailto:alexandre.v...@savoirfairelinux.com]
> Sent: Friday, May 02, 2014 5:17 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Monitoring as a Service
>
> Hello Everyone!
Hello!
I have moved the blueprint to ceilometer.
It is now available here:
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service
We have also created an Etherpad. Feel free to come contribute:
https://etherpad.openstack.org/p/MaaS
> And since most of the monitoring systems
+1
And since most of the monitoring systems have standardized on supporting Nagios
plug ins, it would be great if it supported them too.
Thanks,
Kevin
From: Alexandre Viau [alexandre.v...@savoirfairelinux.com]
Sent: Thursday, May 01, 2014 2:17 PM
To: open
On Thu, 2014-05-01 at 17:17 -0400, 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
> inform
21 matches
Mail list logo
