and the customer is interested to know what his VMs do or can
do.
It would be nice to get the data from a single point. I thought I can
enhance the Ceilometer compute agent to get this data out. Does this make
sense or is it better to use another monitoring tool for the physical
components?
I
usable
with different sinks.
On Nov 1, 2012, at 1:17 PM, Sandy Walsh wrote:
Hey!
Here's a first pass at a proposal for unifying StackTach/Ceilometer and other
instrumentation/metering/monitoring efforts.
It's v1, so bend, spindle, mutilate as needed ... but send feedback!
http
work on this? Is there a repo setup yet?
-A
On Nov 1, 2012, at 1:17 PM, Sandy Walsh wrote:
Hey!
Here's a first pass at a proposal for unifying StackTach/Ceilometer and other
instrumentation/metering/monitoring efforts.
It's v1, so bend, spindle, mutilate as needed ... but send feedback
what his VMs do
or can do.
It would be nice to get the data from a single point. I thought I can
enhance the Ceilometer compute agent to get this data out. Does this
make sense or is it better to use another monitoring tool for the
physical components?
I think the pollster implementation
Lucas (graflu0); Zehnder Toni (zehndton);
openstack@lists.launchpad.net; Doug Hellmann
Subject: Re: [Openstack] [ceilometer] Monitoring physical devices
On Tue, Nov 6, 2012 at 10:53 PM, Julien Danjou jul...@danjou.info wrote:
On Tue, Nov 06 2012, Graf Lucas (graflu0) wrote:
I'm a little
From: Doug Hellmann [doug.hellm...@dreamhost.com]
Sent: Thursday, November 08, 2012 1:54 PM
To: Sandy Walsh
Cc: Eoghan Glynn; OpenStack Development Mailing List;
openstack@lists.launchpad.net
Subject: Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified
notification_driver=cinder.openstack.common.notifier.rabbit_notifier
notification_driver=cinder.openstack.common.notifier.rpc_notifier
in cinder.conf and restarting cinder-volume service and ceilometer-collector
service.
Still I am not getting any volume related meters. Neither they are mentioned
in resources
Hi Stackers
I've installed the requirements from requirements.txt with pip, and then
tried to install the ceilometer client, and I get this error:
root@control:~/python-ceilometerclient# python setup.py install
running install
Traceback (most recent call last):
File setup.py, line 21
I am not getting disk.root.size meter notifications from nova to ceilometer. I
am getting all ther pollster meters but not notification meters.
Do I need to add any cron job like cinder to get notifications?
I am using devstack and below are the contents of my nova.conf.
firewall_driver
of metrics from SWIFT - Object Storage
Hallo All,
Based on the documentation from Ceilometer, I see the metrics from all the
components except SWIFT. Can I get to know whether Ceilometer offers any
metrics from the SWIFT component?
Thanks
Krishnaprasad
I think Luis can answer that?
-- Videresendt melding --
Fra: Jobin Raju George jobin...@gmail.com
Dato: 11. juli 2013 14:38
Emne: [Openstack] Documentation for openstack-java-sdk
Til: openstack lista openstack@lists.launchpad.net
Kopi:
I am trying to query ceilometer using
: [Openstack] [Ceilometer] Problems with query fields in filters
On Fri, Jul 12 2013, Alessandro Barabesi wrote:
I have the following problems with query fields in filters.
1) Filtering by metadata.size in v2/meters/image apparently is not working.
The following request returns also samples
Hi,
We had a plan to write some plugin which will collect metering data from
VMs and Hosts (free ram, networking, disk IO, cpu both from VMs and Hosts)
via libvirt (mayby later for xen etc), but i've found ceilometer project,
which is doing what I want or will be doing what I want in near future
to complete. It
should have access to the context (http return status, user, operation
etc) so would be able to raise a notification if appropriate. Using a
standard notifier would mean output could be to a log file or, perhaps
in time, the notifications could be consumed by ceilometer.
LOL, that's
I know nothing about ceilometer.
I think the best thing is to checkout the classes on github and make a lot
of tests. Probably to functioning of objects and methods are the same in
ceilometer.
CHeckout the methods and try to workout with it.
:)
Good luck!
On Thu, Jul 11, 2013 at 11:59 AM, Jobin
Okay, thanks Gui! Lets see how things go, but still I'm awaiting a little
help with respect to the documentation and examples :/
On Thu, Jul 11, 2013 at 8:31 PM, Gui Maluf guimal...@gmail.com wrote:
I know nothing about ceilometer.
I think the best thing is to checkout the classes on github
PageBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 1178 lines...]hard linking tests/storage/test_impl_log.py -> ceilometer-2013.2/tests/storagehard linking tests/storage/test_impl_mongodb.py -> ceilometer-
). With this approach, folks could control
both the volume of metrics and also the outlet for the metrics. Ceilometer
would also be an outlet that could be leveraged via RPC flow for metrics --
though I'd expect some would want to send via datagram to statsd or file for
offline log aggregation.
I'll post a diagram
Yes, I am assuming the service controller provides a different stream of
data from the lower level VM events. So the question is how to represent
and store this additional meta data in ceilometer. Note that there
doesn't necessarily need to be a linkage/grouping between the resources
since
, for
experienced developers, hiring managers and newcomers to this great
community.
Ceilometer Grizzly 2 Milestone Available
http://blog.doughellmann.com/2013/01/ceilometer-grizzly-2-milestone-available.html
The Ceilometer team is proud to announce the first synchronous milestone
delivery
Hi all,
Here's a better-late-than-never release status update for Ceilometer 0.9. We're
now a week away from release.
Release in numbers
--
Bugs in progress: 5
Fixes committed: 39
Triaged bugs: 15
Confirmed bugs: 21
New bugs: 1
These numbers were generated using
*are* building such integration systems at the
same time that we are building ceilometer. That's where these requirements
are coming from! :-) I don't expect to be releasing all of the code for
that integration, but I will release what I can and I am happy to talk
about the general requirements
up openshift (sdake, 21:23:54)
* ACTION: shardy working on initial cloudwatch improvements - to
potentially merge into ceilometer later without much wasted effort
(sdake, 21:25:38)
* ACTION: zaneb help wrap up integration testing and start cracking on
openstack orchestration rest api
Hi Eoghan,
Thanks for your reply. As we can see from the document:
-
Three type of meters are defined in ceilometer:
TypeDefinition
Cumulative Increasing over time (instance hours)
Gauge Discrete items (floating
Cool! Grizzly G3 is on Raring Ringtail!
I'm seeing lots of AWESOME new packages here! Like Ajax Console, SPICE
proxy, Ceilometer, Nova Cells and Baremetal and go on...
But, no Heat package available... Is Heat a requirement to run Grizzly G3?
Or can I start testing it now with those packages
Hi
On 13-02-25 01:34 PM, Martinx - ジェームズ wrote:
Cool! Grizzly G3 is on Raring Ringtail!
I'm seeing lots of AWESOME new packages here! Like Ajax Console, SPICE
proxy, Ceilometer, Nova Cells and Baremetal and go on...
But, no Heat package available... Is Heat a requirement to run Grizzly
G3
Thanks a log, Gui! This helps but would be more useful if you could point
me to some *ceilometer-specific *guides/examples.
On Thu, Jul 11, 2013 at 8:25 PM, Gui Maluf guimal...@gmail.com wrote:
Surely Luis can help you, I've used openstack-java-sdk in one of my
projects
the project name: ceilometer.
For a more complete meeting summary, go visit:
http://wiki.openstack.org/Meetings/MeteringAgenda/meeting-0-summary
Next week we will have for objective to find an agreement on schema and
counter definitions. If anyone does not do it before me I'll fire an
introduction
Forgot to copy the list
-- Forwarded message --
From: Luis Gervaso l...@woorea.es
Date: Wed, May 9, 2012 at 7:14 PM
Subject: Re: [Openstack] ceilometer (java implementation)
To: Doug Hellmann doug.hellm...@dreamhost.com
I asked for these fields in my previous email
On May 22, 2012, at 5:15 AM, Tom tom.gal...@hp.com wrote:
On 05/21/2012 10:52 PM, Doug Hellmann wrote:
I have written up some of my thoughts on a proposed design for
ceilometer in the wiki [1]. I'm sure there are missing details, but I
wanted to start getting ideas into writing so
...@dreamhost.comwrote:
I have written up some of my thoughts on a proposed design for ceilometer
in the wiki [1]. I'm sure there are missing details, but I wanted to start
getting ideas into writing so they could be discussed here on the list,
since I've talked about different parts with a couple
for ceilometer
in the wiki [1]. I'm sure there are missing details, but I wanted to start
getting ideas into writing so they could be discussed here on the list,
since I've talked about different parts with a couple of you separately.
Let me know what you think, and especially if I am not clear or have
. A problem that no other OpenStack components tried
to resolved, AFAIK. So I don't see why we should try to resolve
configuration deployment in ceilometer when it's a much larger issue in
the project.
--
Julien Danjou
// eNovance http://enovance.com
// ✉ julien.dan...@enovance.com
. A problem that no other OpenStack components tried
to resolved, AFAIK. So I don't see why we should try to resolve
configuration deployment in ceilometer when it's a much larger issue in
the project.
--
Julien Danjou
// eNovance http://enovance.com
// ✉ julien.dan...@enovance.com
include all of the data about the instance. My current plan
is to have the collector code that processes notifications look up the
instance in the database to get the rest of the data.
Does anyone have any thoughts on this plan?
https://bugs.launchpad.net/ceilometer/+bug/1006120
agree on meter configuration mechanism [1]
* Discuss proposing ceilometer as an incubated project
* Prepare documentation and framework for plugin contributors
* Establish communication with swift/quantum/cinder on best points of
interaction for our agents
* Status of the essex compatibility
/dhellmann/ceilometer/commit/18130bcafabf23871831e9b4913752ebb7b9f3ef
[2] http://wiki.openstack.org/EfficientMetering/APIProposalv1
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
Hi Julien,
On 25/06/12 10:15, Julien Danjou wrote:
We've a couple of problem on Stackforge currently with at least the
ceilometer project.
First, I don't receive any email from Gerrit anymore since several days.
:-(
As we have pointed out several times the Stackforge Gerrit mail
and tests on
jenkins.openstack.org.
If there are any problems please get in touch with the CI team (note it
is 4th July holidays so probably just me today)
Thanks, Andrew, it looks like the ceilometer parts are working just fine!
Doug
___
Mailing list
against
quota. In that, I don't know if we even track past quotas anywhere. So I am
going to avoid jumping into that any time soon. Maybe that's a job for
ceilometer.
-Matt
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
Hello,
As we are observing that the current meeting time is not very convenient
for a few contributors, we would like to propose to change the date and
time to something that would suit a larger number. I propose that we do
this in a two phase process:
1/ Each project member that care should
Hi,
You should read Ceilometer Project [1] and try it into DevStack directly in
editing localrc before to run devstack and add :
enable_service ceilometer-acompute,ceilometer-acentral, ceilometer-collector
Enjoy !
[1] http://wiki.openstack.org/EfficientMetering
Regards,
-Emilien
On Thu
OpenStack Management UI to integrate
identity (keystone), compute (nova, +glance, +melange), storage (swift) and
billing (ceilometer)
The architecture proposed is
Angular JS + Vertx.io (Java, Groovy and Python)
Hope to see your forks!
Cheers
On 09/05/2012 01:11 PM, surya_prabha...@dell.com wrote:
On 09/05/12 15:49, Nick Barcet wrote:
PLEASE NOTE THE NEW MEETING TIME, ONE HOUR EARLIER
The metering project team holds a meeting in #openstack-meeting,
Thursdays at 1500 UTC
On Fri, Oct 05 2012, Graham Binns wrote:
These numbers were generated using a launchpadlib API script
(attached). We haven't set up a milestone for the 0.9 release; I
suggest that we do and will take care of it today if no-one objects.
Agreed, thanks!
Status of roadmap
-
On Wed, Oct 24 2012, 吴亚伟 wrote:
I still have questions about the data in the mongodb.
First: All the data about source in db is ?,for example:
is it correct?
Yes, that's what we used for now in the source code, so this is correct.
second,when I create a instance,there will be
On Thu, Oct 25 2012, Doug Hellmann wrote:
IIUC, what's need here is a GROUP BY operator in the API.
Correct me if I'm wrong, but this is still doable via the API if you
request /users/user/meters/instance and treats the events in the
client, no?
It is possible, but very very inefficient.
On Oct 26, 2012, at 4:29 AM, Julien Danjou jul...@danjou.info wrote:
On Thu, Oct 25 2012, Doug Hellmann wrote:
IIUC, what's need here is a GROUP BY operator in the API.
Correct me if I'm wrong, but this is still doable via the API if you
request /users/user/meters/instance and treats
Not at all. It means the CPU time consumed is reset to 0, but
that's not an issue in itself, the API should be capable to
deal with that if you ask for the total usage.
Would that total usage be much more apparent if we started
metering the delta between CPU times on subsequent polling
is no
exception.
+ Key Performance Indicators (kpi's). Useful for SLA's and other shirt stuff.
There is some support in there now (via stacky), but it's busted and
inefficient. I'm going to be getting this working again immediately.
+ Integration with ceilometer. We're duplicating effort here
On Mon, Nov 05 2012, Doug Hellmann wrote:
If we make the current compute agent take an option telling it which
pollster namespace to use, then the same framework can load different
pollsters. However, there is a fundamental security issue with
communicating from an agent running inside a
On Tue, Nov 6, 2012 at 10:53 PM, Julien Danjou jul...@danjou.info wrote:
On Tue, Nov 06 2012, Graf Lucas (graflu0) wrote:
I'm a little confused now... ;) Is the bare metal run by the platform
operator the physical machine? What do you mean with the bare metal
run to replace virtual instances
.
(note: aux are all the minor actions, like list, show, etc)
https://github.com/rackspace/stacktach
(.../reports/pretty.py)
We're in the process of porting all this stuff over to ceilometer, but
that's a longer term effort.
We've also got a more detailed report with causes of errors, cell
breakdown
It doesn't - the AMQP is needed for the Nova/Glance/Cinder/Ceilometer
integration and that internal RPC mechanism that they use.
-joe
On Feb 19, 2013, at 4:53 PM, Everett Toews everett.to...@rackspace.com wrote:
Hi All,
When I was doing a Swift/Keystone only install with DevStack I used
:
What is the status of Openstack Grizzly-3 Ubuntu packages?
Can we already set it up using apt-get / aptitude? With packaged Heat,
Ceilometer and etc?
Which version is recommended to test Grizzly-3, Precise (via testing
UCA), Raring?
Is Grizzly planed to be the default Openstack for Raring?
I
Thanks for the heads up, Sandy. There was some talk in the last release
cycle about possibly merging some or all of the StackTach functionality
with Ceilometer. Is that still on the horizon or has that idea been
scuttled?
Best,
-jay
On 03/25/2013 09:42 AM, Sandy Walsh wrote:
Hi, how are you? Me
resource from Libvirt and run
time resource usage details from Nagios. The aggregated information is
published via REST APIs and the APIs are programmed in Java.
I would like to have a feedback from the community whether our monitoring using
Nagios can be used or integrated with Ceilometer / Healthnmon
have referred to this link but it isn't very helpful:
- Utilization data https://wiki.openstack.org/wiki/Utilizationdata
I have a controller node and a compute node on two different hosts(both on
Ubuntu 12.04). I couldn't get ceilometer to fetch these data for me and I
read healthnmon is meant
Hi everybody,
I have the following problems with query fields in filters.
1) Filtering by metadata.size in v2/meters/image apparently is not working.
The following request returns also samples with metadata.size=0.
GET http://10.10.10.10:8777/v2/meters/image
{
q: [{
well use
Keystone for identity but generate different billable events. Should
source be the origin of the metric data being sent to ceilometer?
As I see it, source should remain the same as long as you can correlate
project_id and user_id from the same source.
* add another record
of metering is indeed always implemented in
similar ways. I had discussions with a company yesterday about their own
metering implementation (which will be used in production soon) and it also has
an architecture matching what has been proposed so far in ceilometer. I added a
few points
/ceilometer/extensions/.py and loads it.
The module defines a query function that takes the following arguments:
Andrew Bogott is doing some work with a standardized plugin mechanism for
Nova which will eventually be put in the common lib for all of the
projects. We should look at his work
On 05/21/2012 10:52 PM, Doug Hellmann wrote:
I have written up some of my thoughts on a proposed design for
ceilometer in the wiki [1]. I'm sure there are missing details, but I
wanted to start getting ideas into writing so they could be discussed
here on the list, since I've talked about
/EfficientMetering/GrizzlySummit
* Discussion on alternating meeting time to allow presence from down
under
Well thanks for trying. I guess I am the only one down this end.
The main things I'd like to achieve is to add alarms and monitoring
to ceilometer.
To achieve this we would need:
- auth
case where the instance has been restarted
within a polling period).
Cheers,
Eoghan
[1] https://review.openstack.org/14921
I am still testing ceilometer now. I am confused about the meter
volume
in the mongodb. Let's talk about cpu usage.
After I create and boot a vm named vm_1, meter
with different sinks.
Hmm, really not a fan of the decorator approach. Makes the code really ugly.
They'd be everywhere.
Not sure if I can get over it. :D
-S
On Nov 1, 2012, at 1:17 PM, Sandy Walsh wrote:
Hey!
Here's a first pass at a proposal for unifying StackTach/Ceilometer and other
the xz, and not just gz) from *any* commit,
if we want to. Let me explain how it works.
Let's say I want to make a snapshot release of Ceilometer for the commit
hash 23ff2f9bbfc14e435c4c04fba473cf2a829b (this is an actual real
life example, in fact...). Then, to do that, I just do:
git checkout
Ceilometer (OpenStack Metering). What happens when they grow to
cover Monitoring ? You rename the project to OpenStack Metering and
Monitoring ? Or you keep the partial functional description ? I'd
rather avoid to rename everything every time a project evolves. Those
renames are *extremely* costly
-
From: Angus Salkeld [mailto:asalk...@redhat.com]
Sent: venerdì 12 luglio 2013 12:55
To: openstack@lists.launchpad.net
Cc: Alessandro Barabesi
Subject: Re: [Openstack] [Ceilometer] Problems with query fields in filters
On 12/07/13 11:33 +0200, Julien Danjou wrote:
On Fri, Jul 12 2013
function in a cache
* discuss event collection
* events are collected from a components when possible
* ceilometer agent is installed on a node when the a component does not
provide the value
* contribute to the component instead of developping a ceilometer agent
plugin
* engaging
of the sum function in a
cache
* discuss event collection
* events are collected from a components when possible
* ceilometer agent is installed on a node when the a component
does not
provide the value
* contribute to the component instead of developping a ceilometer
agent
plugin
are collected from a components when possible
* ceilometer agent is installed on a node when the a component does
not provide the value
* contribute to the component instead of developping a ceilometer
agent plugin
* engaging discussions with core components
* nova
* cinder
, networking, disk IO, cpu both from VMs and Hosts)
via libvirt (mayby later for xen etc), but i've found ceilometer project,
which is doing what I want or will be doing what I want in near future :).
I was thinking about collectd/ganglia/munin as source of data and I wanted
to write local agents which
On 08/30/2012 03:40 AM, Emilien Macchi wrote:
Hi,
You should read Ceilometer Project [1] and try it into DevStack directly
in editing localrc before to run devstack and add :
enable_service ceilometer-acompute,ceilometer-acentral, ceilometer-collector
Enjoy !
[1] http
Thanks for your quick reply, Simon,
The role ResellerAdmin does exists and looks good, does it?
root@ns-proxy01:/etc/swift# keystone user-get ceilometer
+--+--+
| Property | Value
exists and looks good, does it?
root@ns-proxy01:/etc/swift# keystone user-get ceilometer
+--+--+
| Property | Value |
+--+--+
| email | |
| enabled
Hi,
I'm not sure to understand exactly your issue but since your setup
includes ceilometer, I can just give you a hint for the ceilometer/swift
integration.
You have to create a 'ResellerAdmin' role and assign that role to your
ceilometer user. Alternatively you can define
/jenkins/www/apt/dists/utopic-juno/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/utopic-juno/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2014.2+git201410081838~utopic-0ubuntu1_all.debdeleting
/c/ceilometer/ceilometer-agent-central_2014.3+git201412040630~vivid-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer/ceilometer-agent-compute_2014.3+git201412040630~vivid-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer/ceilometer-agent-ipmi_2014.3+git201412040630~vivid
then having each Collector
connect to the db..
That was the goal, but I may have swapped the terminology around. For
ceilometer, the agent runs on the compute node and writes only to the
message queue. The collector runs in a central location and writes to the
database. The number of collectors you
in Quantum. Why not do
something similar?
I mean if you have a MQ cluster in a deployment I think it makes more
sense to have 1 thing that handles the db stuff then having each Collector
connect to the db..
That was the goal, but I may have swapped the terminology around. For
ceilometer, the agent
think it makes more
sense to have 1 thing that handles the db stuff then having each Collector
connect to the db..
That was the goal, but I may have swapped the terminology around. For
ceilometer, the agent runs on the compute node and writes only to the
message queue. The collector runs
tl;dr: Ceilometer should ignore resource metadata when computing sums or
maximum values for counters through the API.
One of the things we discussed early during the design meetings was the
need to track metadata along with resources so providers could use the
metadata to determine the rate
of
the Amazon Web Service CloudWatch API
http://aws.amazon.com/cloudwatch/ for OpenStack
http://openstack.org/. Julien Danjou
http://julien.danjou.info/blog/, a contributor to the Ceilometer
http://launchpad.net/ceilometer project, gives a look at this project
and how it could overlap with Ceilometer
-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesImported Translations from Transifexby openstack-infraeditceilometer/locale/ceilometer-log-warning.poteditceilometer/locale/it/LC_MESSAGES/ceilometer-log-info.poaddceilometer/locale/pt_BR/LC_MESSAGES/ceilometer-log
the meeting.
GET extension=param1=fooparam2=bar
The API looks up /usr/share/ceilometer/extensions/.py and loads it.
The module defines a query function that takes the following arguments:
Andrew Bogott is doing some work with a standardized plugin mechanism for
Nova which
...@canonical.com
On 05/21/2012 10:52 PM, Doug Hellmann wrote:
I have written up some of my thoughts on a proposed design for
ceilometer in the wiki [1]. I'm sure there are missing details, but I
wanted to start getting ideas into writing so they could be discussed
here on the list, since I've
On Tue, May 22, 2012 at 3:40 AM, Nick Barcet nick.bar...@canonical.comwrote:
On 05/21/2012 10:52 PM, Doug Hellmann wrote:
I have written up some of my thoughts on a proposed design for
ceilometer in the wiki [1]. I'm sure there are missing details, but I
wanted to start getting ideas
alternative strategy are you suggesting? That if glance, quantum,
cinder and ceilometer want to re-use Nova's RPC code, they should
copy-and-paste it and hack it to their needs?
I don't think our only options here are immediate adoption and relative
chaos.
Here's what I would like to see
and then
extract the tag and send it with the metadata associated with
the meter. Then you could query the ceilometer db for that group.
(In CloudWatch this is just another Dimension).
-Angus
--
Julien Danjou
-- Free Software hacker freelance
-- http://julien.danjou.info
only to particular topics. I know there have been at least a
couple of threads about Quantum in the past couple of weeks (one
pertaining to Ceilometer integration, one pertaining to the Folsom
stable branch come to mind) that didn't have [Quantum] (or [Ceilometer]
for that matter) in the subject line
Cheers,
Eoghan
[1] https://review.openstack.org/14921
I am still testing ceilometer now. I am confused about the meter
volume
in the mongodb. Let's talk about cpu usage.
After I create and boot a vm named vm_1, meter data record about cpu
usage will be inserted into db in cycle
of contributors around it) is
*distinct* from the functional scope of what its code does.
Take Ceilometer (OpenStack Metering). What happens when they grow to cover
Monitoring ? You rename the project to OpenStack Metering and Monitoring ?
Or you keep the partial functional description ? I'd rather
@lists.launchpad.net
Kopi:
I am trying to query ceilometer using
openstack-java-sdkhttps://github.com/woorea/openstack-java-sdkfor meters of
VM's running on KVM. I am able to get the CPU meters via curl
on the command line but unfortunately I don't find good documentation for
the SDK's
Hello,
The 3rd meeting of the Ceilometer project will be held on May 10th at
1600 UTC in the #openstack-meeting channel on Freenode. The main subject
we will be tackling this week is the external API definition and I'd
like to gather you opinions on the subject prior to the meeting.
The current
On Tue, May 8, 2012 at 11:27 AM, Nick Barcet nick.bar...@canonical.comwrote:
Hello,
The 3rd meeting of the Ceilometer project will be held on May 10th at
1600 UTC in the #openstack-meeting channel on Freenode. The main subject
we will be tackling this week is the external API definition
Hello everyone,
Next week's irc meeting will have for goal to choose a reference
messaging queue service for the ceilometer project. For this meeting to
be able to be successful, a discussion on the choices that we have to
make need to occur first right here.
To open the discussion here
into that daemon and ensure that periodic
tasks are triggered at regular (and relatively dependable) intervals then
we could move the agent portion of ceilometer into the common agent.
Is there a project for creating that? Or a blueprint I could subscribe to?
-Matt
On Tue, May 22, 2012 at 11:08 AM
/EfficientMetering/ArchitectureProposalV1?action=diffrev2=10rev1=9
On Mon, May 21, 2012 at 5:52 PM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
I have written up some of my thoughts on a proposed design for
ceilometer in the wiki [1]. I'm sure there are missing details, but I
wanted to start getting
exists for all other
OpenStack components. A problem that no other OpenStack components tried
to resolved, AFAIK. So I don't see why we should try to resolve
configuration deployment in ceilometer when it's a much larger issue in
the project.
Maybe the problem of discrepancy of configuration
401 - 500 of 1811 matches
Mail list logo
