Re: [openstack-dev] [ceilometer] indicating sample provenance

> a) Am I right that no indicator is there? > > b) Assuming there should be one: > > * Where should it go? Presumably it needs to be an attribute of > each sample because as agents leave and join the group, where > samples are published from can change. > > * How should it be named? The never-en

Re: [openstack-dev] [ceilometer] indicating sample provenance

> b) Assuming there should be one: > >* Where should it go? Presumably it needs to be an attribute of > each sample because as agents leave and join the group, where > samples are published from can change.is this just for debugging > purposes or auditing? from an audit standpoint, w

Re: [openstack-dev] [all] The future of the integrated release

> The point I've been making is > that by the TC continuing to bless only the Ceilometer project as the > OpenStack Way of Metering, I think we do a disservice to our users by > picking a winner in a space that is clearly still unsettled. can we avoid using the word 'blessed' -- it's extremel

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

is it possible that it's not on all the nodes? seems like it passed here: https://review.openstack.org/#/c/109207/ but another patch at roughly the same time failed https://review.openstack.org/#/c/113549/ cheers, gord _

Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient

> I would like to realize moving swift_middleware.py from the ceilometer > package to > the ceilometerclient package. For me it is very difficult to convince users > of > installing the ceilometer package on Proxy Nodes for just using the swift > middleware > because of maintenance costs. Ope

Re: [openstack-dev] [all] The future of the integrated release

> It may be easier for you, but it certainly isn't inside big companies, > e.g. HP have pretty broad approvals for contributing to (official) > openstack projects, where as individual approval may be needed to > contribute to none-openstack projects. i was referring to a company bigger than hp... m

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

> I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh > trusty too, everything worked fine… fun from the limited error message. it's because service path isn't found (https://github.com/stackforge/wsme/blob/master/wsmeext/sphinxext.py#L133-L140) and this code is returnin

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

just an update, i had to re-add PYTHONHASHSEED = 0 to ceilometer. i didn't find the exact root cause of why WSME is affecting our doc gate but it appears WSME is also affected by new tox and random hashseed as it too suffers from random failures in UT. for now, i've added back HASHSEED so we sho

Re: [openstack-dev] Treating notifications as a contract

> > For example: It appears that CADF was designed for this sort of thing and> > > > was considered at some point in the past. It would be useful to know> > > > more of that story if there are any pointers.> >> > My initial reaction is > > that CADF has the stank of enterprisey all over> > it ra

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

> Nejc has been doing a great work and has been very helpful during the> Juno > cycle and his help is very valuable. > I'd like to propose that we add Nejc Saje to the ceilometer-core group.can we > minus because he makes me look bad? /sarcasm +1 for core. cheers, gord

[openstack-dev] oslo.middleware 0.1.0 release

on behalf of the Oslo team, we're pleased to the announce the initial public release of oslo.middleware (verison 0.1.0). this library contains WSGI middleware, previously available under openstack/common/middleware, that provides additional functionality to the api pipeline.the oslo.middleware

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

> Dina has been doing a great work and has been very helpful during the > Juno cycle and her help is very valuable. She's been doing a lot of> reviews > and has been very active in our community.+1cheers, gord __

[openstack-dev] [Ceilometer] meaning of resource_id in a meter

at is accessible from notification/response and if it is, is there a better (possibly more consistent) alternative? cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com___ OpenStack-dev mailing list OpenStac

Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter

consistent resource_id can provide. cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic][Ceilometer] get IPMI data for ceilometer

n this bp as well: https://blueprints.launchpad.net/oslo/+spec/notification-structured cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.or

Re: [openstack-dev] [ceilometer][qa] Punting ceilometer from whitelist

RIGHT NOW! was going to ask what CRITICAL level was for... good thing i googled first: http://docs.python.org/2/howto/logging.html seems like a good enough definition for each level. cheers, gordon chung openstack, ibm software standards

Re: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team

much of the > existing event storage and querying code. +1 in support of Sandy. the Event work he's led in Ceilometer has been an important feature and i think he has some valuable ideas. cheers, gordon chung openstack, ibm software standards___ O

Re: [openstack-dev] [ceilometer] Discussion of the resource loader support patch

eas outside of fileloader so it'd be interesting to know of other use-cases. cheers, gordon chung openstack, ibm software standards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

'status': 'ok' > }, > '3.3VCC': { > 'current_value': '3.36', > 'min_value': '3.20', > 'max_value': '3.56

Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer

looks like there > are no categories and hardware exposes a variable number of meters > whose names adhere to some consistent structure (eg, "FAN ?" and "V???"). cool cool. personally, i would think the first option, splitting it into categori

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

k > low priority for J cycle. adding participants to the bp just so we get eyes on it. cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

r/+bug/1285388 cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Suggestions for alarm improvements

ove doc? is the pipeline alarm design attached to a blueprint? also, is your interest purely to see status or were you looking to work on it? ;) cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@

[openstack-dev] oslo.middleware 0.2.0 released

The Oslo team is pleased to announce release 0.2.0 of oslo.middleware. This is primarily a bug-fix release, but does include requirements changes. For more details, please see the git log history below and https://launchpad.net/oslo.middleware/kilo/0.2.0 Please report issues through launchpad

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 cheers, gord From: morgan.fainb...@gmail.com Date: Sun, 18 Jan 2015 12:11:02 -0700 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer

[openstack-dev] pyCADF 0.7.0 released

pyCADF is the python implementation of the DMTF Cloud Auditing Data Federation Working Group (CADF) specification. pyCADF 0.7.0 has been tagged and should be available on PyPI and our mirror shortly. this release includes: * deprecation of audit middleware (replaced by audit middleware in keyst

Re: [openstack-dev] [ceilometer] Monitoring as a Service

hpad.net/ceilometer/+spec/event-sample-plugins [5] https://blueprints.launchpad.net/ceilometer/+spec/hbase-events-feature cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate proposal - drop Postgresql configurations in the gate

continue gating against mysql only rather than postgres only? is it known that mysql is the typical choice for openstack deployments? cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

ituting the middle ie. "4724 8478". whatever we decide here, i'm all for having a consistent way of masking and minimising tokens in OpenStack. cheers, gordon chung openstack, ibm software standards___ OpenStack-dev

Re: [openstack-dev] [ceilometer] nominating Ildikó Váncsa and Nadya Privalova to ceilometer-core

> I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer +1, thanks for the effort so far. cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.opens

Re: [openstack-dev] [Ceilometer] Suggestions for alarm improvements

that what we have is the best solution. https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.o

Re: [openstack-dev] [Ceilometer]Collector's performance

ations set up better? cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer resource_list CLI command

g the performance in line with the 'seconds' expectation. cheers, gordon chung openstack, ibm software standards Matthew Treinish wrote on 17/03/2014 02:55:40 PM: > From: Matthew Treinish > To: openstack-dev@lists.openstack.org > Date: 17/03/2014 02:57 PM > Subject: [openstack

Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer resource_list CLI command

would expect sub 2 seconds would be a good target. that said, as Jay mentioned, as the load/test increases there's only so much performance you can get with hundred thousand to millions of records using an sql backend... at the very least it's going to flutuate (how much is acceptab

Re: [openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer tempest testing in gate

but that said, given the modest load of tempest tests, i would expect our sql backend be able to handle it. cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer][all] persisting dump tables after migration

traints.py cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] pyCADF 0.5 released

please report any problems here: https://bugs.launchpad.net/pycadf cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Collector no recheck the db status

k the db status > and reconnect it. so the collector service keeps useless to record the data. is this against master? does this patch resolve the issue for you? https://review.openstack.org/#/c/83595/ gordon chung openstack, ibm software standards___

[openstack-dev] [ceilometer] PTL candidacy

nstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html [4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists

Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends

a-sql https://blueprints.launchpad.net/ceilometer/+spec/tighten-model https://blueprints.launchpad.net/ceilometer/+spec/bulk-message-handling we're still prioritising design sessions but it's safe to say this session will be there: http://summit.openstack.org/cfp/details/163 cheers, gordon chung op

Re: [openstack-dev] [Ceilometer] MySQL performance and Mongodb backend maturity question

> mysql> select count(*) from metadata_text; > +--+ > | count(*) | > +--+ > | 25249913 | > +--+ > 1 row in set (3.83 sec)> > There were 25M records in one table. The deletion time is reaching an > unacceptable level (7 minutes for 4M records) and it was not increasing > in

Re: [openstack-dev] [oslo] request_id deprecation strategy question

> The issue I'm highlighting is that those projects using the code now have > to update their api-paste.ini files to import from the new location, > presumably while giving some warning to operators about the impending > removal of the old code. This was the issue i ran into when trying to switch p

Re: [openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found

just an fyi, i had same issue. i 'pip uninstall'ed all the python-*clients and it worked fine... i assume it's something to do with master (as i had it configured previously) since devstack seems to pull in pypi version. cheers, gord

[openstack-dev] [oslo] graduating oslo.middleware

hi, following the oslo graduation protocol, could the oslo team review the oslo.middleware library[1] i've created and see if there are any issues. [1] https://github.com/chungg/oslo.middleware cheers, gord ___

Re: [openstack-dev] [oslo] graduating oslo.middleware

> I left a comment on one of the commits, but in general here are my thoughts: > 1) I would prefer not to do things like switch to oslo.i18n outside of > Gerrit. I realize we don't have a specific existing policy for this, but > doing that significant > work outside of Gerrit is not desirable I

Re: [openstack-dev] [oslo] graduating oslo.middleware

> Gordon, could you prepare a version of the repository that stops with the > export and whatever changes are needed to make the test jobs for the new > > library run? If removing some of those tests is part of making the suite run, > we can talk about that on the list here, but if you can make

Re: [openstack-dev] [keystone][oslo][ceilometer] Moving PyCADF from the Oslo program to Identity (Keystone)

> > Before we move ahead, I would like to hear from the other current pycadf and > > oslo team members, especially Gordon since he is the primary maintainer. this move makes sense to me. auditing and identity have a strong link and all of the pyCADF work done so far has been connected to Keystone

Re: [openstack-dev] [oslo][nova] can't rebuild local tox due to oslo alpha packages

> I noticed yesterday that trying to rebuild tox in nova fails because it > won't pull down the oslo alpha packages (config, messaging, rootwrap). i ran into this yesterday as well. Doug suggested i update my virtualenv and that worked. i went from 1.10.1 to 1.11.x cheers, gord

Re: [openstack-dev] [ceilometer][nova] extra Ceilometer Samples of the instance gauge

> In a normal DevStack install, each Compute instance causes one Ceilometer > Sample every 10 minutes. Except, there is an extra one every hour. And a > lot of extra ones at > the start. What's going on here? instance is one meter which is generated through both polling and notifications (se

Re: [openstack-dev] [Ceilometer]How to change Keystone properties

ocol = http cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Oslo] Bringing audit standards to Openstack

ard when capturing events. cheers, gordon chung openstack, ibm software standards email: chu...@ca.ibm.com___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Bringing audit standards to Openstack

of data. the audit work will continue to be contained in Ceilometer and maybe once we have the code in and working, it'll prove itself to have greater value beyond Ceilometer. cheers, gordon chung openstack, ibm software standards___ OpenStac

[openstack-dev] [Ceilometer] what's in scope of Ceilometer

? is the consensus that Ceilometer will collect anything and everything the other projects allow for? cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com phone: 905.413.5072___ OpenStack-dev mailing list Ope

Re: [openstack-dev] [Telemetry] Time to test and import Panko

what needs to be tested here? that Ceilometer can dispatch to Panko? do we need to worry about any redirection like we had with Aodh? On 17/05/2016 8:29 AM, Julien Danjou wrote: > Hi fellows, > > I'm done creating Panko, our new project born from cutting off the event > part of Ceilometer. It's

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

i don't know if anyone is looking at this -- i'm not sure where this test is even run. i usually let mriedem yell at me but i take it he has bigger things on his plate now :) this seems like a pretty simple fix from the error output[1]. i guess my question is: should the correct fix be to cap o

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

hi, i actually told him to raise it here. since our team is scattered pretty globally, we use the ML for this when we want a few more eyes on something debatable in a patch. for me, my concern is whether there's a strong desire to have ordering of severity to be done based on context vs alphab

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

On 14/06/2016 12:10 PM, Ian Cordasco wrote: > I wonder why more projects aren't seeing this in stable/liberty. Perhaps, > ceilometer stable/liberty isn't using upper-constraints? I think oslo.utils > 3.2.0 > (https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L

Re: [openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

On 24/06/2016 9:58 AM, Julien Danjou wrote: > On Thu, Jun 23 2016, Afek, Ifat (Nokia - IL) wrote: > >> I understood that during Aodh-Vitrage design session in Austin, you had a >> discussion about Vitrage need for notifications about Aodh alarm state >> changes. >> Did you have a chance to think

[openstack-dev] [gnocchi] profiling and benchmarking 2.1.x

hi, i realised i didn't post this beyond IRC, so here are some initial numbers for some performance/benchmarking i did on Gnocchi. http://www.slideshare.net/GordonChung/gnocchi-profiling-21x as a headsup, the data above is using Ceph and with pretty much a default configuration. i'm currently

Re: [openstack-dev] [Openstack-operators] [gnocchi] profiling and benchmarking 2.1.x

test against a larger dataset going forward. also, will be testing some enhancements we've been discussing for Gnocchi 3.x hope it helps. cheers, On 25/06/2016 8:50 AM, Curtis wrote: > On Fri, Jun 24, 2016 at 2:09 PM, gordon chung wrote: >> hi, >> >> i realised i didn&#x

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

On 30/03/2016 8:06 AM, Julien Danjou wrote: > On Wed, Mar 30 2016, Chris Dent wrote: > >> Another option on the meetings would be to do what the cross project >> meetings do: Only have the meeting if there are agenda items. > > That's a good idea, I'd be totally cool with that too. We could send

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

ie. the new PTL should checkpoint with subteam leads regularly to review spec status or identify missing resources on high-priority items? as some feedback, re: news flash mails, we need a way to promote roadmap backlog items better. i'm not sure anyone looks at Road Map page... maybe we need t

[openstack-dev] [election][tc] tc candidacy

hi folks, i'd like to announce my candidacy for the OpenStack Technical Committee. as a quick introduction, i've been a contributor in OpenStack for the past few years, focused primarily on various Telemetry and Oslo related projects. i was recently the Project Team Liaison for the Telemetry p

Re: [openstack-dev] [telemetry] Newton design summit planning

seems fine to me. we still don't have a story around events. we just sort of store and dump it right now. i guess this could probably fit into ceilometer split session... or maybe everyone is cool with just pushing things to elasticsearch and letting users play with that + kibana. On 05/04/2016

Re: [openstack-dev] [all][elections] Results of the TC Election

On 08/04/2016 9:32 AM, Sheel Rana Insaan wrote: > I agree with Thierry Carrez , I think this would help. > > Along with this, we need to motivate new joiners to continue with openstack. > Most of them leave earlier or participate less due to some demotivating > factors like coding is easy but ge

Re: [openstack-dev] [all][elections] Results of the TC Election

On 08/04/2016 9:14 AM, Thierry Carrez wrote: > Eoghan Glynn wrote: >>> However, the turnout continues to slide, dipping below 20% for >>> the first time: >> >>Election | Electorate (delta %) | Votes | Turnout (delta %) >>=== >>Oc

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On 08/04/2016 1:26 PM, Davanum Srinivas wrote: > Team, > > Steve pointed out to a problem in Stackalytics: > https://twitter.com/stevebot/status/718185667709267969 > > It's pretty clear what's happening if you look here: > https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On 08/04/2016 5:23 PM, Davanum Srinivas wrote: > On Fri, Apr 8, 2016 at 5:10 PM, gordon chung wrote: >> >> >> is it actually affecting anything in the community aside from the >> reviews being useless. aside from the 'diversity' tags in governance, &

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On 11/04/2016 5:10 AM, Thierry Carrez wrote: > gordon chung wrote: >> On 08/04/2016 1:26 PM, Davanum Srinivas wrote: >>> Steve pointed out to a problem in Stackalytics: >>> https://twitter.com/stevebot/status/718185667709267969 >>> >>> It

Re: [openstack-dev] [ceilometer][tempest] disabling 'full' tempest tests for ceilometer changes in CI

i'd be in favour of dropping the full cases -- never really understood why we ran all the tests everywhere. ceilometer/aodh are present at the end of the workflow so i don't think we need to be concerned with any of the other tests, only the ones explicitly related to ceilometer/aodh. On 12/04/

Re: [openstack-dev] [ceilometer][horizon] metric-list not complete and show metrics in horizon dashboard

On 12/04/2016 7:47 AM, Safka, JaroslavX wrote: > * > And my question is: How is connected the database table meter and the command > metric-list? i assume you mean meter-list. it uses a combination of data from meter table and resource table[1]. this is because it lists all the meters and

[openstack-dev] [Openstack] [Ceilometer][Architecture] Transformers in Kilo vs Liberty(and Mitaka)

hi Nadya, copy/pasting full original message with comments inline to clarify some comments. i think a lot of the confusion is because we use pipeline.yaml across both polling and notification agents when really it only applies to latter. just an fyi, we've had an open work item to create a po

Re: [openstack-dev] [Openstack] [Ceilometer][Architecture] Transformers in Kilo vs Liberty(and Mitaka)

On 14/04/2016 5:28 AM, Nadya Shakhat wrote: > Hi Gordon, > > I'd like to add some clarifications and comments. > > this is not entirely accurate pre-polling change, the polling agents > publish one message per sample. not the polling agents publish one > message per interval (multiple

Re: [openstack-dev] [telemetry][vitrage] Joint design sesssion in Austin

cool! either works for me. prefer earlier slot if it's just the one. On 14/04/2016 5:07 AM, Julien Danjou wrote: > Hi folks, > > Vitrage doesn't have any track/session at the summit, and we Telemetry > have a bunch of spare ones, so I figured we should use one to meet and > chat a bit about how ou

Re: [openstack-dev] [searchlight] [ceilometer] [fuel] [freezer] [monasca] Elasticsearch 2.x gate support

On 24/04/2016 6:53 PM, Julien Danjou wrote: > On Mon, Apr 18 2016, McLellan, Steven wrote: > > Hi Steven, > > […] > >> * Have you tested with ES 2.x at all? >> * Do you have plans to move to ES 2.x? > > I don't think we have tested that nor anyone

Re: [openstack-dev] [puppet] Stepping down from core

great work Yanis! (i am talking about your ping pong skills). all the best in your new adventure. On 10/05/2016 3:52 AM, Yanis Guenane wrote: > Hello all, > > After the Mitaka summit, my main area of focus at work changed and I > couldn't find the necessary time to help anymore on the puppet modu

Re: [openstack-dev] [api] [senlin] [keystone] [ceilometer] [telemetry] Questions about api-ref launchpad bugs

On 10/05/2016 9:36 AM, Anne Gentle wrote: > > It's a small set of files: > https://github.com/openstack/api-site/tree/master/api-ref/source/telemetry/v2 > How about I ask someone to do the conversion and add it to > https://github.com/openstack/ceilometer? I have someone in mind who's > looking f

Re: [openstack-dev] [tc] supporting Go

wow. everything you did below is awesome. respect. not a swift dev so i won't suggest what to do as i'm sure you've put a lot more thought into adopting golang than i have. personally, i think it's easier to find design flaws in something that is (perceived) slow and these design optimisations

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

On 12/05/2016 1:47 PM, Morgan Fainberg wrote: > > > On Thu, May 12, 2016 at 10:42 AM, Sean Dague > wrote: > > We just had to revert another v3 "fix" because it wasn't verified to > work correctly in the gate - https://review.openstack.org/#/c/315631/ > > While

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

you can consider ceilometer database (and api) as an open-ended model designed to capture the full fidelity of a datapoint (something useful for auditing, post processing). alternatively, gnocchi is a strongly type model which captures only required data. in the case of ceilometer -> gnocchi, t

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

> It makes for a crappy user experience. Crappier than the crappy user > experience that OpenStack API users already have because we have done a > crappy job shepherding projects in order to make sure there isn't > overlap between their APIs (yes, Ceilometer and Monasca, I'm looking > directly at y

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 27/01/2016 10:51 AM, Jay Pipes wrote: > On 01/27/2016 12:53 PM, gordon chung wrote: >>> It makes for a crappy user experience. Crappier than the crappy user >>> experience that OpenStack API users already have because we have done a >>> crappy job shepherding

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 28/01/2016 1:03 AM, Steven Dake (stdake) wrote: > Choice is one of life's fundamental elements that make life interesting. > Let the Operators choose what they wish based upon technical merits rather > then "who was first to publish a project". yes, it's nice when competing entities exists in

[openstack-dev] log processing project

hi folks, just querying before i do anything, i was wondering if there's a log processing project out there? or is everyone just using ELK stack? cheers, -- gord __ OpenStack Development Mailing List (not for usage questi

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

On 28/01/2016 3:37 PM, Jeremy Stanley wrote: > On 2016-01-28 19:40:20 + (+), Dave Walker wrote: > [...] >> However, pip 8 was released around the same time as the tarballs were >> attempted to be generated. Most of the projects are OK with this, but >> ceilometer declares pbr!=0.7,<1.0,>

Re: [openstack-dev] [ceilometer] :Regarding wild card configuration in pipeline.yaml

I have a meter subscription m1.* for publisher p1 and I need a subset of m1.* notifications for ex:m1.xyz.* for publisher p2. If we add p2 to already exisiting sink along with p1, p2 will get other notification's along with m1.xyz.* which are not needed for p2. To avoid this we had the follo

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On 29/01/2016 10:48 AM, Foley, Emma L wrote: >> So, metrics are grouped by the type of resource they use, and each metric >> has to be listed. >> Grouping isn't a problem, but creating an exhaustive list might be, >> since there are 100+ plugins [1] in collectd which can provide >> statistics, a

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On 28/01/2016 2:32 AM, Foley, Emma L wrote: > So, metrics are grouped by the type of resource they use, and each metric has > to be listed. > Grouping isn't a problem, but creating an exhaustive list might be, since > there are 100+ plugins [1] in collectd which can provide statistics, although

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

On 29/01/2016 1:27 PM, Jeremy Stanley wrote: > On 2016-01-29 14:14:48 + (+), gordon chung wrote: >> trying to understand the situation here. isn't this all managed by >> global-reqs? an incompatible pip and pbr were release so now we >> can't build?

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

On 30/01/2016 7:54 AM, Dave Walker wrote: > On 29 January 2016 at 20:36, Jeremy Stanley wrote: >> On 2016-01-29 19:34:01 + (+), gordon chung wrote: >>> hmm.. that's unfortunate... anything we need to update so this doesn't >>> happen again? or just a

Re: [openstack-dev] [all] towards a keystone v3 only devstack

yeah... the revert broke us across all telemetry projects since we fixed plugins to adapt to v3. i'm very much for adapting to v3 since it's lingered around for years. i think given the time lapsed, if it breaks them, tough. the only issue i had with original patch was it merged on a Friday with

Re: [openstack-dev] [all] towards a keystone v3 only devstack

On 02/02/2016 8:45 AM, Jordan Pittier wrote: On Tue, Feb 2, 2016 at 2:09 PM, gordon chung mailto:g...@live.ca>> wrote: yeah... the revert broke us across all telemetry projects since we fixed plugins to adapt to v3. i'm very much for adapting to v3 since it's lingered aro

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On 03/02/2016 9:16 AM, Foley, Emma L wrote: > AFAICT there's no such thing out of the box but it should be fairly > straightforward to implement a StatsD writer using the collectd Python plugin. > Simon > > [1] https://collectd.org/documentation/manpages/collectd-python.5.shtml

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 03/02/2016 10:38 AM, Sam Yaple wrote: On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: On 2016-02-03 14:32:36 + (+), Sam Yaple wrote: [...] > Luckily, digging into it it appears cinder already has all the > i

Re: [openstack-dev] [all] the trouble with names

On 04/02/2016 9:04 AM, Morgan Fainberg wrote: On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann mailto:d...@doughellmann.com>> wrote: Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500: > A few issues have crept up recently with the service catalog, API > headers, API end points, and

[openstack-dev] [telemetry][aodh] announcing Liusheng as new Aodh liaison

hi, we've been searching for a lead/liaison/lieutenant for Aodh for some time. thankfully, we've had a volunteer. i'd like to announce Liusheng as the new lead of Aodh, the alarming service under Telemetry. he will help me with monitor bugs and specs and will be another resource for alarming r

Re: [openstack-dev] [all] the trouble with names

On 05/02/2016 1:22 PM, Ryan Brown wrote: > For example, I think "containers" will be one of those words that > everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for > projects to say "hm, someone else wants this" would be nice. too late, magnum[1] beat you to it. i'm not sure what

Re: [openstack-dev] [all] Proposal for having a service type registry and curated OpenStack REST API

On 08/02/2016 7:13 AM, Sean Dague wrote: > On 02/07/2016 08:30 AM, Jay Pipes wrote: >> On 02/04/2016 06:38 AM, Sean Dague wrote: >>> What options do we have? >> >>> 2) Have a registry of "common" names. >>> >>> Upside, we can safely use common names everywhere and not fear collision >>> down the

Re: [openstack-dev] [gate] RFC dropping largeops tests

makes sense to me. thanks for concise update and tracking this. On 10/02/2016 7:59 AM, Davanum Srinivas wrote: > +1 from me > > On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote: >> On 02/10/2016 07:33 AM, Sean Dague wrote: >>> >>> The largeops tests at this point are mostly finding out that some

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 10/02/2016 11:35 AM, Thierry Carrez wrote: > Chris Dent wrote: >> [...] >> Observing this thread and "the trouble with names"[1] one I get >> concerned that we're trending in the direction of expecting >> projects/servers/APIs to be done and perfect before they will ever >> be OpenStack. This,

  1   2   3   4   5   >