Following up on our last meeting and the comments collected on the
mailing list, here is a second version of the proposal for centrally
hosting configuration of meters in ceilometer.
The main idea is that all meters of a given type should be sending
similarly formatted information in order
of the data.
Does anyone have any thoughts on this plan?
https://bugs.launchpad.net/ceilometer/+bug/1006120
Well, this seems a bit inelegant to me to have collectors to additional
lookup in an external DB where otherwise it's role would be limited to
handle and store event. It would
/possible). Also, it sort of depends on the architecture and
use model details of Ceilometer, which I hate to admit but I'm not
really up to speed on.
My first reaction/thought is the best most appropriate place to tie in
is via the python-cinderclient. There would be a number of ways
on the other sides (consistency where
practical/possible). Also, it sort of depends on the architecture and
use model details of Ceilometer, which I hate to admit but I'm not
really up to speed on.
My first reaction/thought is the best most appropriate place to tie in
is via the python
/ceilometer/+bug/1005944
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
of the form $project-$branch.tar.gz which will get
overwritten with each commit - that way, if you need to track trunk from
a pip-requires file, (such as ceilometer, which needs to track nova
trunk) you can simply plop in something like
http://tarballs.openstack.org/nova/nova-master.tar.gz - and it'll work
On 07/11/2012 02:24 PM, Nick Barcet wrote:
Candidates should, before July 24th:
1/ declare themselves on this mailing list
It has been so much fun and so rewarding to kick-start this project,
that I can't resist to propose myself as Candidate. Not being a true
developer places me in an awkward
and is stable enough for more general
evaluation by the OpenStack community.
We did watch the Ceilometer incubation proposal, and noted the fact that
the PPB would like projects to spend more time in initial development
before requesting incubation. Still we feel our code is in great shape
of resources
against quotas.
Maybe later we can provide some graphing of deltas in resource use 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
On 29/08/12 19:21 -0700, Nick Barcet wrote:
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
On Thu, Aug 30 2012, Angus Salkeld wrote:
I'd like to attend but am in Australia. I am quite flexible so it might
be easier to say what times don't suit.
Basically midnight - 6am which in UTC is 14:00 to 20:00
That's gonna be a tough one. :)
In the same idea, living in France, I'd exclude
This is will be an alternative 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 08:55 AM, SPN wrote:
On 2012-08-31 21:34, Nick Barcet wrote:
On 08/30/2012 09:49 AM, Nick Barcet wrote:
I am about to open a poll to pick from 0600, 1200, 1500 and 2100 UTC on
Google. Will reply to this thread when it opens. We'll have to go with
what fits most.
The poll is
PLEASE NOTE THE NEW MEETING TIME, ONE HOUR EARLIER
The metering project team holds a meeting in #openstack-meeting,
Thursdays at 1500 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0.
Everyone is welcome.
Agenda:
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 Wed, Sep 5, 2012 at 5:51 AM, Nick Barcet nick.bar...@canonical.comwrote:
On 09/05/2012 08:55 AM, SPN wrote:
On 2012-08-31 21:34, Nick Barcet wrote:
On 08/30/2012 09:49 AM, Nick Barcet wrote:
I am about to open a poll to pick from 0600, 1200, 1500 and 2100 UTC on
Google. Will reply to
On 09/05/2012 11:51 AM, Nick Barcet wrote:
Thanks for asking, I was just about to come up with this. So based on
the poll, it seems that the 3-4pm UTC time slot received the most favors
with 9 yes, 1 if need be and 1 no. So I guess we'll have to do
without Angus, unless we want to do
On 07/09/12 12:39 +0200, Nick Barcet wrote:
On 09/05/2012 11:51 AM, Nick Barcet wrote:
Thanks for asking, I was just about to come up with this. So based on
the poll, it seems that the 3-4pm UTC time slot received the most favors
with 9 yes, 1 if need be and 1 no. So I guess we'll have to do
On Fri, Sep 7, 2012 at 6:39 AM, Nick Barcet nick.bar...@canonical.comwrote:
On 09/05/2012 11:51 AM, Nick Barcet wrote:
Thanks for asking, I was just about to come up with this. So based on
the poll, it seems that the 3-4pm UTC time slot received the most favors
with 9 yes, 1 if need be
于 2012年10月24日 17:35, Julien Danjou 写道:
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.
If it
That would be one way, but adding dimensions to the meters also makes
sense because it reduces the need to collect the data more than once. For
instance, if flavor was a dimension of the instance meter I wouldn't
need the separate meter instance:flavor. These sorts of use cases were
part of the
On Thu, Oct 25 2012, Doug Hellmann wrote:
That would be one way, but adding dimensions to the meters also makes
sense because it reduces the need to collect the data more than once.
In case of group, the other problem is how to emit instance counter with
group metadata (assuming this group
On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote:
On Thu, Oct 25 2012, Doug Hellmann wrote:
That would be one way, but adding dimensions to the meters also makes
sense because it reduces the need to collect the data more than once.
In case of group, the other
On Wed, Oct 31 2012, 吴亚伟 wrote:
1) '12389000' nanoseconds means '123.89' seconds or two minutes,it
seem like to be 1238.9 seconds actually, is there something wrong ?
Why do you think it's 1238.9 seconds?
2) If I never reboot or suspend vm_1, will the 'counter_volume' of cpu
usage
On Wed, Oct 31 2012, Doug Hellmann wrote:
Is that better than just reporting the data in a more easily digested
format in the first place?
IMHO yes.
Julien, I don't understand your comment about losing data if your system
is not launched to compute delta. Can you clarify what you mean
于 2012年10月31日 21:56, Julien Danjou 写道:
On Wed, Oct 31 2012, 吴亚伟 wrote:
1) '12389000' nanoseconds means '123.89' seconds or two minutes,it
seem like to be 1238.9 seconds actually, is there something wrong ?
Why do you think it's 1238.9 seconds?
Well, to be honest, I do really though it's
On Wed, Oct 31 2012, Eoghan Glynn wrote:
Yep the sum of local maxima is not lossy as long as the requested
duration completely encapsulates the compute agent outage (and the
instance doesn't restart during the outage).
Actually, if there's one restart, it still _can_ be safe in certain
if you have:
Time | Value
0 | 10
1 | 30
2 | 50
3 | 80
4 | 100
If your delta-pollster is down at 1 and 2, you restart at 3,
therefore at 4 you'll send 20 as usage (100 minus 80).
So you miss the delta between 10 (time 0) and 80 (time 3)
(therefore 70 for free!). If
On Thu, Nov 1, 2012 at 1:31 PM, Eoghan Glynn egl...@redhat.com wrote:
if you have:
Time | Value
0 | 10
1 | 30
2 | 50
3 | 80
4 | 100
If your delta-pollster is down at 1 and 2, you restart at 3,
therefore at 4 you'll send 20 as usage (100 minus 80).
So you miss
filed several reviews for that:
https://review.openstack.org/#/c/20479/
https://review.openstack.org/#/c/20119/
https://review.openstack.org/#/c/20127/
Feel free to add some weight to the open ones. I wanted to get some
feedback before adding reviews to the missing components
(glance,ceilometer
to notify
somewhere about the account being over quota ideally it would be an option
to get to ceilometer or other plugged in system.
Chmouel.
On Wed, Feb 20, 2013 at 11:11 AM, Alex Yang alex890...@gmail.com wrote:
Storage Quotas
Designhttps://docs.google.com/document/d/1b5hkT_E8PyzaAPjNImW0SF
quota middleware but I am waiting on the
other review for account info metadata to send it for reviews.
- Down the line but probably not for the v1 I like to be able to notify
somewhere about the account being over quota ideally it would be an option
to get to ceilometer or other plugged
Hi!
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
On 03/25/2013 10:47 AM, Jay Pipes wrote:
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?
Nope, we are absolutely
All good in the hood. :) Thanks mate!
On 03/25/2013 09:57 AM, Sandy Walsh wrote:
On 03/25/2013 10:47 AM, Jay Pipes wrote:
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
/sysctl.conf file and it is working!
I'll ask for the help of this community to finish my guide.
On my `TODO list' I have: enable Metadata, Spice and Ceilometer.
Volunteers?!
Best!
Thiago
On 20 March 2013 19:51, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:
Hi!
I'm working with Grizzly G3+RC1
active are Oslo, Nova,
Heat, and Ceilometer.
Does that answer your question?
Thanks,
Dave.
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
Hi!
The `Ultimate OpenStack Grizzly Guide' is a bit more updated!
There are two new scripts: keystone_basic.sh and
keystone_endpoints_basic.sh which preliminary support for Swift and
Ceilometer.
Check it out! https://gist.github.com/tmartinx/d36536b7b62a48f859c2
Best!
Thiago
On 20 March
Hello Giuseppe,
I am not sure which Hypervisor you are using, but it seems that it is not
KVM which would be the reason why only partial information is collected.
At this time, KVM is the only fully instrumented Hypervisor, even though
we would really welcome patches from users of other
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. In
this regard, I can share information regarding what we have
(both on
Ubuntu 12.04). I couldn't get ceilometer to fetch these data for me and I read
healthnmon is meant for this purpose. Please correct me if I am wrong.
--
Thanks and regards,
Jobin Raju George
Third Year, Information Technology
College of Engineering Pune
Alternate e-mail
', 'Ceilometer', 'Documentation',
'Infrastructure', 'QA', 'Oslo', 'Trove' and 'Ironic'. Those programs
should retroactively submit a mission statement and initial lead
designation, if they don't have one already.
The TC asks that the chair modifies the charter accordingly, including
replacing the word
/: OpenStack Metering Using
Ceilometer
http://www.mirantis.com/blog/openstack-metering-using-ceilometer/
* By Michael Still http://www.stillhq.com/: Nova database continuous
integration http://www.stillhq.com/openstack/15.html
* By Sébastien Han http://sebastien-han.fr/: OpenStack
Hey!
I am trying to get the meters from ceilometer programmatically using java
with the help of the SDK's provided by openstack.
While trying to execute the command mvn clean install or mvn clean install
assembly:assembly, it is asking me for a gpg passphrase. Which passphrase
is it talking
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 with metadata.size=0.
GET
On 12/07/13 11:33 +0200, Julien Danjou wrote:
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 with
, there has been no
short-term plan for kwapi to monitor the energy consumption of the VM.
BR,
Simon
Le 25/07/2013 09:26, Narayanan, Krishnaprasad a écrit :
Hallo Stackers,
This is regarding the power measurement for VMs running in OpenStack.
On the web I found that, Ceilometer has Kwapi that measures
'/var/lib/jenkins/www/apt/dists/trusty-icehouse/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2014.1+git201401220630~trusty-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer/ceilometer-agent-compute_2014.1
'/var/lib/jenkins/www/apt/dists/trusty-icehouse/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/trusty-icehouse/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2014.1+git201402101937~trusty
ase.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2014.1+git201402211001~trusty-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer/ceilometer-agent-compute_2014.1+git201402211001~trusty-0ubuntu1_all.debdeleting and forget
'/var/lib/jenkins/www/apt/dists/trusty-icehouse/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2014.1+git201404011001~trusty-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer/ceilometer-agent-compute_2014.1
' (uncompressed,gzipped)Successfully created '/var/lib/jenkins/www/apt/dists/trusty-icehouse/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/trusty-icehouse/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent
/Packages' (uncompressed,gzipped)Successfully created '/var/lib/jenkins/www/apt/dists/precise-icehouse/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/precise-icehouse/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent
? 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:
Quantum, cinder, and ceilometer get
Let's imagine that the service that launch instances can tag the
instance with:
a) a common service identifier (constant)
b) a uuid unique for each Unit of the service
such as constant:uuid
If that tag is passed onto the events which ceilometer stores in its
entirety as meta, I do not see what
can tag the
instance with:
a) a common service identifier (constant)
b) a uuid unique for each Unit of the service
such as constant:uuid
If that tag is passed onto the events which ceilometer stores in its
entirety as meta, I do not see what the difficulty would be for the
rating engine to be able
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 are a few requirements that I would consider
important for the queue to support
of details from the ceilometer API and
storing them in the billing system using a batch job, rather than trying
to ensure that the billing database performs well enough to record the
information in real time. My goal is to not have to change the billing
system at all.
That's good information
and dhellmann opened a bunch of bugs on Launchpad to track
things https://bugs.launchpad.net/ceilometer (jd___, 16:03:21)
* ACTION: dhellmann to report on outcome of demo at DreamHost
(dhellmann, 16:07:44)
* ACTION: dhellmann to report on outcome of demo at DreamHost (jd___,
16:07:58)
* API
nd how you're implementing things on the other sides (consistency where practical/possible). Also, it sort of depends on the architecture and use model details of Ceilometer, which I hate to admit but I'm not really up to speed on. My first reaction/thought is the best most appropriate place t
for a certain amount of time, but the *rate* for
charging for that time would depend on where it is. A representative from
HP requested the same thing in ceilometer, and we may use it at DreamHost,
too, eventually.
I totally agree with you, Doug. I'm just saying that's it's not *only* a
metadata. The zone
this. The telco industry calls the
tool handling this a rating engine (what transforms metering into line
items of a bill) and I intentionally proposed since the beginning that
Ceilometer should not be a rating engine.
We can hope that our current API will be able to evolve to simplify
rating engines
On Wed, Sep 05 2012, Thomas Goirand wrote:
Hi Thomas,
There may have been some other contributors (especially Debconf
translations), but that's the main team. I'm not sure if Julien still
wants to get involved in the Debian packaging of Openstack, since he is
busy on the Ceilometer project
On Wed, Oct 24 2012, Dan Dyer wrote:
Use Case 1
Service Owned Instances
There are a set of use cases where a service is acting on behalf of a user,
the service is the owner of the VM but billing needs to be attributed to the
end user of the system.This scenario drives two requirements:
1.
I think a good deal of ceilometer's messaging and event tracking could
additionally be used for event audit logging.
-Matt
On Wed, Oct 24, 2012 at 2:35 PM, Julien Danjou jul...@danjou.info wrote:
On Wed, Oct 24 2012, Dan Dyer wrote:
Use Case 1
Service Owned Instances
There are a set of
On 25/10/12 17:04 -0400, Doug Hellmann wrote:
On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote:
On Thu, Oct 25 2012, Doug Hellmann wrote:
That would be one way, but adding dimensions to the meters also makes
sense because it reduces the need to collect the data more
On Oct 25, 2012, at 6:05 PM, Angus Salkeld asalk...@redhat.com wrote:
On 25/10/12 17:04 -0400, Doug Hellmann wrote:
On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou jul...@danjou.info wrote:
On Thu, Oct 25 2012, Doug Hellmann wrote:
That would be one way, but adding dimensions to the
spec files.
Some reviews have already been opened on the topic (admittedly before we
discovered the real issue). Given the different outcome of each review
it seems that not everybody is aware that setuptools_git is used or of
what it does.
https://review.openstack.org/#/c/17122/ (ceilometer
status.
[1] http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee
* We started the end-of-cycle graduation review for Heat and Ceilometer,
covering statements of readiness and release process alignment. This
review will continue next week.
See details and full logs at:
http
For those of you following at home, this means we are about to have 10
(ten) different simultaneous elections. If you aren't following at home,
the following projects are electing PTLs right now:
Ceilometer
Cinder
Glance
Heat
Horizon
Keystone
Nova
Oslo
Quantum
Swift
After that, the following will happen
Dear List,
i got stuck with a setup of openstack grizzly. This setup consists of:
- swift proxy 1.0.8.1
- swift storage nodes 1.0.8.1
- keystone
- ceilometer
I kept browsing the web and reading openstack docs for days now and
can't just get it working right. Because of openstacks diversity
*, on *both* controller *AND* compute
nodes! Take a look! I didn't touch the /etc/sysctl.conf file and it is
working!
I'll ask for the help of this community to finish my guide.
On my `TODO list' I have: enable Metadata, Spice and Ceilometer.
Volunteers?!
Best!
Thiago
On 20 March 2013 19
:
- the transition from our own CloudWatch-lite alarming to ceilometer
might be messy - there might be a limit to how much we can mitigate the pain
- it seems reasonable for latest heat to depend on the latest released
client libs. Any regressions involving recent client libs running on
older APIs probably need
Hi Julien
Thank you for your response.
Do you mean removing the keystone endpoint for glance and creating a new
one without the /v2 number?
This is my service and endpoint list, if you don't mind to check it :)
root@control: keystone service-list
-error/but
with no response yet. Hope you find the solution for that ;-)
On Fri, Jun 28, 2013 at 10:24 PM, Claudio Marques clau...@onesource.ptwrote:
Hi Stacker's!
I have already ceilometer installed and fully functional on my 3 node
Grizzly architecture, but I need to get more info from the VMs
, 2013 at 10:24 PM, Claudio Marques clau...@onesource.pt wrote:
Hi Stacker's!
I have already ceilometer installed and fully functional on my 3 node Grizzly
architecture, but I need to get more info from the VMs that I have installed.
So I am trying to install healthnmon on my controller node
Unsubscribe
On Fri, Jul 12, 2013 at 6:55 AM, Angus Salkeld asalk...@redhat.com wrote:
On 12/07/13 11:33 +0200, Julien Danjou wrote:
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
Ceilometer Project
http://www.mirantis.com/blog/openstack-project-technical-lead-interview-series-5-julien-danjou-openstack-ceilometer-project/
* Three Years and Some with OpenStack
https://blog.hpcloud.com/three-years-and-some-openstack
* Quality Of Service In OpenStack
https
Havana-1 development milestone available
http://lists.openstack.org/pipermail/openstack-announce/2013-May/000107.html
The first milestone of the Havana development cycle, havana-1? is now
available for Keystone, Glance, Nova, Horizon, Networking, Cinder,
Ceilometer, and Heat
on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesImported Translations from Transifexby openstack-infraeditceilometer/locale/en_AU/LC_MESSAGES/ceilometer-log-error.poeditceilometer/locale/it/LC_MESSAGES/ceilometer-log-info.poaddceilometer/locale/en_GB
-builderHealth ReportWDescriptionScoreBuild stability: 3 out of the last 5 builds failed.40Changesadd sahara and heat eventsby gordeditetc/ceilometer/event_definitions.yaml[MongoDB] Fix bug with bad chars in metadatas keysby idegtiaroveditceilometer/storage/impl_mongodb.pyeditceilometer/storage/mongo
/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/precise-grizzly/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2013.1+git201301311431~precise-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer
/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/raring-grizzly/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/c/ceilometer/ceilometer-agent-central_2013.1+git201301311431~raring-0ubuntu1_all.debdeleting and forgetting pool/main/c/ceilometer
-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesUse console scripts for ceilometer-collectorby julieneditsetup.cfgedittox.inieditdoc/source/install/manual.rsteditceilometer/collector/service.pydeletebin/ceilometer-collectorMove os_* options
://review.openstack.org/#/admin/groups/83,members, Neutron
https://review.openstack.org/#/admin/groups/38,members, Ceilometer
https://review.openstack.org/#/admin/groups/107,members, Heat
https://review.openstack.org/#/admin/groups/114,members and OpenStack
Doc https://review.openstack.org/#/admin/groups/30
I just upload a video that shows the way i manage the billing described in
my previous mail in order to clarify:
http://youtu.be/3A1SdZS9Iak
Data is gathered and correlated in a own metering agent that i want to
conform with the ceilometer spec.
Data is submited to the billing system
On Fri, May 18, 2012 at 4:42 AM, Nick Barcet nick.bar...@canonical.comwrote:
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
iPad
On May 18, 2012, at 7:26, Doug Hellmann doug.hellm...@dreamhost.com wrote:
On Fri, May 18, 2012 at 4:42 AM, Nick Barcet nick.bar...@canonical.com
wrote:
Hello everyone,
Next week's irc meeting will have for goal to choose a reference
messaging queue service for the ceilometer project
:
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
layer on top of it. Notifications
and other simple messages (such as meter data for ceilometer) would use the
lower layer, and communication that truly works like RPC could use the
higher level API. We should be able to build an agnostic RPC layer that
uses the messaging driver, instead of having
to abstract the messaging layer out of the existing nova RPC
library and then build a compatible RPC layer on top of it. Notifications
and other simple messages (such as meter data for ceilometer) would use the
lower layer, and communication that truly works like RPC could use the
higher level API
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
Well, this seems a bit inelegant to me to have collectors to additional
lookup
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
Well, this seems a bit inelegant to me to have collectors to additional
lookup in an external DB where
the same thing in ceilometer, and we may use it at DreamHost,
too, eventually.
That only solves part of the problem, though. As a provider I may want to
charge different flat rates for the amount of RAM being used. For
example,
1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when
On 06/29/2012 03:04 PM, Doug Hellmann wrote:
[..]
My conclusion from all of this (over-)thinking is that the ceilometer
API should assume the simple case and ignore the metadata changes when
computing the sum or maximum value for a counter over a range of time.
More complex processing
On Wed, Jul 4, 2012 at 1:52 PM, Nick Barcet nick.bar...@canonical.comwrote:
On 06/29/2012 03:04 PM, Doug Hellmann wrote:
[..]
My conclusion from all of this (over-)thinking is that the ceilometer
API should assume the simple case and ignore the metadata changes when
computing the sum
tests. In ceilometer we've pegged our
pep8 tests to 1.1.
Doug
[1]
https://github.com/jcrocholl/pep8/commit/b9f72b16011aac981ce9e3a47fd0ffb1d3d2e085
Kind Regards,
Dave Walker dave.wal...@canonical.com
Engineering Manager,
Ubuntu Server Infrastructure
translations), but that's the main team. I'm not sure if Julien still
wants to get involved in the Debian packaging of Openstack, since he is
busy on the Ceilometer project.
Well, I'm still interested, but don't have any direct use of them as of
today, and have other things to do as you stated, so I'm
I don't think its just a matter of adding more meters or events for a
couple of reasons:
1. In many cases the metadata I am referring to comes from a different
source than the base usage data. Nova is still emitting its normal
events, but we get the service/user mapping from a different source.
). Given the different outcome
of each review it seems that not everybody is aware that
setuptools_git is used or of what it does.
https://review.openstack.org/#/c/17122/ (ceilometer) - this one
got accepted before we knew what was going on
https://review.openstack.org/#/c/17347/ (cinder
501 - 600 of 1811 matches
Mail list logo
