Re: [openstack-dev] [ceilometer][oslo.cache][oslo] ceilometer fails to publish to gnocchi

On 11/6/18 3:25 AM, Eyal B wrote: Hi, Because of this fix https://review.openstack.org/#/c/611369/ ceilometer which uses oslo.cache for redis fails to publish to gnocchi see this log:

[openstack-dev] [ceilometer][oslo.cache] ceilometer fails to publish to gnocchi

Hi, Because of this fix https://review.openstack.org/#/c/611369/ ceilometer which uses oslo.cache for redis fails to publish to gnocchi see this log:

[openstack-dev] ceilometer-powervm 7.0.0.0rc1 (rocky)

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this

Re: [openstack-dev] [ceilometer][panko][pike] elasticsearch integration

>>>> File "/opt/ceilometer/lib/python3.5/site-packages/tenacity/__init__.py", line 217, in iter 2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline >>>>> six.raise_from(RetryError(fut), fut.exception()) 2018-06-20 07:06:11.537 24 TRACE ceilometer.pipeline

[openstack-dev] [ceilometer][panko][pike] elasticsearch integration

Hello, I'm trying to run ceilometer with panko publishers in pike release and when I run the ceilometer-agent-notification I get a trace complaining about NoSuchOptError, but without the actual parameter that is missing (see trace below). I have configured panko.conf with the following:

[openstack-dev] [ceilometer] Ceilometer-file-publisher-compression-csv-format

Submitted the following review on April 19, https://review.openstack.org/#/c/562768/ Would like to know who else could be on the reviewer list and anything else for the next step? Thanks. Louie __ OpenStack Development

Re: [openstack-dev] [ceilometer] [gnocchi] keystone verification failed.

On Tue, Mar 20 2018, __ mango. wrote: > hi， > I have a question about the validation of gnocchi keystone. > I run the following command, but it is not successful.(api.auth_mode :basic, > basic mode can be > # gnocchi status --debug > REQ: curl -g -i -X GET

[openstack-dev] [ceilometer] [gnocchi] keystone verification failed.

hi?? I have a question about the validation of gnocchi keystone. I run the following command, but it is not successful.(api.auth_mode :basic, basic mode can be # gnocchi status --debug REQ: curl -g -i -X GET http://localhost:8041/v1/status?details=False -H "Authorization:

[openstack-dev] [ceilometer][gnocchi]-gnocchi installation failed.

hi?? I refer to: https://docs.openstack.org/ceilometer/pike/install/install-base-ubuntu.html to install gnocchi, Operation (apt-get installed gnocchi-api gnocchi-gnocchiclient), When I tried to launch the gnocc-api, I got the message. No gnocchi- API starts. Service :gnocchi-api unit. The

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

hey Dan, On 2018-01-11 06:05 PM, Daniel Dyer wrote: > My understanding was that the API is not officially deprecated until queens. > Is this not the case? not quite. we removed the API permanently in queens. it was actually deprecated back in 2016[1] officially. we've

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On Thu, Jan 11, 2018 at 3:05 PM, Daniel Dyer wrote: > My understanding was that the API is not officially deprecated until queens. > Is this not the case? https://docs.openstack.org/releasenotes/ceilometer/ocata.html#deprecation-notes

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

Gordon, My understanding was that the API is not officially deprecated until queens. Is this not the case? Dan > On Jan 11, 2018, at 7:05 AM, gordon chung wrote: > > > > On 2018-01-11 01:48 AM, Thomas Bechtold wrote: >> >> It was at lease for openSUSE: >>

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 2018-01-11 01:48 AM, Thomas Bechtold wrote: > > It was at lease for openSUSE: > https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer ah, maybe just centos then... or i'm not searching the correct place. :) -- gord

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 2018-01-11 07:48, Thomas Bechtold wrote: > Hi, > > On 11.01.2018 01:18, gordon chung wrote: >> >> >> On 2018-01-10 06:44 PM, Doug Hellmann wrote: It's worth pointing out that openstacksdk has ceilometer REST API support in it, although it is special-cased since ceilometer was

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

Hi, On 11.01.2018 01:18, gordon chung wrote: On 2018-01-10 06:44 PM, Doug Hellmann wrote: It's worth pointing out that openstacksdk has ceilometer REST API support in it, although it is special-cased since ceilometer was retired before we even made the service-types-authority: so

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

I'm favor of dropping Ceilometer API support in the SDK if we claim 1.0 will support Queens and beyond. If the SDK has to support previous versions (Pike, Ocata, etc), then we should warn the SDK users that Ceilometer API has been deprecated and removed so depending on your cloud provider the SDK

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

Excerpts from Monty Taylor's message of 2018-01-10 18:08:52 -0600: > On 01/10/2018 05:44 PM, Doug Hellmann wrote: > > Excerpts from Monty Taylor's message of 2018-01-10 17:40:28 -0600: > >> On 01/10/2018 04:10 PM, Jon Schlueter wrote: > >>> On Thu, Nov 23, 2017 at 4:12 PM, gordon chung

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 2018-01-10 06:44 PM, Doug Hellmann wrote: >> It's worth pointing out that openstacksdk has ceilometer REST API >> support in it, although it is special-cased since ceilometer was retired >> before we even made the service-types-authority: so ceilometer's REST API does not exist anymore. i

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 01/10/2018 05:44 PM, Doug Hellmann wrote: Excerpts from Monty Taylor's message of 2018-01-10 17:40:28 -0600: On 01/10/2018 04:10 PM, Jon Schlueter wrote: On Thu, Nov 23, 2017 at 4:12 PM, gordon chung wrote: On 2017-11-22 04:18 AM, Julien Danjou wrote: Hi, Now that the

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

Excerpts from Monty Taylor's message of 2018-01-10 17:40:28 -0600: > On 01/10/2018 04:10 PM, Jon Schlueter wrote: > > On Thu, Nov 23, 2017 at 4:12 PM, gordon chung wrote: > >> > >> > >> > >> On 2017-11-22 04:18 AM, Julien Danjou wrote: > >>> Hi, > >>> > >>> Now that the Ceilometer

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 01/10/2018 04:10 PM, Jon Schlueter wrote: On Thu, Nov 23, 2017 at 4:12 PM, gordon chung wrote: On 2017-11-22 04:18 AM, Julien Danjou wrote: Hi, Now that the Ceilometer API is gone, we really don't need ceilometerclient anymore. I've proposed a set of patches to retire it:

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

Excerpts from gordon chung's message of 2018-01-10 23:28:05 +: > > On 2018-01-10 05:10 PM, Jon Schlueter wrote: > > I would think that a discussion around retiring a project should also > > include at least enumerating > > which projects are currently consuming it [5]. That way a little bit

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 2018-01-10 05:10 PM, Jon Schlueter wrote: > I would think that a discussion around retiring a project should also > include at least enumerating > which projects are currently consuming it [5]. That way a little bit > of pressure on those consumers > can be exerted to evaluate their usage of

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On Thu, Nov 23, 2017 at 4:12 PM, gordon chung wrote: > > > > On 2017-11-22 04:18 AM, Julien Danjou wrote: > > Hi, > > > > Now that the Ceilometer API is gone, we really don't need > > ceilometerclient anymore. I've proposed a set of patches to retire it: > > > >

Re: [openstack-dev] [ceilometer] the cpu util

2017-12-20 23:48 GMT+08:00 gordon chung : > > > On 2017-12-20 10:06 AM, Jaze Lee wrote: >> Yes, i notice it. But when there will be vcpu.*.time? Which libvirt version? >> We use libvirt 3.2.0 and it does not have vcpu.*.time, so it will go >> to fall back. > > i have: > > virsh #

Re: [openstack-dev] [ceilometer] the cpu util

On 2017-12-20 10:06 AM, Jaze Lee wrote: > Yes, i notice it. But when there will be vcpu.*.time? Which libvirt version? > We use libvirt 3.2.0 and it does not have vcpu.*.time, so it will go > to fall back. i have: virsh # version Compiled against library: libvirt 3.2.0 Using library: libvirt

Re: [openstack-dev] [ceilometer] the cpu util

2017-12-20 22:29 GMT+08:00 gordon chung : > > > On 2017-12-20 03:14 AM, Jaze Lee wrote: >> Hello, >> We use ceilometer newton, and also master calculates cpu same as newton. >> It is in >>

Re: [openstack-dev] [ceilometer] the cpu util

On 2017-12-20 03:14 AM, Jaze Lee wrote: > Hello, > We use ceilometer newton, and also master calculates cpu same as newton. > It is in > https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183 > > I test with a two vcpu vm, and find

[openstack-dev] [ceilometer] the cpu util

Hello, We use ceilometer newton, and also master calculates cpu same as newton. It is in https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183 I test with a two vcpu vm, and find using this method as line 183 we can not get cpu util 100,

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-18 10:28 AM, Jaze Lee wrote: > Is there some document about how to use rate? I do not find any about it > Thanks. > https://gnocchi.xyz/rest.html#archive-policy its' similar to how other aggregates are defined. it's just not part of default aggregation methods. -- gord

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-18 21:17 GMT+08:00 gordon chung : > > > On 2017-12-17 11:08 PM, Jaze Lee wrote: >> Hello. >> >> 2017-12-16 9:30 GMT+08:00 Jaze Lee : >>> 2017-12-15 23:17 GMT+08:00 gordon chung : On 2017-12-14 10:38 PM, Jaze Lee wrote: >

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-17 11:08 PM, Jaze Lee wrote: > Hello. > > 2017-12-16 9:30 GMT+08:00 Jaze Lee : >> 2017-12-15 23:17 GMT+08:00 gordon chung : >>> >>> >>> On 2017-12-14 10:38 PM, Jaze Lee wrote: It sounds like great. When the gnocchi can be ready to do

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

Hello. 2017-12-16 9:30 GMT+08:00 Jaze Lee : > 2017-12-15 23:17 GMT+08:00 gordon chung : >> >> >> On 2017-12-14 10:38 PM, Jaze Lee wrote: >>> It sounds like great. When the gnocchi can be ready to do transformer's >>> work? >>> If it takes long time, we have

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-15 23:17 GMT+08:00 gordon chung : > > > On 2017-12-14 10:38 PM, Jaze Lee wrote: >> It sounds like great. When the gnocchi can be ready to do transformer's work? >> If it takes long time, we have to move to compute temporarily. > > it already exists in gnocchi 4.1+. we just

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-14 10:38 PM, Jaze Lee wrote: > It sounds like great. When the gnocchi can be ready to do transformer's work? > If it takes long time, we have to move to compute temporarily. it already exists in gnocchi 4.1+. we just need to change the workflow in ceilometer so it integrates with

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-14 22:34 GMT+08:00 gordon chung : > > > On 2017-12-14 04:14 AM, Jaze Lee wrote: >>> The plan is to actually make the TSDB (Gnocchi) do that job for us. >> What ？ >> Is there some detail on this plan ? If it did, then we do not need >> workload partition, and scale with agent

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-14 04:14 AM, Jaze Lee wrote: >> The plan is to actually make the TSDB (Gnocchi) do that job for us. > What ？ > Is there some detail on this plan ? If it did, then we do not need > workload partition, and scale with agent process happily > Gnocchi can capture rate information

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-14 16:58 GMT+08:00 Julien Danjou : > On Thu, Dec 14 2017, Jaze Lee wrote: > >> Oh, sorry. I found libvirt can not get cpu.util, cpu.delta, and >> network/disk rate info directly >> from inspector. So i mean, we can move this into compute pollster. >> Before it sends to

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On Thu, Dec 14 2017, Jaze Lee wrote: > Oh, sorry. I found libvirt can not get cpu.util, cpu.delta, and > network/disk rate info directly > from inspector. So i mean, we can move this into compute pollster. > Before it sends to notifications.sample, > transform it. Then we can scale notification

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-13 21:16 GMT+08:00 gordon chung : > > > On 2017-12-13 01:52 AM, Jaze Lee wrote: >> Hello, >> >> What about move transformer to compute pollster? If we do this, we >> do not need >> transformer any more > > sorry, i don't understand. if you move the transformer,

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-13 01:52 AM, Jaze Lee wrote: > Hello, > > What about move transformer to compute pollster? If we do this, we > do not need > transformer any more sorry, i don't understand. if you move the transformer, you still have a transformer. -- gord

[openstack-dev] [ceilometer] about add transformer into libvirt

Hello, What about move transformer to compute pollster? If we do this, we do not need transformer any more -- 谦谦君子 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [ceilometer][gnocchi] some code not very understood

On Thu, Dec 07 2017, Jaze Lee wrote: > Yes. I misunderstand here. If there any exception in gnocchi api, it > won't store any measures. > Just after all resource, and all metrics are there, gnocchi will store > those measures. Am i right? Yes. -- Julien Danjou # Free Software hacker #

Re: [openstack-dev] [ceilometer][gnocchi] some code not very understood

2017-12-07 16:36 GMT+08:00 Julien Danjou : > On Thu, Dec 07 2017, Jaze Lee wrote: > >>I think at line 416, we should remove some measures that already post at >> 390. >>Or may be i miss something? >> >> >>

Re: [openstack-dev] [ceilometer][gnocchi] some code not very understood

On Thu, Dec 07 2017, Jaze Lee wrote: >I think at line 416, we should remove some measures that already post at > 390. >Or may be i miss something? > > > https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/gnocchi.py#L416 The code at L416 is only executed if L390

[openstack-dev] [ceilometer][gnocchi] some code not very understood

Hello, I think at line 416, we should remove some measures that already post at 390. Or may be i miss something? https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/gnocchi.py#L416 -- 谦谦君子

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On Mon, Dec 04 2017, gordon chung wrote: > but at the end of the day, are you building for reality or for some > personal ideal scenario? :p Haha, you know that if I was building for an ideal scenario, most of Ceilometer would probably have never existed in this way. Half of Ceilometer is

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On 2017-12-04 08:53 AM, Julien Danjou wrote: > Which is usually a problem because of the APIs, not Ceilometer. They're > sometimes utterly slow for simple things and other times don't offer a > way to retrieve what Ceilometer needs in a batch-y way. > >> in general, there's a preference that

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

Either way step one is to propose the code for a better replacement. I doubt you'll get much opposition to that. No need to propose removing the old code immediately, it can live in parallel for as long as needed. On 4 December 2017 at 15:14, Jaze Lee wrote: > 2017-12-04

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On 2017-12-04 09:52 AM, Jaze Lee wrote: > 2017-12-04 20:53 GMT+08:00 gordon chung : >> i'm curious. how does a "simple tcp socket" protect ou against > > I do not quite understand 'protect ou against'. > The tcp socket means it is a client to send samples to gnocchi tcp server. >

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 19:36 GMT+08:00 Duncan Thomas : > Why remove something that works and people are using? Yes, removing it will make noise. > > If polster can be set up to do the job, then great, but there's no > rush to remove the existing infrastructure; this is one case

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 20:57 GMT+08:00 gordon chung : > > > On 2017-12-04 05:30 AM, Jaze Lee wrote: >> Right now,we can get volume from central pollester. Then i think >> may be we can drop cinder volume usage. > > which metrics are you referring to? just for the record, except for >

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

2017-12-04 20:53 GMT+08:00 gordon chung : > > > On 2017-12-03 10:41 PM, Jaze Lee wrote: >> So what about to remove gnocchi http, and add a simple tcp socket, which >> will send to gnocchi tcp server(which will also be created.). > > i'm curious. how does a "simple tcp socket"

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On Mon, Dec 04 2017, gordon chung wrote: > On 2017-12-04 05:30 AM, Jaze Lee wrote: >> Right now,we can get volume from central pollester. Then i think >> may be we can drop cinder volume usage. > > which metrics are you referring to? just for the record, except for > libvirt stats, the

Re: [openstack-dev] [ceilometer] about workload partition

On 2017-12-03 10:30 PM, 李田清 wrote: > > > On 2017-12-01 05:03 AM, 李田清 wrote: > >> Hello, > >>       we test workload partition, and find it's much slower than not > >> using it. > >>       After some review, we find that, after get samples from > >> notifications.sample > >>       

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On 2017-12-04 05:30 AM, Jaze Lee wrote: > Right now,we can get volume from central pollester. Then i think > may be we can drop cinder volume usage. which metrics are you referring to? just for the record, except for libvirt stats, the polling done by ceilometer is against the API which

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On 2017-12-03 10:41 PM, Jaze Lee wrote: > So what about to remove gnocchi http, and add a simple tcp socket, which > will send to gnocchi tcp server(which will also be created.). i'm curious. how does a "simple tcp socket" protect ou against > anyone can update gnocchi database which is not

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

Why remove something that works and people are using? If polster can be set up to do the job, then great, but there's no rush to remove the existing infrastructure; this is one case where duplication is very, very cheap. On 4 December 2017 at 10:30, Jaze Lee wrote: > Hello, >

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

2017-12-04 18:41 GMT+08:00 Julien Danjou : > On Mon, Dec 04 2017, Jaze Lee wrote: > >> Right now, the dispatch will cost much time in http request. And >> keystone auth token cost much time. Although we can configure it to >> noauth, then anyone can update gnocchi database

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On Mon, Dec 04 2017, Jaze Lee wrote: > Right now, the dispatch will cost much time in http request. And > keystone auth token cost much time. Although we can configure it to > noauth, then anyone can update gnocchi database which is not we want. > So what about to remove gnocchi http,

[openstack-dev] [ceilometer][cinder]about cinder volume usage

Hello, Right now,we can get volume from central pollester. Then i think may be we can drop cinder volume usage. Cinder volume usage, do not like nova usage which is in nova compute. It is a cmd. And should put it in cron. This will cause more work in devops. If ceilometer pollester can

[openstack-dev] [ceilometer] remove gnocchi http interface?

Hello, Right now, the dispatch will cost much time in http request. And keystone auth token cost much time. Although we can configure it to noauth, then anyone can update gnocchi database which is not we want. So what about to remove gnocchi http, and add a simple tcp socket, which will

Re: [openstack-dev] [ceilometer] about workload partition

On 2017-12-01 05:03 AM, 李田清 wrote: >> Hello, >> we test workload partition, and find it's much slower than not >> using it. >> After some review, we find that, after get samples from >> notifications.sample >> ceilometer unpacks them and sends them one by one to the pipe >>

Re: [openstack-dev] [ceilometer] about workload partition

On 2017-12-01 05:03 AM, 李田清 wrote: > Hello, >      we test workload partition, and find it's much slower than not > using it. >      After some review, we find that, after get samples from > notifications.sample >      ceilometer unpacks them and sends them one by one to the pipe >      

[openstack-dev] [ceilometer] about workload partition

Hello, we test workload partition, and find it's much slower than not using it. After some review, we find that, after get samples from notifications.sample ceilometer unpacks them and sends them one by one to the pipe ceilometer.pipe.*, this will make the consumer slow.

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

On 2017-11-22 04:18 AM, Julien Danjou wrote: > Hi, > > Now that the Ceilometer API is gone, we really don't need > ceilometerclient anymore. I've proposed a set of patches to retire it: > >https://review.openstack.org/#/c/522183/ > just for reference, we had a super short discussion on

[openstack-dev] [ceilometer] Retiring ceilometerclient

Hi, Now that the Ceilometer API is gone, we really don't need ceilometerclient anymore. I've proposed a set of patches to retire it: https://review.openstack.org/#/c/522183/ -- Julien Danjou ;; Free Software hacker ;; https://julien.danjou.info signature.asc Description: PGP signature

Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

On 2017-11-16 03:29 PM, Waines, Greg wrote: > Ok ... if you don’t mind, i might create a blueprint anyways ... for > traceability and documentation purposes. > > We/WindRiver tracks both blueprints and code submissions that we have > worked on, as an indication of our upstream contributions.

Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

Reply-To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Date: Thursday, November 16, 2017 at 2:59 PM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file

Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

On 2017-11-16 02:48 PM, Waines, Greg wrote: > Cool ... i will go ahead and submit a blueprint for these. just an fyi, we don't use blueprints in Telemetry projects. just submit the code :) if there's many alternatives to the solution or if it's a something controversial, we usually discuss

Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

Reply-To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Date: Thursday, November 16, 2017 at 1:49 PM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file

Re: [openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

On 2017-11-16 12:44 PM, Waines, Greg wrote: > > 1.Compression of files (within file rotation) to minimize disk usage and > minimize bandwidth in FTP-ing these files off server > > oi.e. as part of file rotation, the newly rotated file would be gzip’d > to compress the file > > othis would

[openstack-dev] [ceilometer] Blueprint proposals for 'file' publisher: Compression and CSV file format

Hey there, I am looking for some feedback on 2x enhancement / blueprint proposals for the ‘file’ publisher in ceilometer. i.e. https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/file.py Are the Ceilometer owners open to looking at blueprints for the following ? 1.

[openstack-dev] [ceilometer][oslo_messaging] Random Connection reset by peer

Hello, I test ceilometer agent notification workload partition. I found it is too fragile. The load is 1k cirrors vm. I make processing queue to 4 and workers to 1. I can sure the network is ok. But in the ceilometer agent notification log i see this

Re: [openstack-dev] [ceilometer] the workload partition willcauseconsumer disappeared

I use 5.10.2 > I test newton 5.10.2, and in ceilometer agent notification, the log shows > 2017-10-21 03:33:19.779 225636 ERROR root [-] Unexpected exception > occurred 60 time(s)... retrying. > 2017-10-21 03:33:19.779 225636 ERROR root Traceback (most recent call last): > 2017-10-21

Re: [openstack-dev] [ceilometer] the workload partition will causeconsumer disappeared

On 25/10/17 03:25 AM, 李田清 wrote: > I test newton 5.10.2, and in ceilometer agent notification, the log shows > 2017-10-21 03:33:19.779 225636 ERROR root [-] Unexpected exception > occurred 60 time(s)... retrying. > 2017-10-21 03:33:19.779 225636 ERROR root Traceback (most recent call last): >

Re: [openstack-dev] [ceilometer] the workload partition will causeconsumer disappeared

On 2017-10-23 09:57 PM, 李田清 wrote: > We test ceilometer workload partition, and find even with one > rabbitmq server, the ceilometer-pipe > will lost its consumers. Does anyone know this? > I configure, batch_size =1, batch_timeout =1, > and pipeline_processing_queues = 1. >

Re: [openstack-dev] [ceilometer] the workload partition will cause consumer disappeared

On 2017-10-23 09:57 PM, 李田清 wrote: >      We test ceilometer workload partition, and find even with one > rabbitmq server, the ceilometer-pipe >      will lost its consumers. Does anyone know this? >      I configure, batch_size =1, batch_timeout =1, > and pipeline_processing_queues = 1. >

[openstack-dev] [ceilometer] the workload partition will cause consumer disappeared

Hello, We test ceilometer workload partition, and find even with one rabbitmq server, the ceilometer-pipe will lost its consumers. Does anyone know this? I configure, batch_size =1, batch_timeout =1, and pipeline_processing_queues = 1. If anyone know this, please point it

Re: [openstack-dev] [ceilometer] Time for API removal?

adding ops list On 2017-10-13 11:01 AM, Julien Danjou wrote: > Hey there, > > We deprecated the Ceilometer API last year (Ocata) and our latest user > survery shows than more than 50% of our users are now using Gnocchi or > something else than the old deprecated storage methods. thanks to all

[openstack-dev] [ceilometer] Time for API removal?

Hey there, We deprecated the Ceilometer API last year (Ocata) and our latest user survery shows than more than 50% of our users are now using Gnocchi or something else than the old deprecated storage methods. I'm starting to think it's time to stop carrying this dead code around. The biggest

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

yana (MFG & Tech) <rajeev.satyanaray...@wipro.com> > *Subject:* ** Newsletter/Marketing email** Re: [openstack-dev] > [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC > > > > ** This mail has been sent from an external source. Treat hyperlinks and > a

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

/Marketing email** Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** Hi Rajeev, The Chain Monitoring is the missing piece in networking-sfc . V

Re: [openstack-dev] [ceilometer]The principle of restrict the scope of returned events

OK，thanks @gord Look forward to other people's suggestion. On Sat, Aug 5, 2017 at 12:12 AM, gordon chung wrote: > hi, > > i think this is best to ask this on mailing list. to be honest, i do not > work on Panko much anymore. feel free to propose something if it doesn't > meet

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

Hi Rajeev, The Chain Monitoring is the missing piece in networking-sfc . Vikram and myself were discussed to introduce "SFC Manager" [1] (basically OAM tool ) few cycle before. It'll continuously monitor an existing SFC chain, when any SF VM goes down or any packet drop. It'll trigger alert and

[openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

Hi Igor/Cathy/Gord, Sorry for the delay in replying. As part of monitoring the SFC, I think maintaining the details of "Number of flows assigned to a given SFC", "Number of packets/bytes dropped/hit due to the policies at each Service Function entry/exit points or for the entire SFC" would be

Re: [openstack-dev] [ceilometer]Understandig ceilometer

Hi Gordon, Thanks for the explanations! Br, György > -Original Message- > From: gordon chung [mailto:g...@live.ca] > Sent: 2017 július 4, kedd 23:58 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [ceilometer]Understandig ceilometer > > >

Re: [openstack-dev] [ceilometer]Understandig ceilometer

On 04/07/17 05:14 AM, Gyorgy Szombathelyi wrote: > - I understand that there is no collector service now. I know the old > pipeline was: compute-agent->notification-agent->collector->storage(gnocchi). > Now I assumed it should be compute-agent->storage(gnocchi). > However I found out it is a

[openstack-dev] [ceilometer]Understandig ceilometer

Hi! I try to dig into the inner workings of ceilometer, and there are things I couldn't figure out: - I understand that there is no collector service now. I know the old pipeline was: compute-agent->notification-agent->collector->storage(gnocchi). Now I assumed it should be

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

Thanks Along and Gordon , after making changes , it works. On Fri, Jun 30, 2017 at 12:02 AM, Along Meng wrote: > Yes， and you need make sure ceilometer-agent-notification and panko was > intalled in a same machine in your environment. > Because ceilometer will load the

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

Yes， and you need make sure ceilometer-agent-notification and panko was intalled in a same machine in your environment. Because ceilometer will load the publisher dispatcher panko from the module panko and use the database url[1] which configured in panko.conf to init the database connection. [1]

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

On 29/06/17 07:24 AM, Yaguang Tang wrote: > sinks: > - name: event_sink > transformers: > triggers: > publishers: > - direct:// > - panko:// the publisher path is only available if you have Pike Panko. you need to either backport[1] or configure your

[openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

Hi all, I am using Ocata Ceilometer Gnocchi with Panko, Panko is configured to use MySQL as backend to store events, I configured Ceilometer event_pipeline.yaml as follow: sinks: - name: event_sink transformers: triggers: publishers: - direct:// -

[openstack-dev] [ceilometer] deprecating pollster-list option

hi, i'm proposing to deprecate/remove pollster-list config option. if you're like me and wondering what this is, we apparently support ability to filter pollsters loaded by polling agent[1]. the reason i'd like to deprecate is because we already have this functionality in the

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

On 25/06/17 08:10 AM, rajeev.satyanaray...@wipro.com wrote: > I am interested to know if there are any meters available for monitoring > SFC through ceilometer, like no.of flows associated with an SFC or > packets in/out for an SFC etc? > > If they are available, please let me know how to

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

questions) Subject: Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC Hi Rajeev, there are no meters as far as I know and I'm not aware of any plans at the moment. What else do you have in mind in terms of monitoring? Best regards, Igor. From

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

-dev@lists.openstack.org Subject: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC Hi All, I am interested to know if there are any meters available for monitoring SFC through ceilometer, like no.of flows associated with an SFC or packets in/out for an SFC etc

[openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

Hi All, I am interested to know if there are any meters available for monitoring SFC through ceilometer, like no.of flows associated with an SFC or packets in/out for an SFC etc? If they are available, please let me know how to configure and use them. If not, are there any plans of providing

Re: [openstack-dev] [Ceilometer]

On 09/05/17 10:08 AM, simona marinova wrote: > The Alarming service doesn't work at this point. For example the > command "ceilometer alarm-list" gives the error: > > you should be using aodhclient if you have aodh. > > Now my biggest concern is that the Alarming service database >

[openstack-dev] [Ceilometer]

Hello, I am working on an Openstack Newton platform and I am currently trying to implement the Telemetry services, Ceilometer and Aodh. I installed and configured Aodh with MySQL first and it worked. Afterwards, I installed Ceilometer following the latest update which includes MongoDB, unlike

  1   2   3   4   5   6   7   8   9   10   >