Open Stack

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 project mandate, and would welcome further development of
our capabilities in this area (whether directly within the ceilometer
code-tree itself, or within a parallel repo aligned with the Telemetry
program).

In terms of furthering the discussion, unfortunately you've missed the
boat in terms of securing a slot in the design summit next week in
Atlanta (proposal deadline was April 20th, and the scheduling has all
been finalized at this stage).

However, we do have a project pod space available for ad-hoc overflow
sessions. I would suggest that we organize something on this theme
after the main ceilometer track[1] has completed, say on the Thursday
or Friday. Please reach out on IRC to discuss availability for this
and we'll work out something around remote participation.

Thanks,
Eoghan

[1] http://junodesignsummit.sched.org/overview/type/ceilometer

----- Original Message -----
> 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.openstack.org/p/MaaS
> 
> > 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.
> Roland,
> 
> I currently have no plans to be at the Summit next week. However, I
> would be interested in exploring what you have already done and learn
> from it.  Maybe we can schedule a meeting? You can always contact me on
> IRC (aviau) or by e-mail at alexandre.viau at savoirfairelinux.com
> 
> For now, I think we should focus on the use cases. I invite all of you
> to help us list them on the Etherpad.
> 
> Alexandre
> 
> 
> 
> On 14-05-05 12:00 PM, Hochmuth, Roland M wrote:
> > 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" <me at 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 <dmakogon at 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 <zigo at 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.viau at 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 at 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 at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>