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

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 t

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

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] Mascot/logo for your project

On 19/07/16 03:50 AM, Julien Danjou wrote: Heidi, could you confirm that it is a mascot per team or per project? Honestly, I don't think it'll suit us to have only one mascot/logo. It's gonna be hard to use a logo marked "Telemetry" as a branding for our 4 different projects that do different t

Re: [openstack-dev] [telemetry] Mascot

On 21/07/2016 11:36 AM, Doug Hellmann wrote: > Something with big ears that are good for listening. A fennec [1]? A > serval [2]? > > Doug > > [1] https://en.wikipedia.org/wiki/Fennec_fox > [2] https://en.wikipedia.org/wiki/Serval i really like these suggestions, with a preference for the fennec

Re: [openstack-dev] [telemetry] Mascot

Sent: July 21, 2016 19:47 >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [telemetry] Mascot >> >> On Thu, 21 Jul 2016, gordon chung wrote: >>> On 21/07/2016 11:36 AM, Doug Hellmann wrote: >>>> Somethi

Re: [openstack-dev] [horizon][vitrage] Midcycle Summary

this is probably a continuation from the design summit back in Japan[1]. basically, it's a very common use case that people want to visualise ceilometer(system) data. the issue is that the existing dashboard in horizon (Resource Usage tab) is unusable both because it is just a data dump of cei

[openstack-dev] [gnocchi] typical length of timeseries data

hi folks, this is probably something to discuss on ops list as well eventually but what do you think about shrinking the max size of timeseries chunks from 14400 to something smaller? i'm curious to understand what the length of the typical timeseries is. my main reason for bringing this up is

Re: [openstack-dev] [gnocchi] typical length of timeseries data

On 29/07/2016 5:00 AM, Julien Danjou wrote: > Best way is probably to do some bench… but I think it really depends on > the use cases here. The interest of having many small splits is that you > can parallelize the read. > > Considering the compression ratio we have, I think we should split in >

Re: [openstack-dev] [gnocchi] typical length of timeseries data

On 29/07/2016 12:20 PM, Julien Danjou wrote: > On Fri, Jul 29 2016, gordon chung wrote: > >> so at first glance, it doesn't really seem to affect performance much >> whether it's one 'larger' file or many smaller files. > > I guess it's because yo

Re: [openstack-dev] [gnocchi] typical length of timeseries data

On 29/07/16 03:29 PM, gordon chung wrote: i'm using Ceph. but i should mention i also only have 1 thread enabled because python+threading is... yeah. i'll give it a try again with threads enabled. I tried this again with 16 threads. as expected, python (2.7.x) threads do jack al

Re: [openstack-dev] FW: [Ceilometer]:Duplicate messages with Ceilometer Kafka Publisher.

what does your pipeline.yaml look like? maybe paste it to paste.openstack.org. i imagine it's correct if your udp publishing works as expected. On 16/08/16 04:04 AM, Raghunath D wrote: Hi Simon, I have two openstack setup's one with kilo and other with mitaka. Please find details of kafka versi

Re: [openstack-dev] [Ceilometer] Newbie question regarding Ceilometer notification plugin

On 15/08/16 02:23 PM, Wanjing Xu (waxu) wrote: We are trying to develop a program which can draw the VMs topology. For this we need to listen VM creation/deletion event and act upon it. I would think Ceilometer is the right place for this. So I download and read Ceilometer a little bit. If s

Re: [openstack-dev] [Telemetry] Barcelona summit space needs

i'm cool with less space requirements. as the summit is basically all marketing driven now, i don't see any increase in devs being sent to Barcelona. do we even want the contributors meetup? based on last few summits, a good chunk of people just choose to fly out on the last day so basically no

Re: [openstack-dev] FW: [Ceilometer]:Duplicate messages with Ceilometer Kafka Publisher.

ertainty. IT Services Business Solutions Consulting ________ -gordon chung <mailto:g...@live.ca> wrote: - To: "openstack-dev@lists.openstack.org"<mailto:openstack-dev@lists.openstack.org> <mailto:openstack-dev@lists.openstack.org> From: gordon chung <mailto:g

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 25/08/16 01:13 PM, Steve Martinelli wrote: The keystone team is pursuing a trigger-based approach to support rolling, zero-downtime upgrades. The proposed operator experience is documented here: http://docs.openstack.org/developer/keystone/upgrading.html This differs from Nova and Neutron

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

just to clarify, what 'innovation' do you believe is required to enable you to build on top of OpenStack. what are the feature gaps you are proposing? let's avoid defining "the cloud" since that will give you 1000 different answers if you ask 1000 different people.* * actually you'll get 100 an

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

just a heads up, oslo.db 4.13.2 is also broken. we will need this: https://review.openstack.org/#/c/366362/ or something that fixes issue :) On 07/09/16 09:21 AM, Matthew Thode wrote: > https://review.openstack.org/366298 > > This is just a bump to upper-constraints so is more minor to get testin

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

On 08/09/16 09:13 AM, Chris Dent wrote: > The truth, for me, is that I agree with most of the things in the > document. What is problematic for me is that I know a lot of people > who will not. Because of the ordering of the process and the > presumption of the document they will simply choose to

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

On 07/09/16 12:04 PM, Sean Dague wrote: > On 09/07/2016 11:43 AM, Thierry Carrez wrote: >> Hi everyone, >> >> As you probably know by now, starting with the Boston event in 2017, the >> Summit will happen further away from the release day and more around the >> middle of the next development cycl

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

mec, great work trying to make the stuff we build work and telling us to make it less broken. so we play ping pong now? On 09/09/16 12:05 PM, Emilien Macchi wrote: > Hi, > > I wrote a little blog post about the last cycle in PuppetOpenStack: > http://my1.fr/blog/puppet-openstack-achievements-dur

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

On 09/09/16 03:50 PM, Matt Riedemann wrote: > > Do we really expect the next cycle PTL to be planning for the next cycle > midway through the current cycle? That seems pretty extreme to me, when > we're still crunching to the 3rd milestone and trying to wrap things up > for feature freeze, which

Re: [openstack-dev] [requirements][FFE] Request to allow ceilometerclient 2.6.1 in upper-constraints for newton

On 09/09/16 03:45 PM, Matthew Thode wrote: > Does this mean that the minimum (GR needs raising as well)? iiuc, just the max or upper-constraints. cheers, -- gord __ OpenStack Development Mailing List (not for usage questi

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

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] [nova][ceilometer] versioned notifications coverage

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 __ Op

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

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 > t

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

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] [gnocchi] gnocchi-keystone verification failed.

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. > https://gnocchi.xyz/gnocchiclient/shell.html

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

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. > the

[openstack-dev] [telemetry][ceilometer] let's talk about volume=1 meters (again)

hi, i should preface the below is arguably not important if we have ability to count events and alarm against panko. ~~ we recently removed all our volume=1 meters in ceilometer and while i cleaning things up some residual stuff i started to wonder if we took out too much. (yes, i'm aware of

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

On 29/11/16 01:24 PM, Doug Hellmann wrote: > If we start by assuming that contributors may end up getting more > value from seeming to be a part of the community than the community > will get from their participation, and that we have to guard against > that because it somehow diminishes us, it s

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

On 29/11/16 03:53 PM, Jeremy Stanley wrote: > Perhaps they wanted to publish documentation to the > docs.openstack.org site? That's traditionally only been allowed by > the Docs team for official project deliverables. that's probably it, i just couldn't find their docs. from our experience, we

[openstack-dev] [ceilometer] lxml gate issues

hi, this is just a headsup, i'm fast approving my own magic[1] to fix gate of the error 'fatal error: libxml/xpath.h: No such file or directory'[2]. some notes: - i don't know why it doesn't affect aodh (so far) even though aodh has the same lxml requirement - there was a new lxml lib release r

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

On 12/12/16 10:13 PM, Li, Xiaoyan wrote: > The new notification reports kinds of capacity information, includes total, > free, allocated, provisioned, visual_free. that's cool. just for reference, you can easily add support to generate metrics from this by editing the meters.yaml file[1]. alte

Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

On 20/12/16 05:09 PM, Steve Martinelli wrote: > This was my initial thought when discussing the problem with Hongbin > last night. > > We have three main "swift" resources in OSC -- "object store account", > "container" and "object". I think renaming "container" to "object store > container" is t

Re: [openstack-dev] Gone (HTTP 410) when use "ceilometer alarm-list"

On 27/12/16 08:03 PM, jace.li...@itri.org.tw wrote: > Hi, > > > > I have trouble using alarm of ceilometer , when I type ceilometer > alarm-list, > > it returns Gone (HTTP 410) (Request-ID: > req-a6d1d333-ac49-48c5-ad94-ae8796b13e26) > > Even creating alarm will returns same result. > > I'm using

Re: [openstack-dev] Gnocchi sizing on production

On 28/12/16 05:49 AM, Sam Huracan wrote: > Thanks, > > > How can I increase processing delay? I think it could increase the > number of measures in queue. > you can also force the measures in backlog/queue to be processed on request by passing in refresh=True. in theory, you could turn off all

Re: [openstack-dev] [Telemetry] Asking a question to our users

On 26/12/16 05:20 AM, Julien Danjou wrote: > Hi folks, > > The foundation is offering the opportunity to ask a question to users: > > "I wanted to offer you the opportunity to ask a question on the > upcoming User Survey, which launches on or before Feb. 1. Each PTL of > a project with sign

Re: [openstack-dev] [Telemetry] Asking a question to our users

On 04/01/17 12:08 PM, Julien Danjou wrote: > I _think_ they ask for what "release of OpenStack" is being used, but > that might be it. i would probably do something similar to what Mehdi suggested then. i don't think we want feedback relating to ceilometer storage/api (because it's been dead f

Re: [openstack-dev] [Ceilometer] Scale deployment

On 08/01/17 07:28 PM, Srikanth Vavilapalli wrote: > > - Deploying database cluster on separate nodes with sharding > and replica-sets enabled > we don't recommend you use ceilometer storage since it's deprecated and hasn't been worked on for over a year. > > > My questions are: > > 1.

Re: [openstack-dev] [Ceilometer] Scale deployment

On 09/01/17 07:21 PM, Srikanth Vavilapalli wrote: > Thanks Gordon for your inputs, Quick follow-up question: I see few new > alternatives existing in place of ceilometer mongo storage: Gnocchi and > Panko. Are these recommended data storage options from now on for Ceilometer? > Also, I suppose

Re: [openstack-dev] [telemetry] [ceilometer] [panko] ceilometer API deprecation

On 10/01/17 07:27 AM, Julien Danjou wrote: > On Mon, Jan 09 2017, William M Edmonds wrote: > >> I started the conversation on IRC [5], but wanted to send this to the >> mailing list and see if others have thoughts/concerns here and figure out >> what we should do about this going forward. > > Not

Re: [openstack-dev] [telemetry] [ceilometer] [panko] ceilometer API deprecation

On 11/01/17 08:06 AM, William M Edmonds wrote: > > After discussing with my team, I think we will need to propose a revert. > The deprecation process was not followed correctly here. We will start > working on moving to panko, but we are not sure we can contain that for > Ocata. Please follow the

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

On 13/01/17 06:47 PM, Srikanth Vavilapalli wrote: > So the question is, is there any config that I can use to let > "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in > addition to predefined ones, such that this framework can be extended to > receive meters from non ope

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

On 13/01/17 06:47 PM, Srikanth Vavilapalli wrote: > So the question is, is there any config that I can use to let > "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in > addition to predefined ones, such that this framework can be extended to > receive meters from non ope

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

On 17/01/17 06:58 PM, Keen, Joe wrote: > > I also see additional problems with the use of the deprecated > SimpleConsumer and SimpleProducer clients. We really do need to > investigate migrating to the new async only Producer objects while still > maintaining the reliability guarantees that Mona

Re: [openstack-dev] [oslo] Not running for Oslo PTL for Pike

On 03/01/17 03:03 PM, Joshua Harlow wrote: > Hi Oslo folks (and others), > > Happy new year! > > After serving for about a year I think it's a good opportunity for > myself to let another qualified individual run for Oslo PTL (seems > common to only go for two terms and hand-off to another). > >

[openstack-dev] [telemetry] remaining ocata items

hi, so i just wanted to create a list of items i'm tracking for ocata that i'd like to see in: ceilometer - polling definition file support [1] - configurable control exchanges [2] - deprecate collector [3] - equivalent publisher/dispatcher support [4] gnocchi - creator(user+project) unique ids

Re: [openstack-dev] [telemetry] remaining ocata items

On 24/01/17 11:53 AM, Emilien Macchi wrote: > Yes, even outside TripleO, it's already hard to follow all changes > made in projects, so please do not deprecate things at the end of a > cycle. > Let's take some time, we do it in Pike, making good communication, so > folks like TripleO etc can have

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 24/01/17 03:01 AM, Afek, Ifat (Nokia - IL) wrote: > We understood that Aodh aims to be OpenStack alarming service, which is much > more than an ‘engine of alarm evaluation’ (as you wrote in your comment in > gerrit). If I may describe another use case for generic alarms - of OPNFV > Doctor:

Re: [openstack-dev] [telemetry] remaining ocata items

On 24/01/17 02:05 PM, Emilien Macchi wrote: > I'm ok if you deprecate it in Ocata, as long: > > 1) it's properly document how to make a transition to the new services. > 2) We don't remove it in Pike, because work to deprecate it would have > been done end of Ocata. > > Deal? no. period. (triple

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 24/01/17 03:05 PM, Julien Danjou wrote: > I think Aodh emits notifications when something happens so it can be in > Panko indeed. I don't think it'd be fair to force Panko to have (a > recent) history though. :) i'm going to add a work item (for anyone): allow multiple notification topics on

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc. Each source has its own expertise and internal > implementation. Nagios and Zabbix can raise alarms about the physical layer, > Aodh can rai

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 26/01/17 11:41 AM, Julien Danjou wrote: > So here's another question then: why wouldn't there be a "zabbix" alarm > type in Aodh that could be created by a user (or another program) and > that would be triggered by Aodh when Zabbix does something? > Which is something that is really like the e

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 29/01/17 08:52 AM, Afek, Ifat (Nokia - IL) wrote: > On 26/01/2017, 20:09, "Julien Danjou" wrote: > >> On Thu, Jan 26 2017, gordon chung wrote: >> >>> On 26/01/17 11:41 AM, Julien Danjou wrote: >> >>> and vitrage would be an alarm orchestra

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 31/01/17 08:34 AM, Afek, Ifat (Nokia - IL) wrote: > If you query Vitrage (or get a notification from Vitrage) and then you query > Aodh, then Aodh will not return any additional information. But – if you > query only Aodh, you will be aware of the fact that the instances are at > risk. With

[openstack-dev] [ffe][requirements][gnocchi] upper-constraint gnocchiclient 3.0.0

hi, we'd like to request this patch be accepted: https://review.openstack.org/#/c/426917/ the new client removes some encoding done that was previously required by gnocchiv3 and ceilometer newton but is not relevant to either ceilometer ocata or gnocchi v3.1 (which we are trying to release).

Re: [openstack-dev] [ffe][requirements][gnocchi] upper-constraint gnocchiclient 3.0.0

On 31/01/17 04:09 PM, Matthew Thode wrote: > So, to summarize, new server doesn't work with old client. Will this > require a global requirements update as well (seems like it)? i probably shouldve just typed that ^ > > It will cause a knock-ons for ceilometer, cloudkitty, gnocchi and > mistra

Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/ceilometer failed

thanks for bringing this up. below are the current statuses. On 01/02/17 08:30 AM, Ian Cordasco wrote: >> > Build failed. >> > >> > - periodic-ceilometer-docs-mitaka >> > http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-mitaka/3774607/ >> > : SUCCESS in 4m 09s >> > - periodic-ce

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

On 01/02/17 10:22 AM, Monty Taylor wrote: > > I personally continue to be of the opinion that without an explicit > vocal and well-staffed champion, supporting postgres is more trouble > than it is worth. The vast majority of OpenStack deployments are on > MySQL - and what's more, the code is wri

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

On 01/02/17 11:42 AM, Monty Taylor wrote: > As I mentioned before, I don't think it matters which of the two we pick > - although I know _way_ more about MySQL personally and it has a much > more proven track record at absurdly large scale - I just argue that we > should pick one and then actuall

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

On 01/02/17 12:15 PM, Sean Dague wrote: > What were you thinking about the messaging? TC resolution for > deprecation of postgresql as a first class backend? > > If setup tools want to support things, that's fine, just they do need to > realize they are owning that support its not coming from ups

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 02/02/17 06:30 AM, Afek, Ifat (Nokia - IL) wrote: > I understand. So clearly the use case of Vitrage raising alarms in Aodh is > not relevant at the moment. > We will have to think if over and see how Panko fits in the use case. if the use case is that you wanted to store history of Vitrage

Re: [openstack-dev] [telemetry] Pollsters for Veritas HyperScale

On 10/02/17 12:24 AM, Nirendra Awasthi wrote: > Overview: > * HyperScale pollsters are required to collect and monitor HyperScale > storage statistics. > * Collected statistics can be visualized in HyperScale dashboard. > * Pollsters are deployed on all the managed computes, HyperScale data > pl

Re: [openstack-dev] [oslo_messaging] Limiting the number of retries for kafka driver

On 14/02/17 02:52 PM, Elancheran Subramanian wrote: > Hello All, > This is reg limiting the number of retries for Kafka driver support on > Nova and Neutron. > > While trying out the oslo messaging notifications support for Kafka on > Nova and Neutron, the Kafka driver doesn’t support limiting th

Re: [openstack-dev] Ceilometer event-list empty

On 15/02/17 12:06 AM, Sam Huracan wrote: > Hi, > > I'm unable to show event-list of ceilometer, meanwhile meter-list has > data. Ceilometer log does not any "ERROR". > > My ceilometer.conf: http://paste.openstack.org/show/598925/ > My ceilometer version: http://prntscr.com/e8wob6 > > I'm using Op

Re: [openstack-dev] Ceilometer event-list empty

On 15/02/17 09:27 PM, Sam Huracan wrote: > > I check mongodb has event collection, but it is empty > http://prntscr.com/e9b96w > > I do not see any error in Ceilometer log. > > Could you check my > ceilometer.conf? http://paste.openstack.org/show/598925/ >

Re: [openstack-dev] [architecture][nova][neutron][cinder][ceilometer][ironic] PTG stuff -- Arch-WG nova-compute-api fact-gathering session Tuesday 10:30 Macon

On 17/02/17 01:16 PM, Clint Byrum wrote: > From that, as a group we'll produce a detailed analysis of all the ways > nova-compute is interacted with today, and ongoing efforts to change > them. If you are interested in this please do raise your hand and come > to our meetings[2] as my time to wor

Re: [openstack-dev] [Telemetry] Feedback from the User Survey

On 21/02/17 03:55 AM, Julien Danjou wrote: > - Legacy MongoDB: 56 (60.2% of users, 40.5% of choices) > - Gnocchi: 44 (47.3% of users, 31.8 % of choices) > - HTTP: 8 (8.6% of users, 5.8% of choices) > - Legacy MySQL: 8 (8.6% of users, 5.8% of choices) > - Other: 8 (8.6% of users, 5.8% of choices)

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

On 21/02/17 01:28 AM, Qiming Teng wrote: >> in mysql[2]. > Can someone remind me the benefits we get from Integer over UUID as > primary key? UUID, as its name implies, is meant to be an identifier for > a resource. Why are we generating integer key values? this ^. use UUID please. you can googl

Re: [openstack-dev] [Ceilometer]:Ceilometer kafka publisher is not consistent !

i would consider looking at the kafka implementation in oslo.messaging. i don't believe the individuals who implemented the Kafka publisher still participate in the open community. On 12/09/16 10:04 AM, Raghunath D wrote: > Hi , > > I have below entries in my pipeline.yaml file: > > sources: >

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

On 16/09/16 05:46 AM, Julien Danjou wrote: > On Fri, Sep 16 2016, Sam Morrison wrote: > > >> Currently it is failing one test [1] and that is to do with retention. >> This is because influxDB does retention based on the current time, e.g. a 1 >> day retention policy will be from the current time

Re: [openstack-dev] [Product] Project Navigator - Maturity Metrics

is this updated with a script or manually? i just took a quick look at this and some of the projects have a different information between the high-level "all projects" view and the detailed individual project view. this was something that was brought up a months ago so i assume it hasn't been l

Re: [openstack-dev] [ptl] code churn and questionable changes

i feel like this gets brought up every year. we block these patches in Telemetry projects unless they can be justified beyond the copy/paste description. in addition to this, please, PLEASE stop creating 'all project bugs'. i don't want to get emails on updates to projects unrelated to the ones

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 21/09/16 01:43 AM, Zhai, Edwin wrote: > All, > > I'd like make some clarification for the event-alarm timeout design as > many of you have some misunderstanding here. Pls. correct me if any > mistakes. > > I realized that there are 2 different things, but we mix them sometime: > 1. event-timeo

Re: [openstack-dev] [ptl] code churn and questionable changes

On 22/09/2016 11:18 AM, Amrith Kumar wrote: > [amrith] Actually, not true. Some of the changes I'm seeing are from people > who have a track record of these kinds of changes. And if there is a knob in > Launchpad somewhere, I sure as hell can't find it. no way to block actions but as a workaro

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 22/09/2016 2:40 AM, Zhai, Edwin wrote: > > See > https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158 > > evaluate_events is the handler of the endpoint for 'alarm.all', it > iterates the event list and evaluate them one by one with project > alarms. If both 'timeout.end'

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 23/09/2016 3:19 AM, Zhai, Edwin wrote: > "Each notification listener is associated with an executor which > controls how incoming notification messages will be received and > dispatched. By default, the most simple executor is used - the blocking > executor. This executor processes inbound not

Re: [openstack-dev] [AODH] event-alarm timeout discussion

On 23/09/2016 2:18 AM, Zhai, Edwin wrote: > > There are many targets(topics)/endpoints in above ceilometer code. But > in AODH, we just have one topic, 'alarm.all', and one endpoint. If it is > still multi-threaded, there is already potential race condition here, > but event-alarm tiemout make i

Re: [openstack-dev] TC candidacy

On 28/09/2016 12:41 PM, Chris Dent wrote: > > * Information is not always clear nor clearly available, despite > valiant efforts to maintain a transparent environment for the > discussion of policy and process. There is more that can be done > to improve engagement and communication. Maybe

Re: [openstack-dev] TC candidacy

On 28/09/2016 3:59 PM, Chris Dent wrote: > On Wed, 28 Sep 2016, Jim Rollenhagen wrote: > >> And the git tree, with a changelog, is here: >> http://git.openstack.org/cgit/openstack/governance/ > > I assume, but I'd prefer if he confirm, that the point gordc was > trying to make was that there's mo

Re: [openstack-dev] TC candidacy

On 28/09/2016 4:27 PM, Jeremy Stanley wrote: > As was pointed out elsewhere in the thread, the TC has been trying > to do something along these lines at > http://www.openstack.org/blog/category/technical-committee-updates/ > but even with a dedicated communication subteam (see the May 13, > 2015

Re: [openstack-dev] TC candidacy

On 29/09/16 04:35 PM, John Dickinson wrote: > > I am concerned that there is a current focus on preserving the status > quo. There's focus on policies and rules instead of use cases; there's > focus on conformity instead of innovation; there's focus on forced > prioritization instead of inclusivi

Re: [openstack-dev] [Keystone] Project name DB length

On 28/09/2016 11:52 PM, Adrian Turjak wrote: > > Plus although there is no true official standard, most projects in > OpenStack seem to use 255 as the default for a lot of string fields. > Weirdly enough, a lot of projects seem to use 255 even for project.id, > which seeing as it's 64 in keystone

[openstack-dev] [tc] open question to the candidates

hi, as there are many candidates this TC election, i figured i'd ask a question to better understand the candidates from the usual sales pitch in self-nominations. hopefully, this will give some insights into the candidates for those who haven't voted yet. obviously, the following is completel

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

On 03/10/2016 1:18 PM, Clay Gerrard wrote: > I think a more common problem is when people vote for a *name* they > recognize without really knowing that person or what they're about. Or > perhaps just as bad - *not* voting because they realize they have on > context to consider these candidates

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

On 04/10/2016 11:58 AM, Tim Bell wrote: > What would be the impact for Heat users who are using the Ceilometer scaling > in their templates? > > Tim pretty big. :/ i don't really have anything else to add to this answer. jd__, add it to discussion :P i think the main issue right now is, no o

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

so one thing we probably do need to keep is the ability push samples (and events?). i know previously people were actually using this feature. On 04/10/2016 11:27 AM, Julien Danjou wrote: > Hi, > > Considering the split of Ceilometer in subprojects (Aodh and Panko) > during those last cycles, and

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

On 04/10/2016 12:04 PM, Yarko Tymciurak wrote: > I won't be at Barcelona, but would like to participate in the telemetry > sessions, and particularly this one. > Are there plans to enable remote participants (beyond just etherpad), > i.e. hangouts or skype, or something similar? we can try this

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

On 04/10/2016 12:35 PM, Julien Danjou wrote: > On Tue, Oct 04 2016, gordon chung wrote: > >> so one thing we probably do need to keep is the ability push samples >> (and events?). i know previously people were actually using this feature. > > That's debatable. >

Re: [openstack-dev] [tc] open question to the candidates

hi, just so it doesn't seem like you're replying to nobody. i want to thank all of you for opening up on this topic which hopefully isn't only important to me alone. it really helped me with my voting beyond the people i know. i apologise if this was a polarising topic but it was great to see

Re: [openstack-dev] [Keystone] Project name DB length

On 05/10/16 07:55 AM, Sean Dague wrote: > Except... the 64 char field in keystone isn't required to be a uuid4. > Which we ran into when attempting to remove it from the URLs in Nova. > There is no validation anywhere that requires that of keystone values. > > For instance, Rackspace uses ints.

[openstack-dev] [telemetry][gnocchi] benchmarking gnocchi v3

hi folks, as announced recently, we released Gnocchi v3[1][2]! this marked a major change in how we process and store data in Gnocchi as we worked on building a truly open source time-series service. as we were building it, i've been benchmarking the results and feeding it back into our develo

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

On 10/10/16 04:48 PM, Joshua Harlow wrote: > > So the question started to be raised of is there a documented > format/schema for the events that are being emitted from various services> (there seems to be some at > http://docs.openstack.org/developer/nova/notifications.html)? we have something

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

On 11/10/16 01:14 PM, Joshua Harlow wrote: > > Ah, right, nearly forgot about that yaml. Thanks gordon! > > Has there been any ideas from folks to split those > 'event_definitions.yaml' into something else (a notifications schema > repo?)? I'd be up for helping do that (nice to have would be an i

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

On 11/10/16 04:18 PM, Joshua Harlow wrote: > > To be productive here, would there be any problem if I (or someone I > know) just split that yaml off into a new git repository, and started > iterating on figuring out how to turn the yaml into something that can > generate code for [python, java, g

Re: [openstack-dev] Event notification descriptors/schemas (? swagger ?)

On 11/10/16 05:38 PM, Joshua Harlow wrote: > Yes yes, normalization would be nice to, though a little beyond what I > am (or was) thinking of currently. Going back to how > event_definitions.yaml is the best 'source' we have currently, is it > possible to rip out (for now) event_definitions.yaml

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

On 12/10/16 05:43 PM, Mike Perez wrote: > Besides the governance site, there is also the project navigator [1] which is > a more friendly landing page on projects and their tags. Although it does not > today capture separate deliverables. > > Assuming the README files aren't being manually update

Re: [openstack-dev] [gnocchi] host field information flapping for instance resource-type

i won't lie, i don't remember opening that bug.lol it actually might be related to this previous fix: https://github.com/openstack/ceilometer/commit/de5ff7303d6f278ef37149297bbb7d2e77f45a0d On 12/10/16 08:49 PM, Jake Yip wrote: > Hi all! > > We've been trying to get gnocchi working us, and have

Re: [openstack-dev] [gnocchi] host field information flapping for instance resource-type

04:53 PM, gordon chung wrote: > it actually might be related to this previous fix: > https://github.com/openstack/ceilometer/commit/de5ff7303d6f278ef37149297bbb7d2e77f45a0d -- gord __ OpenStack Development Mailing Lis

Re: [openstack-dev] [telemetry] Telemetry presence at PTG in February

On 10/10/16 08:47 AM, Julien Danjou wrote: > Hi team, > > I'd like to know if members and supporters of the Telemetry team would > like to request a space in February 2017 during the next PTG¹ in > Atlanta. > > It may be hard to schedule enough in advance, but if you got a feeling > whether you'l

<    1   2   3   4   5   >