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

2018-05-14 Thread gordon chung
On 2018-05-14 3:26 PM, Kwan, Louie wrote: > Hi All, > > Any weekly meeting for Telemetry? I would like to discuss what we can do for > the next step for the following review? > > https://review.openstack.org/#/c/562768/ > > Ping in the IRC a few times and please advice the next step. >

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

2018-03-15 Thread gordon chung
On 2018-03-15 5:16 AM, __ mango. wrote: > hi, > The environment variable that you're talking about has been configured > and the error has not gone away. > > I was on OpenStack for the first time, can you be more specific? Thank > you very much. >

Re: [openstack-dev] [tc] [all] TC Report 18-07

2018-02-13 Thread gordon chung
On 2018-02-13 11:31 AM, gordon chung wrote: > > > was there a resolution for this? iiuc, pgsql is not supported by glance > based on: > https://github.com/openstack/glance/commit/f268df1cbc3c356c472ace04bd4f2d4b3da6c026 > err... nevermind. it seems https://github.com/opens

Re: [openstack-dev] [tc] [all] TC Report 18-07

2018-02-13 Thread gordon chung
On 2018-02-13 10:08 AM, Chris Dent wrote: > > # PostgreSQL and Triggers > > Later in the [same > day](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-02-07.log.html#t2018-02-07T17:18:56) > > > there was some discussion about the state of PostgreSQL support and >

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

2018-01-30 Thread gordon chung
On 2018-01-30 10:19 AM, Matt Riedemann wrote: > Gibi's burndown chart is here to see what's remaining: > > http://burndown.peermore.com/nova-notification/ this answer far exceeded my expectations :) thanks! -- gord __

[openstack-dev] [nova][ceilometer] versioned notifications coverage

2018-01-30 Thread gordon chung
hi, we've had an open item to consume versioned notifications in ceilometer. the question that remains is: do all unversioned notifications have a versioned version or are there still some items missing? the blocker for us is that we can't consume both as then we'd end up duplicating data but

Re: [openstack-dev] [tc] [all] TC Report 18-04

2018-01-23 Thread gordon chung
On 2018-01-23 01:40 PM, Chris Dent wrote: > > (Hyperlinkified for your pleasure: > https://anticdent.org/tc-report-18-04.html ) > > When a person is in early adolescence they get cramps in their legs > and call it growing pains. Later, in adulthood, there's a different > kind of pain when the

Re: [openstack-dev] [zuul] Cannot view log outputs in browser

2018-01-23 Thread gordon chung
On 2018-01-23 07:45 AM, Paul Bourke wrote: > Apologies if this has been asked before. It seems as of late (I think > since the roll out of zuul v3, I can't seem to view job outputs directly > in my browser. E.g. when I click link[0], I have to download > 'job-output.txt.gz', unzip it, rename

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

2018-01-11 Thread gordon chung
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

2018-01-11 Thread gordon chung
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

2018-01-10 Thread gordon chung
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

2018-01-10 Thread gordon chung
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] the cpu util

2017-12-20 Thread 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 # version Compiled against library: libvirt 3.2.0 Using library: libvirt

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

2017-12-20 Thread 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 > https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183 > > I test with a two vcpu vm, and find

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

2017-12-18 Thread gordon chung
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 Thread gordon chung
On 2017-12-17 11:08 PM, Jaze Lee wrote: > Hello. > > 2017-12-16 9:30 GMT+08:00 Jaze Lee <jaze...@gmail.com>: >> 2017-12-15 23:17 GMT+08:00 gordon chung <g...@live.ca>: >>> >>> >>> On 2017-12-14 10:38 PM, Jaze Lee wrote: >>

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

2017-12-15 Thread 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 need to change the workflow in ceilometer so it integrates with

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

2017-12-14 Thread 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 process happily > Gnocchi can capture rate information

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

2017-12-13 Thread 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, you still have a transformer. -- gord

[openstack-dev] [cinder][ceilometer] cinder capacity notifications

2017-12-12 Thread gordon chung
hi, i'm attempting to add support for the cinder capacity notifications that were added a while back[1]. adding measurement support in ceilometer is pretty simple where in most cases you just add an entry to a yaml file[2]. the problem i have right now is i have no idea what resource these

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

2017-12-04 Thread gordon chung
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] remove gnocchi http interface?

2017-12-04 Thread gordon chung
On 2017-12-04 09:52 AM, Jaze Lee wrote: > 2017-12-04 20:53 GMT+08:00 gordon chung <g...@live.ca>: >> 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

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

2017-12-04 Thread gordon chung
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

2017-12-04 Thread 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 libvirt stats, the polling done by ceilometer is against the API which

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

2017-12-04 Thread 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" protect ou against > anyone can update gnocchi database which is not

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

2017-12-01 Thread gordon chung
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] [tc] [all] TC Report 48

2017-11-29 Thread gordon chung
On 2017-11-29 12:34 PM, Chris Dent wrote: > Sufficent answer? speaking for myself, yes. -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [tc] [all] TC Report 48

2017-11-29 Thread gordon chung
On 2017-11-29 12:31 PM, Anne Bertucio wrote: > Rereading your question, Gord, the tl;dr of my message is that current > roadmap is not intended to dictate work or what future features should > be—just captures and communicates work already in motion. ah, i see. i was mainly curious to see how

Re: [openstack-dev] [tc] [all] TC Report 48

2017-11-29 Thread gordon chung
On 2017-11-28 11:36 AM, Chris Dent wrote: > * A somewhat bizarre presentation suggesting the Board and the TC >   manage the OpenStack roadmap. There wasn't time to actually discuss >   this as previous topics ran _way_ over, but at a superficial glance >   it appeared to involve a complete

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

2017-11-23 Thread gordon chung
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

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

2017-11-16 Thread gordon chung
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

2017-11-16 Thread gordon chung
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

2017-11-16 Thread gordon chung
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

Re: [openstack-dev] [telemetry] ceilometer-notification restart with no consumers on ceilometer-pipe

2017-11-02 Thread gordon chung
On 17/10/17 11:17 PM, 李田清 wrote: > Hello, > I am testing ceilometer workload partition. And find that if we restart > agent notification, the ceilometer-pip* queue will not have > consumers any more. > Does anyone know this? The pipeline.yaml is > here

Re: [openstack-dev] [all] ujson "drop in" replacement

2017-11-01 Thread gordon chung
On 01/11/17 03:00 PM, Graham Hayes wrote: > There seems to be a lot of "replace oslo.serization / native python json > with UltraJSON (otherwise known as ujson) patches over the last few > weeks. > > We should be careful - it is not a drop in replacement. e.g. - rofl. i guess someone took our

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

2017-10-25 Thread gordon chung
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 cause consumer disappeared

2017-10-24 Thread gordon chung
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] [gnocchi] Redis for storage backend

2017-10-18 Thread gordon chung
On 2017-10-18 12:15 PM, Yaguang Tang wrote: > > We launched 300vms and each vm has about 10 metrics, OpenStack cluster > have 3 controllers and 2 compute nodes(ceph replication is set to 2). seems smaller than my test, i have 20K metrics in my test > > what we want to archive is to make all

[openstack-dev] [telemetry][ceilometer] adding Hanxi Liu as ceilometer core

2017-10-16 Thread gordon chung
hi, i'd like to welcome Hanxi Liu as the newest core member of ceilometer project[1]. Just want to say thanks for the past contributions, for rep'ing us at the PTG, and for being (possibly) the only person on Earth with a Telemetry team sticker on their laptop. look forward to more. :) [1]

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

2017-10-13 Thread gordon chung
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

Re: [openstack-dev] [gnocchi] Redis for storage backend

2017-10-13 Thread gordon chung
On 2017-10-13 03:37 AM, Julien Danjou wrote: > On Fri, Oct 13 2017, Yaguang Tang wrote: > >> I see the latest Gnocchi support using Redis as a storage backend, I am >> testing performance of Redis and Ceph, it seems using Redis as storage >> backend we can achieve more realtime metric >> data,

Re: [openstack-dev] Regarding Horizon panel of Gnoochi/Adoh Services

2017-10-12 Thread gordon chung
On 12/10/17 07:05 AM, Akihiro Motoki wrote: > Horizon supports plugin mechanism and the horizon team encourage > individual project teams > to develop their GUI support under the governance of their project teams. > There are many examples of horizon plugins [1] interesting, didn't know there

Re: [openstack-dev] [panko][ceilometer][keystone] Support X-Is-Admin-Project

2017-09-07 Thread gordon chung
On 2017-09-07 02:15 PM, Innus, Martins wrote: > The fix seems to be something like the attached patch and setting the > appropriate configs in keystone.conf. > > > One curious thing is that with the default keystone config, requests from all > projects have "X-Is-Admin-Project: True” > > If

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

2017-09-05 Thread gordon chung
On 05/09/17 09:27 AM, Jay Pipes wrote: > > Why not sort by created date/timestamp? Wouldn't that give you the same > behaviour (for the most part). we actually do that by default currently. the issue Mikhail ran into was because the timestamp we store is the timestamp of the message, not the

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

2017-09-05 Thread gordon chung
On 04/09/17 11:17 AM, Mikhail Kebich wrote: > Hello Gordon, > > Any feedback? Did you get a chance to take a look at the cursor api prototype? > > Thanks, > Mike > > On Wed, Aug 30, 2017 at 6:00 PM, Mikhail Kebich > <mikhail.keb...@gmail.com> wrote: >>

Re: [openstack-dev] [all] connecting nova notification users and developers

2017-09-05 Thread gordon chung
On 04/09/17 09:55 PM, Lingxian Kong wrote: > ​Hi Gordon, does Aodh rely on Ceilometer to receive events or it could > receive notifications directly from other services?​ yes. Ceilometer normalises the message into something Aodh can understand. (that's how it behaves currently) -- gord

Re: [openstack-dev] [all] connecting nova notification users and developers

2017-09-01 Thread gordon chung
On 2017-08-30 10:30 AM, Balazs Gibizer wrote: > 1) We in the nova developer community would like to see which projects > are using (or planning to use) the nova notification interface. Also we > would like to know if you are using the legacy unversioned notifications > or the new versioned

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

2017-08-30 Thread gordon chung
On 2017-08-30 08:45 AM, Mikhail Kebich wrote: > Assume, that I made a request after events 1, 2, 3 and 4 were added to > the database. After some time events 5, 6, 7, 8 and 9 were added to > the database. I made another request to get the rest of events and > received only events 8, 9 because of

Re: [openstack-dev] [Panko] Ways to go through events in the order they appear in database

2017-08-29 Thread gordon chung
On 2017-08-29 06:28 AM, Mikhail Kebich wrote: > Hello Telemetry Team, > > I see that the Panko API does not provide a way to go through all events > in the order they were stored in database. Panko sorts events by > generated and message_id fields and uses message_id field as a marker > for

Re: [openstack-dev] [Monasca] GridDB repository support

2017-08-28 Thread gordon chung
On 28/08/17 10:32 AM, witold.be...@est.fujitsu.com wrote: > The number looks good but the test you have referenced was performed with the > file storage driver which is not really scalable. It would be great if you > could provide numbers for the Ceph backend. > Please keep us updated. these

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

2017-08-28 Thread gordon chung
> Gaps to be discussed are here: > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if you need storagE) and not Panko. Panko only handles storage of events (more metadata focused data) while

Re: [openstack-dev] About OpenStack's resource limit

2017-08-25 Thread gordon chung
On 2017-08-24 05:20 AM, rk_1218_l...@i.softbank.jp wrote: > Because I want to monitor resource usage (CPU utilization, memory, > ...etc) with OpenStack!! > I have one question. you can monitor resource usage using ceilometer (to generate the metrics) and gnocchi (to store/query metrics). you

Re: [openstack-dev] [release] [telemetry] Ceilometer stable/pike branch outlook

2017-08-18 Thread gordon chung
apologies, I'm currently away on vacation (for a while) we can merge the stable/pike patch as it seems there are others dependent on it. I don't believe it affects us either way. I don't see the auto patch that creates tag so I guess we need to do it via releases project -- gord

Re: [openstack-dev] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

2017-08-08 Thread gordon chung
On 08/08/17 02:17 AM, pearl.dsil...@wipro.com wrote: > I would like to know if there exists support to view the statistics > fetched by gnocchi on Horizon(dashboard). If so, please let me know how > to configure it in Newton release. i don't know if there's plans for this in Horizon. this

Re: [openstack-dev] [heat][ironic][telemetry][dragonflow][freezer][kuryr][manila][mistral][monasca][neutron][ansible][congress][rally][senlin][storlets][zun][docs] repos without signs of migration sta

2017-07-11 Thread gordon chung
On 11/07/17 10:43 AM, Doug Hellmann wrote: > Excerpts from gordon chung's message of 2017-07-11 14:23:41 +: >> >> On 10/07/17 01:26 PM, Doug Hellmann wrote: >>> openstack/ceilometer-powervm >>> openstack/ceilometermiddleware >> >> i don't believe there are docs for these.

Re: [openstack-dev] [heat][ironic][telemetry][dragonflow][freezer][kuryr][manila][mistral][monasca][neutron][ansible][congress][rally][senlin][storlets][zun][docs] repos without signs of migration sta

2017-07-11 Thread gordon chung
On 10/07/17 01:26 PM, Doug Hellmann wrote: > openstack/ceilometer-powervm > openstack/ceilometermiddleware i don't believe there are docs for these. ceilometermiddleware is a simple wsgi middleware and it's usage is part of ceilometer's install docs. ceilometer-powervm contains the powervm

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

2017-07-04 Thread gordon chung
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

Re: [openstack-dev] [telemetry][ceilometer]Cannot get vmware virtual machine's disk usage rate via vsphere inspector

2017-06-29 Thread gordon chung
i'll be honest, i don't think any of the active developers on Ceilometer uses or knows anything about vmware driver. you will probably want to reach out to vmware themselves so they can provide support or fix the driver (or ideally move the vmware driver to their own repo). On 28/06/17 10:34

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

2017-06-29 Thread gordon chung
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] deprecating pollster-list option

2017-06-27 Thread gordon chung
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] [oslo][oslo-service] Multi main processes are started by using oslo_service

2017-06-27 Thread gordon chung
On 27/06/17 05:56 AM, zhi wrote: > Everything goes well when the "api_workers " equals 0 or 1. But two main > processes were started when the " api_workers " equals 2. The log shows > below: > > 2017-06-27 17:42:18.864 1958058 INFO abc.common.wsgi [-] (1958058) wsgi > starting up on

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

2017-06-26 Thread gordon chung
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] [Gnocchi] Difference between Gnocchi-api and uwsgi

2017-06-23 Thread gordon chung
On 23/06/17 03:08 PM, mate...@mailbox.org wrote: > The quantity of metrics is very low. I'm not sure that batch_size works. > Regarding the batch_timeout. What will be when the timeout reached ? Will > ceilometer throw error to the log file and > discard the whole batch ? I've got this timeout

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

2017-06-23 Thread gordon chung
On 22/06/17 01:57 PM, Mike Perez wrote: > An idea that came from the meeting was creating a role of "Champions", > who are the drum beaters to get a goal done by helping projects with > tracking status and sometimes doing code patches. These would be > interested volunteers who have a good

Re: [openstack-dev] [Gnocchi] Difference between Gnocchi-api and uwsgi

2017-06-22 Thread gordon chung
On 22/06/17 04:23 PM, mate...@mailbox.org wrote: > Hello everyone ! > > I'm sorry that I'm disturbing you, but I was sent here from > openstack-operators ML. > On my Mitaka test stack I installed Gnocchi as database for measurements, but > I have problems with > api part. Firstly, I ran it

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

2017-06-22 Thread gordon chung
On 21/06/17 08:41 PM, Zhipeng Huang wrote: > 2. Enhance dev/non-dev comms. I doubt more meetings will be the solution. > > a. I would suggest projects when doing their planning at Forum or > PTG, always leave a spot for requirement from WGs. And WG chairs > should participate this

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-19 Thread gordon chung
On 19/06/17 07:32 AM, Flavio Percoco wrote: >> as an aside, in telemetry project, we did something somewhat similar >> when we renamed/rebranded to telemetry from ceilometer. we wrote several >> notes to the ML, had a few blog posts, fixed the docs, mentioned the new >> project structure in our

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 06:28 PM, Doug Hellmann wrote: >> i see, so this is less an existential question of 'what is openstack' >> > and more 'how to differentiate governance projects from a random repo >> > created last weekend' >> > >> > this might have been just me, but big tent was exactly 'big tent ==

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 03:23 PM, Doug Hellmann wrote: > > We are very open with our hosting, allowing projects that have not > yet, and may never, sign up to be governed by the TC to use our > infrastructure services. We expect them to be related in some way, > but we have even imported projects when we've

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 02:05 PM, Davanum Srinivas wrote: > Example from https://www.meetup.com/openstack/events/237621777/ > "Platform9 recently open-sourced Project Mors and VM HA as part of the > OpenStack Big Tent initiative." ah i see, i imagine you could correct those who are corporate sponsors (and

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 01:17 PM, Davanum Srinivas wrote: > [DIMS] Tons of folks confused about "Big-Tent", folks are confusing > that label with "projects under governance". wait, the big tent isn't the projects under governance? that's what i thought it was based on all the noise... more confused than i

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 11:28 AM, Davanum Srinivas wrote: > The purpose (my 2 cents) is to highlight what projects are under > governance and those that are not. going down the rabbit hole, what does it mean to be under governance? projects that want to use the openstack brand and were, at the time of

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 10:57 AM, Thierry Carrez wrote: > Jeremy Stanley wrote: >> > >> > I'm still unconvinced a term is needed for this. Can't we just have >> > "OpenStack Projects" (those under TC governance) and "everything >> > else?" Why must the existence of any term require a term for its >> >

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

2017-06-15 Thread gordon chung
On 15/06/17 07:03 AM, Chris Dent wrote: > > Part of the issue is that the meaning and value of being an > "OpenStack project" (an "official" one) is increasingly diffuse. > I suspect that if we could make that more concrete then things like > names would be easier to decide. Some things we

Re: [openstack-dev] [telemetry][ceilometer][opendaylight][networking-odl] OpenDaylight Driver for Ceilometer

2017-06-13 Thread gordon chung
On 13/06/17 08:22 AM, Deepthi V V wrote: > Gordon, the driver would leverage ceilometer's polling framework. It will run > as part of ceilometer-agent-central process and will be added to > "network.statistics.drivers" Namespace. > I guess then we are good to add it to networking-odl? yep,

Re: [openstack-dev] [telemetry][ceilometer][opendaylight][networking-odl] OpenDaylight Driver for Ceilometer

2017-06-12 Thread gordon chung
On 12/06/17 04:25 AM, Deepthi V V wrote: > Hi, > > > > We plan to propose a ceilometer driver for collecting network statistics > information from OpenDaylight. We were thinking if we could have the > driver code residing in networking-odl project instead of Ceilometer > project. The thought is

Re: [openstack-dev] [all] etcd3 as base service - update

2017-06-09 Thread gordon chung
On 09/06/17 10:57 AM, Mike Bayer wrote: > Interesting, I had the mis-conception that "fernet" keys no longer > required any server-side storage (how is "kept-on-disk" now > implemented?) . We've had continuous issues with the pre-fernet > Keystone tokens filling up databases, even when

Re: [openstack-dev] [all] etcd3 as base service - update

2017-06-09 Thread gordon chung
On 09/06/17 12:37 AM, Joshua Harlow wrote: > My thinking is that people should look over https://raft.github.io/ or > http://thesecretlivesofdata.com/raft/ (or both or others...) > this was really useful. thanks for this! love how they described it so simply with visuals. spend a few minutes

Re: [openstack-dev] [gnocchi] regional incoming storage targets

2017-06-01 Thread gordon chung
On 01/06/17 07:46 AM, Julien Danjou wrote: > Yes, write doc or log an issue at least. It's best way to keep a public > track now on ideas and what's going on since it's what people are going > to read and search into. added here: https://github.com/gnocchixyz/gnocchi/issues/60 -- gord

Re: [openstack-dev] [collectd-ceilometer-plugin] dpdkstat related meters are not displayed under "ceilometer meter-list"

2017-06-01 Thread gordon chung
On 01/06/17 03:51 AM, rajeev.satyanaray...@wipro.com wrote: > I am working on bringing up Newton version of Openstack on 3 > Nodes(Controller, Compute and Network). I am using OVS with DPDK on my > Compute Node and to get dpdk port related statistics on my Ceilometer, I > have configured

[openstack-dev] [gnocchi] regional incoming storage targets

2017-05-31 Thread gordon chung
here's a scenario: i'd like aggregates stored centrally like it does currently with ceph/swift/s3 drivers but i want to collect data from many different regions spanning globe. they can all hit the same incoming storage but: - that will be a hell of a lot of load - single incoming storage

[openstack-dev] [panko] dropping hbase driver support

2017-05-26 Thread gordon chung
hi, as all of you know, we moved all storage out of ceilometer so it is handles only data generation and normalisation. there seems to be very little contribution to panko which handles metadata indexing, event storage so given how little it's being adopted and how little resources are being

[openstack-dev] [telemetry] gnocchi v4 preview

2017-05-26 Thread gordon chung
hi, since i've been referencing this to a few people already, i've done some basic benchmarking on the upcoming gnocchi release which should be released in next few weeks. here is a short deck highlighting a few updates: https://www.slideshare.net/GordonChung/gnocchi-v4-preview if you have

Re: [openstack-dev] uWSGI help for Congress

2017-05-22 Thread gordon chung
On 22/05/17 05:48 PM, Eric K wrote: > If someone out there knows uWSGI and has a couple spare cycles to help > Congress project, we'd super appreciate it. > > The regular contributors to Congress don't have experience with uWSGI > and could definitely use some help getting started with this

Re: [openstack-dev] [telemetry] Room during the next PTG

2017-05-22 Thread gordon chung
On 22/05/17 02:42 AM, Hanxi Liu wrote: > > +1. I always thought it's a pity that we have no weekly meeting. The > whole Telemetry team need communications. > PTG room discussion can not only provide a good chance to communicate > within team but also attract more new people to contribute. > In

Re: [openstack-dev] [telemetry] Room during the next PTG

2017-05-19 Thread gordon chung
On 18/05/17 05:56 PM, Julien Danjou wrote: > Hi team, > > It's time for us to request a room (or share one) for the next PTG in > September if we want to meet. Last time we did not. Do we want one this > time? > if there are cross project discussions we can line up beforehand, it might be

Re: [openstack-dev] [Ceilometer]

2017-05-12 Thread gordon chung
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 >

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-05-01 Thread gordon chung
On 29/04/17 08:14 AM, Julien Danjou wrote: > 1. get 'deleted' metrics > 2. delete all things in storage > -> if it fails, whatever, ignore, maybe a janitor is doing the same > thing? > 3. expunge from indexer possibly? i was thinking it was possible that maybe it would partially delete and

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 10:50 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> if the sack is unlocked, then it means a processing worker isn't looking >> at the sack, and when it does lock the sack, it first has to check sack >> for existing measures t

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 10:50 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> if the sack is unlocked, then it means a processing worker isn't looking >> at the sack, and when it does lock the sack, it first has to check sack >> for existing measures t

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 10:11 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> refresh i believe is always disabled by default regardless of what >> interface you're using. > > You gotta to show me where it is 'cause I can't see that and I d

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 09:23 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> what if we just don't lock ever on delete, but if we still check lock to >> see if it's processed. at that point, the janitor knows that metric(s) >> is deleted, and since no one

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 09:19 AM, Julien Danjou wrote: > That's not what I meant. You can have the same mechanism as currently, > but then you compute the sacks of all metrics and you > itertools.groupby() per sack on them before locking the sack and > expunging them. yeah, we should do that. i'll add that

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 03:48 AM, Julien Danjou wrote: > Yes, I wrote that in a review somewhere. We need to rework 1. so > deletion happens at the same time we lock the sack to process metrics > basically. We might want to merge the janitor into the worker I imagine. > Currently a janitor can grab metrics

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-28 Thread gordon chung
On 28/04/17 03:48 AM, Julien Danjou wrote: > > Yes, I wrote that in a review somewhere. We need to rework 1. so > deletion happens at the same time we lock the sack to process metrics > basically. We might want to merge the janitor into the worker I imagine. > Currently a janitor can grab

[openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

2017-04-27 Thread gordon chung
hey, so as we transition to the bucket/shard/sack framework for incoming writes, we've set up locks on the sacks so we only have one process handling any given sack. this allows us to remove the per-metric locking we had previously. the issue i've notice now is that if we only have per-sack

Re: [openstack-dev] [oslo] Can we stop global requirements update?

2017-04-20 Thread gordon chung
On 20/04/17 01:32 AM, Joshua Harlow wrote: > Wasn't there also some decision made in austin (?) about how we as a > group stated something along the line of co-installability isn't as > important as it once was (and may not even be practical or what people > care about anymore anyway)? > > With

Re: [openstack-dev] [ceilometer]Looking for endpoint where event passed after first time

2017-04-20 Thread gordon chung
On 20/04/17 01:46 AM, Hui Xiang wrote: > And yes I have known that ceilometer notification agent will listen for > the notification topics, but my question is which file/class will do it. > When I am debugging the code, at the first time when the event send out > to ceilometer exchange

Re: [openstack-dev] [ceilometer]Looking for endpoint where event passed after first time

2017-04-19 Thread gordon chung
On 19/04/17 03:05 PM, Hui Xiang wrote: > Hi folks, > > I am posting some self-defined events to amqp ceilometer exchange > notification topic, during the debug session, I find that at the first > time, event are arriving at notification bus as the AMQPIncomingMessage, > and then handled by

Re: [openstack-dev] [gnocchi] new measures backlog scheduling

2017-04-18 Thread gordon chung
On 18/04/17 10:42 AM, Julien Danjou wrote: > On Tue, Apr 18 2017, gordon chung wrote: > >> do we want it configurable? tbh, would anyway one configure it or know >> how to configure it? even for us, we're just guessing somewhat.lol i'm >> going to leave it static for

  1   2   3   4   5   >