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

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

there are no meetings given sparse participation. regardless, i've added 
a review.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

https://gnocchi.xyz/gnocchiclient/shell.html#openstack-keystone-authentication 
you're missing OS_AUTH_TYPE

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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/openstack/glance/commit/106de18f326247e8d3f715452665b96dade6d2bc
 
fixes it... or it seems i can run devstack.

carry on :)

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
> the merit of using triggers to manage migrations. There were some
> pretty strong (and supported) assertions that triggers are not a good
> choice.

was there a resolution for this? iiuc, pgsql is not supported by glance 
based on: 
https://github.com/openstack/glance/commit/f268df1cbc3c356c472ace04bd4f2d4b3da6c026

i don't know if it was a bad commit but it seems to break any case that 
tries to use pgsql (except if the db has all migrations applied already).

not making an opinion here, just asking as i have a patch[1] to remove 
pgsql gate from one of the telemetry projects that was affected and 
wondering if i should proceed.

[1] https://review.openstack.org/#/c/542240/

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 we also can't consume versioned notifications 
exclusively or we'll miss data.

apologies, if this is captured somewhere, just figured this is easier.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 strategies and tactics used to survive
> adolescence are no longer effective and there's a chafing that won't
> subside until there's been a change in behavior and expectations; an
> adaptation to new constraints and realities.
> 

i love this intro. when does your coming-of-age book come out? :)

> 
> ## OpenStack-wide Goals
> 
> These need to be validated by the community, but they are not [getting
> as much
> feedback](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-23.log.html#t2018-01-23T09:16:51)
>  
> 
> as hoped. There are different theories as to why, from "people are
> busy", to "people don't feel empowered to comment", to "people don't
> care". Whatever it is, without input the onus falls on the TC to make
> choices, increasing the risk that the goals will be perceived as a
> diktat. As always, we need to work harder to have high fidelity
> feedback loops. This is especially true in our "mature" phase.
> 

i think this probably links back to the issues with openstack-specs. 
maybe it's because the tasks aren't flashy enough, maybe it's because 
people have too much work. personally, i've never had a user/anyone tell 
me that "goal X would be useful in your project" and considering how 
silo'd the projects are, looking outside my project of focus is not very 
high on priority.

> 
> ## PTL Balance
> 
> In [this morning's office
> hours](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-18.log.html#t2018-01-18T15:43:53)
>  
> 

this link is wrong! you made me read stuff i didn't want to read! :P i'm 
going to guess it roughly starts here: 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-23.log.html#t2018-01-23T09:48:03

> we had a discussion about ways to help the PTL role (especially of the
> larger and most active projects) be more manageable and balanced. The main
> challenge is that as currently constituted, the person in the PTL role
> often needs to keep the state of the whole project in their head.
> 
> That's not sustainable.
> 

if i were to (potentially) oversimplify it, i would agree with this 
statement: 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-23.log.html#t2018-01-23T10:12:22

i don't believe a PTL necessarily has to keep the whole state of the 
project in their head (although they could). ultimately, it's up to the 
PTL to decide how much they're willing to defer to others.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 the extension to '.html', and 
> finally open it in a browser. I've tried this with both Chrome 
> 63.0.3239.132 and Firefox 57.0.4, OS Ubuntu 16.04.
> 
> Is anyone else seeing this issue?

unless you have some special extension on all browsers it's probably 
because of your company's proxy. it happens to me as well at work 
depending on what network i'm connected to.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 unofficially/transparently 
been telling people to switch to Gnocchi (or whatever target you want to 
put into publisher) for longer than that as the legacy api/storage 
hasn't been touched meaningfully since 2015.

given the realities of the project and OpenStack, our project was just 
more proactive in culling stale and/or unusable code.

as it stands, ceilometer solely generates/normalises data about 
openstack resources and publishes data to consumers. other services are 
required to leverage and add value to the data.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105042.html

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 don't believe it was 
even packaged in Pike (at least i don't have have an rpm for it in my 
environment).

>>
>> http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/connection.py#n234
>>
>> We can either keep it there indefinitely (there is no cost to keeping
>> it, other than that one "self._load('metric')" line) - or we could take
>> this opportunity to purge it from sdk as well.
>>
>> BUT - if we're going to remove it from SDK I'd rather we do it in the
>> very-near-future because we're getting closer to a 1.0 for SDK and once
>> that happens if ceilometer is still there ceilometer support will remain
>> until the end of recorded history.

if it was removed from SDK, does it affect installations from pre-Pike? 
technically the API code exists prior to Pike (but we've been telling 
people for a year+ prior to that, to stop using it). if it only affects 
Queens onwards, i'm an easy yes to removing for openstacksdk 1.0.

>>
>> We could keep it and migrate the heat/mistral/rally/aodh
>> ceilometerclient uses to be SDK uses (although heaven knows how we test
>> that without a ceilometer in devstack)
>>
i'm guessing it's not tested anywhere as we've removed the API code for 
a few months now and have not heard anyone complain about a broken gate.

> If ceilometer itself is deprecated, do we need to maintain support
> in any of our tools?

just to clarify, ceilometer itself is **not** deprecated. it just 
doesn't have an API as there is currently nothing to query/interact with 
remotely. jd had an idea how to manage/monitor existing agents but that 
is unrealised currently.

the workflow remains as it has been:
- ceilometer agents generate/normalise data relating to openstack resources
- ceilometer data is pushed to a configurable target for consumption
- gnocchi, panko, whatever you want
- you interact with the data according to the specific targets.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 an about to be retired
> project.  It shouldn't stop the
> discussions around retiring a project just a data point for decision making.

this is a very valid point. this is something overlooked on my part.

out of curiosity, but what's the effect have 'retiring' something in 
openstack and having services still referencing ceilometerclient? is it 
that it will not get packaged in centos/ubuntu and therefore will be 
missing requirements when installed? or can you not build the package at 
all?

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 3.2.0
Using API: QEMU 3.2.0
Running hypervisor: QEMU 2.9.0

and it works fine. possibly related to your qemu version?

> 
> The fall back is so coarse, do you think we should have it?

are you overcommiting your cpu? that is exactly the case that breaks 
down as the patch i sent you mentions. please look at the bugs and 
related threads on that patch.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 using this method as line 183
> we can not get cpu util 100, always 50 or 52.
> 
> The test script is here(run on compute node, and there is only one vm)
> #!/bin/bash
> 
> cpu_time_begin=`virsh  domstats --cpu-total | grep cpu.time| awk -F
> '=' '{print $2}'`
> sleep 1
> cpu_time_end=`virsh  domstats --cpu-total | grep cpu.time| awk -F '='
> '{print $2}'`
> 
> cpu_util=$(((cpu_time_end - cpu_time_begin) * 100 / 10**9))
> echo "cpu util is ", $cpu_util
> 
> The output will be 100 or 101, if we divide cpu_util with core number,
> then we definitely get 50. But in the vm we watch with top and find
> all core is 99%.
> 
> Can someone tell me why we only use cpu_time here? May be we should
> add cpu.user and cpu.system? It is insane only get 50% when the vm is
> totally 100%
> 

does adding cpu.user and cpu.system make sense or are you just adding 
random numbers in hopes it gets you to right number? :P

i'm not a libvirt/qemu dev but it seems cpu.system is already part of 
cpu.time[1]

if you look further into the code, you should see that the agent tries 
to first use vcpu.*.time to build more accurate cpu.time value. if you 
look at patch[3], it should give you more information as to why and what 
requirements you need.


[1] 
https://stackoverflow.com/questions/40468370/what-does-cpu-time-represent-exactly-in-libvirt
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L175-L176
[3] 
https://github.com/openstack/ceilometer/commit/a4ec0911a3ed4137a1c832fbd7c8fee80c7d4601

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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:
>>>> 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 gnocchi.
>> Oh, I do not quite understand, can you give more details?
>> I do not know change which part of workflow in ceilometer.
>>

i don't openstack on weekends.

what needs to change is that rate aggregate needs to be enabled for 
specific meters such as cpu. this will effectively calculate the cputime 
per second. then you apply the same maths on timeseries that transformer 
does when you query gnocchi.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 gnocchi.


-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 and can also have mathematical 
operations applied to it. there are some examples here: 
https://gnocchi.xyz/rest.html#examples. i imagine we'll change the gate 
workflow to that eventually.

you will still need partitioning for HA of central agents... and 
currently, the only way to get batch support is with workload_partitioning.

but yes, moving the transformation to storage will provide the most 
durable solution for transformations.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 measurement are measuring so 
i'm unsure how to name the measurement in ceilometer so a user can 
understand what it's measuring.

the following are probably stupid questions but i see it measures two 
different resource types, a 'pool' and a 'backend' and they are 
ultimately tied to a host. are these measuring the amount of disk on 
each host? our pools confined to a host?

anyone with better knowledge is welcomed to take over my patch.

[1] https://review.openstack.org/#/c/206923
[2] https://review.openstack.org/#/c/526538

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 stats be pushed to ceilometer
>> rather than pulled.
> Yes, but for the wrong reasons. Having a component sending a batch of
> notification every hour without any configuration knob and granularity
> choice is a PITA for the users. Plus it ususally comes from a single
> point (of failure?).

well you can configure it, just at a per service level.. but that's a 
fair point.

> 
> Ceilometer would do a better job than $project at getting this info, if
> said project(s) would offer a proper and performant API to retrieve them
> efficiently.

but at the end of the day, are you building for reality or for some 
personal ideal scenario? :p is there a service that offers a stats endpoint?

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 send samples to gnocchi tcp server.
> 

oh sorry, i meant "protect you against". i'm just wondering how this tcp 
server authenticates? and if not, why not just have two APIs where one 
is user facing and authenticates, and internally another that doesn't 
for ceilometer->gnocchi?

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
>  >>       ceilometer unpacks them and sends them one by one to the pipe
>  >>       ceilometer.pipe.*, this will make the consumer slow. Right now,
>  >> the rabbit_qos_prefetch_count to 1. If we sent it to 10, the connection
>  >> will be reset
> 
>  > currently, i believe rabbit_qos_prefetch_count will be set to whatever
>  > value you set batch_size to.
> You mean in the past, it can not be set to whatever?
> We test newton, and find under 1k vm, if we open workload partition,
> it will be reset regularly.
> 
>  >i'll give a two part answer but first i'll start with a question: what
>  >version of oslo.messaging do you have?
> 
> newton 5.10.2
> 

i just checked, oslo.messaging==5.10.2 has the offending patch that 
decreases performance significantly. as newton is EOL, it seems you have 
a few choices:
- revert to 5.10.1 but i'm not sure if that reintroduces old bugs
- manually patch your oslo.messaging with: 
https://review.openstack.org/#/c/524099
- pull in a newer oslo.messaging from another branch (fix is unreleased 
currently)
- manually patch notification agent to use multiple threads[1] (but this 
will possibly add some instability to your transforms)
- disable workload_partitioning

option 2 or 5 are probably the safest choices depending on your load.

[1] 
https://github.com/openstack/ceilometer/blob/newton-eol/ceilometer/notification.py#L305-L307

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 
may create additional load.

in general, there's a preference that stats be pushed to ceilometer 
rather than pulled.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 we want

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
>       ceilometer.pipe.*, this will make the consumer slow. Right now, 
> the rabbit_qos_prefetch_count to 1. If we sent it to 10, the connection 
> will be reset

currently, i believe rabbit_qos_prefetch_count will be set to whatever 
value you set batch_size to.

>       regularly. Under this pos, the consumer will be very slow in 
> workload partition. If you do not use workload partition, the messages 
> can all be consumer. If you use it, the messages in pipe will be piled 
> up more and more。

what is "pos"? i'm not sure it means the same thing to both of us... or 
well i guess it could :)

>      May be right now workload partition is not a good choice? Or any 
> suggestion?
> 

i'll give a two part answer but first i'll start with a question: what 
version of oslo.messaging do you have?

i see a performance drop as well but the reason for it is because of an 
oslo.messaging bug introduced into master/pike/ocata releases. more 
details can be found here: 
https://bugs.launchpad.net/oslo.messaging/+bug/1734788. we're working on 
backporting it. we've also done some work regarding performance/memory 
to shrink memory usage of partitioning in master[1].

with that said, there are only two scenarios where you should have 
partitioning enabled. if you have multiple notification agents AND:

1. you have transformations in your pipeline
2. you want to batch efficiently to gnocchi

if you don't have workload partitioning on, your transform metrics will 
probably be wrong or missing values. it also won't batch to gnocchi so 
you'll see a lot more http requests there.

so yes, you do have a choice to disable it, but the above is your tradeoff.

[1] 
https://review.openstack.org/#/q/topic:plugin+(status:open+OR+status:merged)+project:openstack/ceilometer

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 different the roadmap was vs 
reality. thanks for the explanation and link to resources.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 misunderstanding of not just how
>    open source works in OpenStack, but how open source works in
>    general.

was this topic to discuss how to implement an existing roadmap or how 
the board/tc should build a roadmap or something else completely? if the 
first, is there a link to this 'roadmap'?

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 this[1]. 
basically everything we plan on doing to interact with ceilometer (ie. 
monitoring ceilometer services) will leverage something completely new 
when it does get implemented. reusing the current client would just be 
bloat.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2017-11-23.log.html#t2017-11-23T20:55:22

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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.
>
as you wish, as long as you're aware that no one reads it :). we do 
track features under bugs in launchpad[1] and just mark them as wishlist 
normally but i'm not going to stop you from creating a bp. you'll just 
need to ping someone to mark it as implemented when the time comes.

[1] https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 it here on ML. in this case, it seems 
like a pretty regular feature addition.

> 
> Wrt the compression blueprint,  locally we subclassed the base python 
> rotating file handler class in order to optionally compress the file as 
> part of the “shouldRollover” stage.
> 

sounds good.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 be an optional parameter in the pipeline definition in 
> /etc/ceilometer/pipeline.yaml
> e.g.
> 
> name: meter_file
> 
> meters:
> 
>      - "*"
> 
> publishers:
> 
>      - file:///var/test?max_bytes=1000_count=5=true
> 
> oagain,
> minimizing disk usage and minimizing network bandwidth in FTP-ing these 
> files off server.

seems like a good idea. just curious, how would you implement this?

> 
> 2.CSV (Comma Separated Values) File Format
> 
> oCSV is widely supported for many off-box Statistical Analysis-type 
> Tools; especially in Telecom,
> 
> oagain this would be done as an optional argument to the file publisher
> 
> §the existing format (python dictionary print) would remain as the 
> default format
> 
> §‘format=csv’ would be the argument added to the publisher line in order 
> to enable CSV format
> e.g.
> 
> name: meter_file
> 
> meters:
> 
>      - "*"
> 
> publishers:
> 
>      - file:///var/test?max_bytes=1000_count=5=csv
>
this sounds like a good idea. i believe there was a bug previously that 
suggested cleaning up the output of the file publisher/dispatcher so 
it's not just dumping random blurbs of json. i think the proposed 
format=csv trigger makes sense.

> 
> I think these would be valuable addons to the Ceilometer File Publisher,
> 

agreed! thanks for suggesting them. this is me assuming you (or a 
colleague) will implement this :)

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 http://paste.openstack.org/show/623909/
> And i also find the ceilometer-pipe-meter_source:meter_sink-queue
> always has many messages in it.
> Does anyone met this before, or some suggestions can share? Thanks a
> lot...
>

what version of code was this? i just found a pretty big bug that 
basically makes partitioning completely broken. this would affect 
stable/pike and master

cheers.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 patch and ran with it.

for the record, we don't have an api in ceilometer and we also bench'd 
the performance when we originally adopted in gnocchi[1] (spoiler: it's 
much faster). but yeah, it dumps differently in some cases.

[1] https://review.openstack.org/#/c/386744

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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):
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 250, in
> wrapper
> 2017-10-21 03:33:19.779 225636 ERROR root return infunc(*args, **kwargs)
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/base.py", line
> 203, in _runner
> 2017-10-21 03:33:19.779 225636 ERROR root batch_size=self.batch_size,
> batch_timeout=self.batch_timeout)
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/base.py", line
> 52, in wrapper
> 2017-10-21 03:33:19.779 225636 ERROR root msg = func(in_self,
> timeout=timeout_watch.leftover(True))
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line
> 286, in poll
> 2017-10-21 03:33:19.779 225636 ERROR root
> self._message_operations_handler.process()
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line
> 89, in process
> 2017-10-21 03:33:19.779 225636 ERROR root task()
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py",
> line 251, in acknowledge
> 2017-10-21 03:33:19.779 225636 ERROR root self._raw_message.ack()
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/kombu/message.py", line 88, in ack
> 2017-10-21 03:33:19.779 225636 ERROR root
> self.channel.basic_ack(self.delivery_tag)
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/amqp/channel.py", line 1583, in basic_ack
> 2017-10-21 03:33:19.779 225636 ERROR root self._send_method((60, 80), args)
> 2017-10-21 03:33:19.779 225636 ERROR root File
> "/usr/lib/python2.7/site-packages/amqp/abstract_channel.py", line 50, in
> _send_method
> 2017-10-21 03:33:19.779 225636 ERROR root raise
> RecoverableConnectionError('connection already closed')
> 2017-10-21 03:33:19.779 225636 ERROR root RecoverableConnectionError:
> connection already closed

what's the oslo.messaging version? i feel like this is something on 
oslo.messaging and it does sound familiar to possibly it's fixed.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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.
>       If anyone know this, please point it out. Thanks
and you see no errors in notification-agent? does it start with a 
consumer or is there never a consumer?

are you setting pipeline_processing_queues=1 as a test? because it sort 
of defeats purpose.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 metric measures data get 
> processed as soon as possible, metric processing delay is set to 10s, 
> and ceilometer polling interval is 30s.

are you batching the data you push to gnocchi? in gnocchi4.1, the redis 
driver will (attempt to) process immediately, rather than cyclically 
using the metric processing delay.

> 
> when the backend of incoming and storeage is set to ceph, the average of 
> "gnocchi status"
> shows that there are around 7000 measures waiting to be process, but 
> when changing incoming and storage backend to Redis, the result of 
> gnocchi status shows unprocessed measures is around 200.

i should clarify, having a high gnocchi status is not a bad thing, ie, 
if you just send a large spike of measures, it's expected to jump. it's 
bad if never shrinks.

that said, how many workers do you have? i have 18 workers for 20K 
metrics and it takes 2minutes i believe? do you have debug enable? how 
long does it take to process metric?

when i tested gnocchi+ceph vs gnocchi+redis, i didn't see a very large 
difference in performance (redis was definitely better though). maybe 
it's your ceph environment?

> 
> we try to add more metricd process on every controller nodes, to improve 
> the performance of
> calculate and writing speed to storage backend but  have little effect.

performance should increase (relatively) proportionally. ie. if you 2x 
metricd, you should perform (almost) 2x quicker. if you add 5% more 
metricd, you should perform (almost) 5% quicker.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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] https://review.openstack.org/#/c/511870/1

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 those that moved off legacy storage.

> 
> I'm starting to think it's time to stop carrying this dead code around.
> The biggest reason, other than cleaning our code base, is to stop having
> confusing options such as, e.g., "time-to-live" that make users being
> confused about where to configure the expiration of their metrics.
> 
> The question, is there any compelling reason to keep this deprecated
> stuffs for one more cycle?
> 
i'm ok with removing it. the amount of questions i've fielded related to 
Ceilometer API has dropped over the year we've officially deprecated 
it[1]. more importantly, we've had arguably no non-trivial patches to 
improve this legacy code for over 2 years so it's probably best to 
remove it so any new users don't read an old doc and attempt to install 
ceilometer storage.

i just checked docs and the install guide docs back to newton already 
tell people to use Gnocchi or something else.

tl;dr let's burn this down unless some hidden figure who's contributing 
speaks up.

[1] 
https://github.com/openstack/ceilometer/commit/6616a714009a80c7484fa2292c2331868617cb9c#diff-074c02939ac2ca794f659d87981d2220

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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, gnocchi status shows there is always few metric to process.
>>
>> Is Redis a recommend storage backend ?
> 
> Redis is recommended as an incoming measures backend, not really as a
> storage – though it really depends on the size of your installation.
> 
> Up until 4.0 version, Gnocchi process metrics every
> $metricd.metric_processing_delay seconds. With version 4.1 (to be
> released), the Redis incoming driver has a more realtime processing
> delay which avoids having to poll for incoming data.
> 

what Julien said :)

redis as a storage driver really depends on how you setup persistence[1] 
and how much you trust it[2].

would love to see your redis vs ceph numbers compared to mine[3] :)

[1] https://redis.io/topics/persistence
[2] https://aphyr.com/posts/283-jepsen-redis
[3] https://medium.com/@gord.chung/gnocchi-4-introspective-a83055e99776 
(tested part of 4.1 optimisations)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 was a plugin system.

>
> So, the future of "Horizon panel of Gnoochi/Adoh Services" completely
> relies on the telemetry team.
> Gnocchi is now a separate project from OpenStack, but the situation is
> totally same.

i was under impression Aodh CRUD actions were supported in horizon based 
on conversations i had with developer a few cycles back. i guess not.

Sudheer, the other gnocchi devs can correct me if i'm wrong, but 
supporting gnocchi in horizon is not on our roadmap. we will go to 
grafana route since it's a common monitoring/metric interface. you are 
welcome to try to incorporate grafana into horizon's plugin system if 
it's possible (and you really need horizon+gnocchi)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 I set admin_project_domain_name and admin_project_name , only then do the 
> non admin projects have the header set to False.

apologies, do you have more details on what 'X-Is-Admin-Project' is? i'm 
not familiar with this header.

currently, the behaviour is that:
- a member of a project can only see its own events
- an admin of a project can see all the events of a project (and any 
events without any project associated with it)

if this is the way of denoting a user is a 'super-admin' that has access 
to all events, i'm ok with it.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 
timestamp it's actually recorded in the db. because of that, if we 
record the following(msg_id, timestamp, traits):

(event1, 01:00, {})
(event2, 01:10, {})
(event4, 01:30, {})

if a new event comes in as (event3, 01:20, {}), it will be invisible to 
the user if they "get events" with marker=event4 because while it is 
"newer" in terms of when it was recorded, it's not newer in terms of 
event timestamp.

i imagine if we were to support the ability to see event3 even if the 
marker is event4, we'd need to do what Jay suggested, and add a 
recorded_at/created_at field. supporting sorting by id as i previously 
suggested is probably not a great idea since id is implementation details.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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:
>> On Wed, Aug 30, 2017 at 4:22 PM, gordon chung <g...@live.ca> wrote:
>>> ah, i see. iirc, we can choose what we sort on. can this be solved by
>>> just passing in a different sort key? or maybe we need to support
>>> returning results without sort.
>>
>> I thought about this. The key issue I see here is that the api does
>> not include "id" sort key to the result. Because of this api clients
>> can't specify a value of marker that points to the next batch of
>> events. And I believe we should think carefully about exposing this
>> filed because it may be meaningless depending on a storage back-end.
>>
>> Actually, cursors are intended to solve this issue by specifying a
>> value of marker explicitly without making an assumption what marker
>> is.
>>
>> I attached a prototype. It is based on stable/ocata branch. I did not
>> replace existing pagination and just provided another URL route to use
>> cursors. But, I think it is possible to replace current pagination
>> logic with cursors, because if a storage back-end understands markers
>> it can specify the value explicitly.
>>

sorry, i thought you were going to post your patch to gerrit.

i just took a look at your patch. you can correct me if i misunderstand 
your patch but it just seems that you want to add support to use id as a 
marker, specifically the following:

+marker = models.Event(None, None, None, None)
+marker.id = cursor
+sort_keys = ['id']
+sort_dirs = ['asc']
+query = oslo_sql_utils.paginate_query(
+query, models.Event, limit, sort_keys,
+sort_dirs=sort_dirs, marker=marker)

the one concern i have with raising id is because its just an 
autoincremented number (i believe) and it has no meaning outside of the 
db. i also don't believe it exists in any of the other backends.

based on the code above, i would imagine the equivalent could be 
achieved by just sorting by id and continuing to use message_id as a 
marker. (sorting by id might not be necessary but sql apparently doesn't 
guarantee default order)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 ones. We would like to know what are your use cases 
> towards our notification interface and we also would like to get any 
> type of feedback about the interface (both the old and the new one). 
> Based on this information we can make better decision where to focus our 
> development effort. As a good example we already have a  cooperation 
> with the searchlight project to enhance nova's versioned notification 
> interface based on their needs [3].

ceilometer uses it to create events and meters. events just capture the 
message as is and might strip out some superfluous details. meters are 
numerical values (associated with time). in both cases, we have yaml 
files where we just define 'if message event_type equals blah, strip out 
values x, y, and z'[1][2]

we don't use versioned notifications but if we had resources we might[3]

> 
> I opened an etherpad [4] to collect the projects and the feedback and we 
> can go through that feedback in the PTG to define some actions.

most of us wont' be at PTG. if you find Hanxi Liu, then you might have 
someone with some knowledge of telemetry projects. we can be reached on 
irc or ML regardless.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/data/meters.d/meters.yaml
[3] https://bugs.launchpad.net/ceilometer/+bug/1665449

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 current sorting used for
> pagination.

ah, i see. iirc, we can choose what we sort on. can this be solved by 
just passing in a different sort key? or maybe we need to support 
returning results without sort.

> 
> I look for a way to go through events in order determined by the "id"
> field. The "id" field is not exposed via api because it is internal
> part of storage implementation. We can't use it in api calls.
> So, I proposed cursor api as an independent from storage
> implementation way to get events in the order they appear in a
> database.
> 
>> is cursor code part of oslo.db? the one issue i see is we'll need to
>> change api results which means we need to do some versioning changes as
>> well (not a blocker, just another discussion and more work)
> Actually, cursor is not more than the pagenate_query from oslo.db. It
> just uses the "id" field as a sort key.
> 
> Can I share patch with the prototype, maybe it will help in the discussion?

if you already have the code, go for it! :)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 pagination. So, the following case is possible:
> 
> Before the first request we had the following events in database:
> +---+--+
> || message_id1 | 2017-08-29T00:05.00 ||
> +---+--+
> || message_id2 | 2017-08-29T00:06.00 ||
> +---+--+
> || message_id3 | 2017-08-29T00:08.00 ||
> +---+--+
> 
> During the first request we got all three events:
> GET /v2/events?limit=3
> 
> After the request some new events were added:
> +---+--+
> || message_id1 | 2017-08-29T00:05.00 ||
> +---+--+
> || message_id2 | 2017-08-29T00:06.00 ||
> +---+--+
> || message_id4 | 2017-08-29T00:07.00 ||
> +---+--+
> || message_id3 | 2017-08-29T00:08.00 ||
> +---+--+
> || message_id5 | 2017-08-29T00:09.00 ||
> +---+--+
> || message_id6 | 2017-08-29T00:09.00 ||
> +---+--+
> 
> To proceed next we set marker to message_id3:
> GET /v2/events?marker=message_id3=3
> 
> In this case we will get only two new events (message_id5, message_id6). 
> To get message_id4 we need to make the first request again.

i'm having trouble understanding the issue. the marker (message_id in 
this case) denotes the starting point of query. not sure why you would 
expect message_id4 to show up if message_id3 is newer.

> 
> That all makes difficult such scenarios when API clients need to process 
> events as they appear in database.
> 
> I'd like to discuss how we can extend the current API to provide a way 
> to go through all events in the order they were stored in database.
> 
> It looks like cursor API might be useful in this case. We can introduce 
> new "cursor" query parameter. It will work as a marker for pagination, 
> but will determine "special" sorting of events. In this case the request 
> might look like:
> GET /v2/events?cursor=-1=100
> 
> The response will return a list of events and next cursor:
> {
>  events: []
>  next_cursor: 12345
> }
> 
> So, a request to get the next portion of events will look like:
> GET /v2/events?cursor=12345=100
> 

is cursor code part of oslo.db? the one issue i see is we'll need to 
change api results which means we need to do some versioning changes as 
well (not a blocker, just another discussion and more work)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 are numbers i got using a ceph backend with gnocchi v3[1]. i 
should mention that v3 wasn't targeting write performance improvements 
(not directly). for reference, i think my ceph cluster had 30 OSDs.

the actual write throughput will depend on the driver you select (redis 
probably fastest, ceph a close second) and as jd mentioned, the batch sizes.

[1] https://www.slideshare.net/GordonChung/gnocchi-v3/18

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 Ceilometer handles the actual 
generation of both events and metrics, the latter being the one you want 
it seems. Gnocchi is used for optimised time-series metric storage.

unfortunately, i don't believe anyone from Telemetry teams are attending 
the PTG but we can be reached on ML or #openstack-telemetry.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 can extend that 
functionality using grafana for visualisations or heat for autoscaling.

> Can I restrict resource with OpenStack?
>
> For example, is it possible to limit the CPU to 20 % for process that 
> normally use 50% CPU?
> If you have such a command, please let me know!

probably better answered by Nova devs but seems this is possible[1][2]

[1] https://blueprints.launchpad.net/nova/+spec/quota-instance-resource
[2] https://wiki.openstack.org/wiki/InstanceResourceQuota

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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




From: Sean McGinnis 
Sent: Friday, August 18, 2017 4:31:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [release] [telemetry] Ceilometer stable/pike 
branch outlook

> > >>
> > >> Can someone on the release team clarify this for us?
> > >
> > > That's correct the bit you're missing is cycle-with-intermediary
> doesn't
> > > have pre-releases (b{1,2,3},rc{1,2}) so when the ceilometer team feels
> > > they have the code in shape for a release they'll tag that release and
> > > cut a stable/pike branch at the tag point.
> >

>
> that email explicitly says: "Deliverables following the
> cycle-with-intermediary model should also create their Pike release branch
> next week. That means potentially making a last Pike release, and in all
> cases posting the stable/pike branch creation request"
>
> And that wasn't done for ceilometer. So it needs to be done, right?
>

Yes, I just double checked, and there has not been a pike release yet for
ceilometer. That does need to be done soon.

Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 definitely does 
not exist in Newton.

Gnocchi does have visualisation functionality provided by Grafana:
http://gnocchi.xyz/grafana.html

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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. ceilometermiddleware is a
>> simple wsgi middleware and it's usage is part of ceilometer's install
>> docs. ceilometer-powervm contains the powervm driver for ceilometer's
>> polling agent.
>
> I've removed them from the tracking list for now, but it seems like
> both are likely to have contributor documentation, at least, and
> the driver would likely have installation and configuration docs,
> right?

can't speak regarding ceilometer-powervm since it's vendor specific. 
ceilometermiddleware is admittedly purely maintenance mode for last few 
cycles so i'm going to say realistically, it's very very low priority 
for anyone to actually follow through with contributor docs for it.

>
>>
>> i missed this but how do we handle smaller add-on type repos like this?
>> i imagine we want to keep docs grouped by project so they are not
>> scattered across the same level.
>>
>> cheers,
>>
>
> The new "rule" for docs is "The documentation for something should
> live in the same repository as the code."
>
> Hyperlinks are easy and free, so we can use those to ensure that the
> results are easy to find. We're building up a nice set of landing pages
> for "all of the admin guides" and "all of the configuration references"
> and so on within the openstack-manuals repository.
>

ok, sounds good to me.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 driver for ceilometer's 
polling agent.

i missed this but how do we handle smaller add-on type repos like this? 
i imagine we want to keep docs grouped by project so they are not 
scattered across the same level.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 bit different: 
> compute-agent->notification-agent->storage. Is it the intended behavior or 
> just a configuration error on my side?
>

there is no storage service now. ceilometer is just collection.

compute-agent->notification-agent->gnocchi is correct. there is no way 
to publish directly from polling agents to storage currently (not 
without hacking). i'm personally not against having polling agent push 
to gnocchi directory but it's just not there currently.

> - I found no gnocchi at the publishers, but it is still there at the 
> dispatchers. How is it used as a publisher? Just with some magic 
> transformation, publishers: -gnocchi:// is
> translated into using the direct publisher?
>

we haven't ported over gnocchi to publisher. it's still a dispatcher 
with a publisher alias. there is a work item for this and it's pretty 
simple, we just didn't do it (yet). i would think it will be done in 
Pike since we ideally want to remove all dispatchers in Queen.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 AM, Along Meng wrote:
>
> HI, all
>
> Today I try to add a new pollster plugin in ceilometer-agent-compute to
> collect vmware virtual machines's disk usage rate.
>
> After researched the vmware docs:
> https://www.vmware.com/support/developer/converter-sdk/conv61_apireference/disk_counters.html#usage
> 
>
> I think I can call the vsphere inspector get the
> counter capacity.provisioned and capacity.usage.
> Then I can get the virtual machine's disk usage rate via: disk_util
> = capacity.usage/capacity.provisioned
>
> *But, when I add a new function in vsphere inspector like below, It
> cannot get any data from vcenter:*
> My example code like this:
>
> ceilometer.compute.virt.vmware.inspector.VsphereInspector#inspect_disks
> =
> def inspect_disks(self, instance, duration=None):
> vm_moid = self._ops.get_vm_moid(instance.id )
> if not vm_moid:
> raise virt_inspector.InstanceNotFoundException(
> _('VM %s not found in VMware vSphere') % instance.id
> )
>
> VC_DISK_PROVISIONED_CNTR = "disk:capacity.provisioned:average"
> disk_counter_id =
> self._ops.get_perf_counter_id(VC_DISK_PROVISIONED_CNTR)
> disk_infos = self._ops.query_vm_aggregate_stats(vm_moid,
> mem_counter_id, duration)
> print “The disk info is:%s” % disk_infos
> 
>
> The disk_infos is empty.
>
> I try to use these functions to query the counter value:
> self._ops.query_vm_device_stats(vm_moid, disk_counter_id, duration)
> self._ops.query_vm_aggregate_stats(vm_moid, mem_counter_id, duration)
>
> *But cannot get any data from vcenter, and I'm sure the vcenter service
> is correct in my env.*
>
> *Does anyone know what's wrong with my code? *
> *Or is there any other solutions for my requirement.*
>
> Thanks~
>
> ==
> MengAlong

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 publisher as:

direct://?dispatcher=panko


[1] 
https://github.com/openstack/panko/commit/d785015552937455d76f083d313a73a7c0c076b3

cheers,
-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 polling|pipeline.yaml where you define what meters 
you want to enable. having the ability to do it in two different places 
causes conflict/confusion and i think the yaml path is probably the one 
people know about and is the more logical path.

disclaimer: i also want to drop the pollster-list option because there's 
a bug[2] related to it and i personally don't think it's worth fixing it.

[1] 
https://github.com/openstack/ceilometer/blob/7eb37ace7012a203ed83bd27b57f3db6f59f4547/ceilometer/cmd/polling.py#L69-L73
[2] https://bugs.launchpad.net/ceilometer/+bug/1603320

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo-service] Multi main processes are started by using oslo_service

[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 http://0.0.0.0:9914/
>
> 2017-06-27 17:42:18.864 1958059 INFO abc.common.wsgi [-] (1958059) wsgi
> starting up on http://0.0.0.0:9914/

because you asked for 2 workers? workers in oslo.service are 
processes[1]. i have no idea how 0 workers doesn't throw an error.

[1] 
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L523-L526

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 configure and use them.
> If not, are there any plans of providing support to them in coming releases?
>

i'm unaware of a meter in ceilometer that does this but i'd welcome it 
if contributed. please don't hesitate to reach out if you have questions 
on adding new meters to ceilometer.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 set to 300, but every minute 
> I receive errors if api doesn't work
> correctly.

you set batch_timeout as 300? it's either or scenario. basically the 
notification agent (or collector) either waits to receive  
messages before processing/publishing or it waits  
seconds before processing/publishing. nothing is thrown away.

i'm not sure why you receive some metrics but get timeouts for others. 
maybe others have an idea.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 understanding of their selected
> goal and its implementation to be a trusted person.
>
> What do people think before we bikeshed on the name? Would having a
> champion volunteer to each goal to help? Are there ideas that weren't
> mentioned in the TC meeting [3]?

do we know why they're not being completed? indifference? lack of resources?

i like the champion idea although i think its scope should be expanded. 
i didn't mention this in meeting and the following has no legit research 
behind it so feel free to disregard but i imagine some of the 
indifference towards the goals is because:

- it's often trivial (but important) work
many projects are already flooded with a lot of non-trivial, 
self-interest goals AND a lot trivial (and unimportant) copy/paste 
patches already so it's hard to feel passionate and find motivation to 
do it. the champion stuff may help here.

- there is a disconnect between the TC and the projects.
it seems there is a requirement for the projects to engage the TC but 
not necessarily the other way around. for many projects, i'm fairly 
certain nothing would change whether they actively engaged the TC or 
just left relationship as is and had minimal/no interaction. i apologise 
if that's blunt but just based on my own prior experience.

i don't know if the TC wants to become PMs but having the goals i feel 
sort of requires the TC to be PMs and to actually interact with the PTLs 
regularly, not just about the goal itself but the project and it's role 
in openstack. maybe it's as designed, but if there's no relationship 
there, i don't think 'TC wants you to do this' will get something done. 
it's in the same vein as how it's easier to get a patch approved if 
you're engaged in a project for some time as oppose to a patch out of 
the blue (disclaimer: i did not study sociology).

just my random thoughts.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 directly executing gnocchi-api -p 8041. I noted 
> the warning message and later rerun api
> using uwsgi daemon. The problem that I'm faced with is a connection errors 
> that appears in ceilometer-collector.log
> approximately every 5-10 minutes:
>
> 2017-06-22 12:54:09.751 1846835 ERROR ceilometer.dispatcher.gnocchi 
> ConnectFailure: Unable to establish connection to ht
> tp://10.10.10.69:8041/v1/resource/generic/c900fd60-0b65-57b5-a481-
> eaee8e116312/metric/network.incoming.bytes.rate/measures


is this failing on all your requests or just some? do you have data in 
your gnocchi?

>
> I run uwsgi with the following config:
>
> [uwsgi]
> #http-socket = 127.0.0.1:8000
> http-socket = 10.10.10.69:8041

this should work but i imagine it's not behind a proxy so you could use 
http instead of http-socket.

>
> # Set the correct path depending on your installation
> wsgi-file = /usr/local/bin/gnocchi-api
> logto = /var/log/gnocchi/gnocchi-uwsgi.log
>
> master = true
> die-on-term = true
> threads = 1
> # Adjust based on the number of CPU
> processes = 5
> enabled-threads = true
> thunder-lock = true
> plugins = python
> buffer-size = 65535
> lazy-apps = true
>
>
> I don't understand why this happens.
> Maybe I should point wsgi-file as 
> /usr/local/lib/python2.7/dist-packages/gnocchi/rest/app.wsgi ?

/usr/local/bin/gnocchi-api is correct... assuming it's in that path and 
not /usr/bin/gnocchi-api

> Form uwsgi manual I read that direct parsing of http is slow. So maybe I need 
> to use apache with uwsgi mod ?
>

not sure about this part. do you have a lot of metrics being pushed to 
gnocchi? you can minimised connection requirements by setting 
batch_size/batch_timeout for collector (i think mitaka should support 
this?). i believe in the gate we have 2 processes assigned to uwsgi so 5 
should be sufficient.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 dev meetings if their WG has done related work.
> b. Moreover the foundation could start promotion of project/WG
> collaboration best practices, or even specify in the release
> document that certain feature are based upon feedback from a certain
> WGs.
>
> c. WG should have cycle-based releases of works so that they got a
> sense of timing, no lost in a permanent discussion mode for issues.

agree that we need to stop being so silo'd. i would suggest even more 
regular feedback rather than a once a cycle data dump at the forum.

i don't attend WG meetings/discussions but i'm curious, do the Working 
Groups have resource to contact the desired PTLs bi-weekly/(some regular 
interval) to give feedback and discuss requirements? given the lack of 
resources in community dev teams, i would expect better results if WG 
members could initiate communication... or go 51% at least :)

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 presentations... 2 years on, we still
>> occasionally get asked "what's ceilometer", "is xyz not ceilometer?", or
>> "so ceilometer is deprecated?". to a certain extent i think we'll have
>> to be prepared to do some hand holding and say "hey, that's not what the
>> "big tent/."
>
> Is it clear to these people, once you explain the difference, what
> telemetry is?
>
> I would assume it is and this is one of the problems we're trying to
> solve. Even
> after explaining the difference, it's sometimes hard for people to grasp
> the
> concept because the naming that was used is poor and, to be honest, it
> feels
> like it came out from an analogy without properly considering the impact it
> would have in the community.
>
> Over-communicating won't get rid of surprises but sometimes the problem
> is in
> the message and not the receivers of it. We must stay honest with
> ourselves.

i think once we send them to the doc page and correct them, they get it.

i imagine a/the problem is because people are going to read a lot of 
historical unofficial/official stuff while they google. so while we 
fixed all the docs we could, there are still many more other sources 
(blogs, forks, etc...) that still reference the project from prior 
years. i would think this is an issue you'll get as well. people will 
stumble across the many 'big-tent' articles from 2 years ago and that 
becomes their knowledge until they're corrected. i'm not a branding 
specialist so i'm not sure how to correct this but it does seem like 
just renaming will not necessarily fix the issue (based on our experience).

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 ==
>> > governance' so when i read 'moving away from "big tent"' i think 'what
>> > is this *new* thing we're moving to and if we're redefining this new
>> > thing, what for?'. it seems this is not the case.
> No. We're trying to pick new words, because there continues to be
> confusion about the old words.

my bad, apologies for taking the scenic route. regardless of new words, 
we failed to properly describe what the big tent was the first go to 
some people, how do we make sure they're not confused this time? and how 
do we not confuse the ones that did understand the first time?

for me personally, the first go, the messaging was kind of muddled. i 
remember 'level playing field' being used frequently. not sure if that's 
still one of the reasons for ?

>> >
>> > sorry, i probably wasn't clear, i simply noticed that it was a corporate
>> > sponsor that was misusing the 'big tent' name so was just thinking we
>> > could easily tell them, that's not what it means. wasn't suggesting
>> > anything else by sponsor comment.
> You'd think it would be that easy. A surprising number of folks
> within the community don't really understand the old naming either,
> though (see the rest of this thread for examples).

*sigh* so this is why we can't have nice things :p

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 presentations... 2 years on, we still 
occasionally get asked "what's ceilometer", "is xyz not ceilometer?", or 
"so ceilometer is deprecated?". to a certain extent i think we'll have 
to be prepared to do some hand holding and say "hey, that's not what the 
"big tent/."


-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 taken over maintenance
> (several Oslo libs fall into this category, as do a few others like
> mox3 and sqlalchemy-migrate). With the move away from stackforge,
> and other changes in that hosting (that were made for good reasons
> to make the infra team's lives easier and to make it simpler for a
> project to join the set of governed projects), we have removed most
> of the other technical signals about which projects are in that
> "official" list and which are not.  We did not at the same time
> remove all of the people in the world who want to understand what
> is, and what is not, "in" OpenStack.

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 == 
governance' so when i read 'moving away from "big tent"' i think 'what 
is this *new* thing we're moving to and if we're redefining this new 
thing, what for?'. it seems this is not the case.

> And for the record, from the TC's perspective, being a governed
> project has nothing to do with whether the participants are sponsors
> of the foundation.

sorry, i probably wasn't clear, i simply noticed that it was a corporate 
sponsor that was misusing the 'big tent' name so was just thinking we 
could easily tell them, that's not what it means. wasn't suggesting 
anything else by sponsor comment.


-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 send in the suits for those who aren't. j/k).

it seems like we want to drop "big tent" because marketers ruined it but 
i'm still not sure we've formalised why we need a replacement (not 
saying we don't).

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 thought.

so if what we're trying to do is emphasis/segregate these project under 
governance, what for?  who's the target audience of: "here are some 
projects that use the openstack name, have 1+ people working on it, are 
'open', have some testing"?

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 
acceptance, supported some subset[1] of: 'open', had some testing, 
supported keystone, had a human resource? i don't really see how this 
differs from big tent? seems more like the same but without the 
'big-tent' stigma?

are we hoping openstack foundation to be a cloud-specific apache 
foundation? maybe it already is, and if so, i don't really understand 
the additional labeling we're trying to achieve.

[1] 
https://governance.openstack.org/tc/reference/new-projects-requirements.html

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
>> > opposite?
> Well, we tried that for 2.5 years now, and people are still confused
> about which projects are an Openstack project and what are not. The
> confusion led to the perception that everything under openstack/ is an
> openstack project. It led to the perception that "big tent" means
> "anything goes in" or "flea market".

regardless of terminology, i'm not entirely certain what everyone's 
definition of an openstack project and  project is. additionally, what the purpose of this categorization is?

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 might ask ourselves
> to help clarify the situation include (as usual, some of these
> questions may have obvious answers, but enumerating them can help
> make things explicit):
>
> * What motivates a project to seek status as an OpenStack project?
>   * What do they get?
>   * What do they lose?
>
> * What motivates OpenStack to seek more projects?
>   * What does OpenStack get?
>   * What does OpenStack lose?
>   * What gets more complicated when there are more projects?
>
> * Why would a project choose to be "hosted on OpenStack
>   infrastructure" instead of be an "OpenStack project"?
>
> * Why should OpenStack be willing to host projects that are not
>   "OpenStack projects"?
>
> * When a project goes from the status of "OpenStack project" to
>   "hosted on OpenStack infrastructure" (as currently being discussed
>   with regard to Fuel) what is the project losing, what does the
>   change signify and why should anyone care?
>
> (I'm sure other people can come up with a few more questions.)
>
> I think that if we're going to focus on this issue then we need to
> make sure that we focus on marshalling the value and resources that
> are required to support a project. That is: it has to be worth
> everyone's time and enery to be and have (official) projects. It's
> likely that this could mean that some projects are unable to be
> (official) projects anymore.

do this ^ first. if we cant qualify what we're trying to do with this 
labeling then it doesn't matter what name you slap on it. is it for 
marketing purposes? is it to define an OpenStack Community Edition? is 
it to create a repo of known projects that are solely funded/developed 
by OpenStack sponsors? is it to help developers somehow?

currently, if i read the new projects requirements[1], the 'big tent' is 
something along the lines of "here's a bunch of 'cloud' stuff the 
proprietary companies provide but from companies that fund openstack 
brand that is 'open'. we make no guarantees that they actually work 
(they probably don't), this is solely to say these projects: exists, are 
'open', and probably work with nova/keystone."

there is nothing wrong with this (except it being a terrible sales 
pitch) but since the 'big tent' message was ambiguous and we labeled it, 
it reached a marketer and became: 'look at us, we have a big tent 
project. what's the big tent? it's '.

labeling is inherently a branding exercise, so my question is what are 
we trying to market and should we be doing it or is it something that 
companies[2] should be doing.

[1] 
https://governance.openstack.org/tc/reference/new-projects-requirements.html
[2] https://www.openstack.org/marketplace/

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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, you can also see how we add powervm in a separate repo here: 
https://github.com/openstack/ceilometer-powervm. it basically leverages 
ceilometer's interface but they manage the powervm specific stuff.

it's worked ok so far (i think) we just need to sync up on what 
interface is in case other drivers want to do the same.

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 we have OpenDaylight depended code restricted to
> n-odl repo. Please let us know your thoughts on the same.
>

will this run as its own periodic service or do you need to leverage 
ceilometer polling framework?

ideally, all this code will exists outside for ceilometer and have 
ceilometer consume it. the ceilometer team is far from experts on ODL so 
i don't think you want us reviewing ODL code. we'll be glad to help with 
integration though.

cheers,

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 operators were correctly
> expunging old tokens; some environments just did so many requests that
> the keystone-token table still blew up to where MySQL can no longer
> delete from it without producing a too-large transaction for Galera.

i feel your pain. had exact same "can't clean token table because it's 
too damn big" issue.

>
> So after all the "finally fernet solves this problem" we propose, hey
> lets put them *back* in the database :).  That's great.  But, lets
> please not leave "cleaning out old tokens" as some kind of
> cron/worry-about-it-later thing.  that was a terrible architectural
> decision, with apologies to whoever made it.if you're putting some
> kind of "we create an infinite, rapidly growing,
> turns-to-garbage-in-30-seconds" kind of data in a database, removing
> that data robustly and ASAP needs to be part of the process.

my very basic understanding is that only the key to generate token is 
stored. so it in theory will expire less often but more importantly, 
isn't affected by the number of requests.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 and look this ^

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 collectd to use DPDKSTAT plugin and also enabled the
> collectd-ceilometer-plugin as mentioned in their docs. I have used
> mongodb as the database for ceilometer service. I have observed that
> “ceilometer meter-list” doesn’t display any of the dpdkstat related
> meters, but when I issue “ceilometer sample-list –m
> dpdkstat.if_rx_packets” I get a table populated with resource-id and
> other details. I am not sure why “ceilometer meter-list” is not able to
> list my new dpdkstat meters.
>

you see them in sample-list and not meter-list? if that's the case, it's 
probably because the api doesn't return full dataset. i believe it's 
limited to 100 or a 1000.

regardless, i'm going to add obligatory ceilometer storage is 
unsupported and deprecated. use Gnocchi[1] or another time-series 
optimised solution. you're going to run into massive scaling issues 
(each datapoint in mongodb driver is over >1KB), especially if you're 
collecting collectd stats.

[1] http://gnocchi.xyz

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 locality might not be optimal for all regions 
causing the write performance to take longer than needed for a 'cache' 
storage
- sending HTTP POST with JSON payload probably more bandwidth than 
binary serialised format gnocchi uses internally.

i'm thinking it'd be good to support ability to have each region store 
data 'locally' to minimise latency and then have regional metricd agents 
aggregate into a central target. this is technically possible right now 
by just declaring regional (write-only?) APIs with same storage target 
and indexer targets but a different incoming target per region. the 
problem i think is how to handle coordination_url. it cannot be the same 
coordination_url since that would cause sack locks to overlap. if 
they're different, then i think there's an issue with having a 
centralised API (in addition to regional APIs). specifically, the 
centralised API cannot 'refresh'.

i'm not entirely sure this is an issue, just thought i'd raise it to 
discuss.

regardless, thoughts on maybe writing up deployment strategies like 
this? or make everyone who reads this to erase their minds and use this 
for 'consulting' fees :P

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 put on supporting it, i'd like to proposed to drop hbase 
support as a first step in making the project more manageable for 
whatever resource chooses to support it.

why hbase as initial candidate to prune?
- it has no testing in gate
- it never had testing in gate
- we didn't receive a single reply in user survey saying hbase was used
- all the devs who originally worked on driver don't work on openstack 
anymore.
- i'd be surprised if it actually worked

i just realised it's a long weekend in some places so i'll let this 
linger for a bit.

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [telemetry] gnocchi v4 preview

[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 time to help test it[1] out, please feel free and give us 
some feedback. instructions to install from source are online[2].

if you have any questions, feel free to ping on #gnocchi or 
#openstack-telemetry in Freenode or on ML.

[1] https://github.com/gnocchixyz/gnocchi
[2] http://gnocchi.xyz/install.html#id1

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] uWSGI help for Congress

[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 goal.
> Thanks a ton!
>

it shouldn't be much different from mod_wsgi. you just need to create a 
uwsgi.ini file which points to the appropriate .wsgi file. here's 
sileht's patch in gnocchi from a while back: 
https://review.openstack.org/#/c/292077. apparently pbr provides wsgi 
file now (not sure what version though): 
https://github.com/gnocchixyz/gnocchi/commit/6377e25bdcca68be66fadf65aa16a6f174cfaa99

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 my opinion, Discussion promotes the growth of the project. Maybe
> statistics on the number of people who can attend the meeting is
> more convincing.
>

i just want to add, i am ok to meet at PTG but if we consider the turn 
out at forum sessions, we aren't getting any more developers, just 
random requirement requests.

we can discuss on irc and mailing list? in fact we encourage it, which 
is why you might see random short emails from me on list about whether i 
should proceed on work item a certain way. i understand how meetings and 
presence create this false narrative that work is being done. 
regardless, i do hope we leverage ML and irc more. if you have a comment 
or question, don't be afraid to use this medium. i shouldn't have to 
wait 6 months to here problems :)

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 worthwhile. if not, i imagine it's not worthwhile to have us 
all fly to a different city so we can do exactly what we can do at home.

cheers,

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer]

[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
> (MySQL-based) and the Data collection service database (MongoDB) are not
> communicating properly. Is it possible for the Aodh to access the data
> from MongoDB?

the alarming database and the deprecated ceilometer db are not suppose 
to be communicating with each other so i'm not entirely sure what you 
are expecting. ceilometer meter-list grabs data from legacy ceilometer 
db, aodh alarm list grabs data from aodh.


-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 could not deleted the rest on second go but i guess i'll need 
to look at that and see if we can do that.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 to process and then check indexer to validate that
>> they are still active. because it checks indexer later, even if both
>> janitor and processing worker check lock at same time, we can guarantee
>> it will have indexer state processing worker sees is > 00:00:00 since
>> janitor has state before getting lock, while processing worker as state
>> sometime after getting lock.
>
> My brain hurts but that sounds perfect. That even means we potentially
> did not have to lock currently, sack or no sack.
>

oh darn, i didn't consider multiple janitors... so this only works if we 
make janitor completely separate and only allow one janitor ever. back 
to square 1

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 to process and then check indexer to validate that
>> they are still active. because it checks indexer later, even if both
>> janitor and processing worker check lock at same time, we can guarantee
>> it will have indexer state processing worker sees is > 00:00:00 since
>> janitor has state before getting lock, while processing worker as state
>> sometime after getting lock.
>
> My brain hurts but that sounds perfect. That even means we potentially
> did not have to lock currently, sack or no sack.
>

yeah, i think you're right.

success! confused you with my jumble of random words.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 don't
> recall any option for that. :/

https://github.com/openstack/gnocchi/commit/72a2091727431555eba65c6ef8ff89448f3432f0
 


although now that i check, i see it's blocking by default... which means 
we did guarantee all measures would be return.

>
>> in the case of cross-metric aggregations, this is a timeout for entire
>> request or per metric timeout? i think it's going to get quite chaotic
>> in the multiple metric (multiple sacks) refresh. :(
>
> Right I did not think about multiple refresh. Well it'll be a nice
> slalom of lock acquiring. :-)
>
>> i'm hoping not to have a timeout because i imagine there will be
>> scenarios where we block trying to lock sack, and when we finally get
>> sack lock, we find there is no work for us. this means we just added x
>> seconds to response to for no reason.
>
> Right, I see your point. Though we _could_ enhance refresh to first
> check if there's any job to do. It's lock-free. Just checking. :)
>

hmmm. true. i'm still hoping we don't have to lock an entire sack for 
one metric and not return an error status just because it can't lock. 
doesn't seem like a good experience.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 else is working on sack, any metricd that
>> follows will also know that the metric(s) are deleted and therefore,
>> won't work on it.
>
> I did not understand your whole idea, can you detail a bit more?
> Though the "check lock" approach usually does not work and is a source
> of race condition, but again, I did not get the whole picture. :)
>

my thinking is that, when the janitor goes to process a sack, it means 
it has indexer state from time 00:00:00.

if the sack is locked, then it means a processing worker is looking at 
sack and has indexer state from time <= 00:00:00.

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 to process and then check indexer to validate that 
they are still active. because it checks indexer later, even if both 
janitor and processing worker check lock at same time, we can guarantee 
it will have indexer state processing worker sees is > 00:00:00 since 
janitor has state before getting lock, while processing worker as state 
sometime after getting lock.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 as a patch.

>
>> > refresh is currently disabled by default so i think we're ok.
> Well you mean it's disabled by default _in the CLI_, not in the API
> right?

refresh i believe is always disabled by default regardless of what 
interface you're using.

>
>> > what's the timeout for? timeout api's attempt to aggregate metric? i
>> > think it's a bad experience if we add any timeout since i assume it will
>> > still return what it can return and then the results become somewhat
>> > ambiguous.
> No, I meant timeout for grabbing the sack's lock. You wouldn't return a
> 2xx but a 5xx stating the API is unable to compute stuff right now, so
> try again without refresh or something.

in the case of cross-metric aggregations, this is a timeout for entire 
request or per metric timeout? i think it's going to get quite chaotic 
in the multiple metric (multiple sacks) refresh. :(

i'm hoping not to have a timeout because i imagine there will be 
scenarios where we block trying to lock sack, and when we finally get 
sack lock, we find there is no work for us. this means we just added x 
seconds to response to for no reason.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 and do dumb things like:
> - metric1 from sackA
> - metric2 from sackB
> - metric3 from sackA
>
> and do 3 different lock+delete -_-

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 else is working on sack, any metricd that 
follows will also know that the metric(s) are deleted and therefore, 
won't work on it.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 and do dumb things like:
> - metric1 from sackA
> - metric2 from sackB
> - metric3 from sackA
>
> and do 3 different lock+delete -_-

so the tradeoff here is that now we're doing a lot more calls to 
indexer. additionally, we're pulling a lot more unused results from db.
a single janitor currently just grabs all deleted metrics and starts 
attempting to clean them up one at a time. if we merge, we will have n 
calls to indexer, where n is number of workers, each pulling in all the 
deleted metrics, and then checking to see if the metric is in it's sack, 
and if not, moving on. that's a lot of extra, wasted work. we could 
reduce that work by adding sack information to indexer ;) but that will 
still add significantly more calls to indexer (which we could reduce by 
not triggering cleanup every job interval)


>>
>> alternatively, this could be solved by keeping per-metric locks in
>> addition to per-sack locks. this would effectively double the number of
>> active locks we have so instead of each metricd worker having a single
>> per-sack lock, it will also have a per-metric lock for whatever metric
>> it may be publishing at the time.
>
> If we got a timeout set for scenario 3, I'm not that worried. I guess
> worst thing is that people would be unhappy with the API spending time
> doing computation anyway so we'd need to rework how refresh work or add
> an ability to disable it.
>

refresh is currently disabled by default so i think we're ok.

what's the timeout for? timeout api's attempt to aggregate metric? i 
think it's a bad experience if we add any timeout since i assume it will 
still return what it can return and then the results become somewhat 
ambiguous.

now that i think about it more this issue still exists in per-metric 
scenario (but to lesser extent). 'refresh' can still be blocked by 
metricd but it's just a significantly smaller chance and the window for 
missed unprocessed measures is smaller.

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 locking, 
metric based actions can affect sack level processing. for example:

scenario 1:
1. delete metric, locks sack to delete single metric,
2. metricd processor attempts to process entire sack but can't, so skips.

OR

scenario 2:
1. API request passes in 'refresh' param so they want all unaggregated 
metrics to be processed on demand and returned.
2. API locks 1 or more sacks to process 1 or more metrics
3. metricd processor attempts to process entire sack but can't, so 
skips. potentially multiple sacks unprocessed in currently cycle.

scenario 3
same as scenario 2 but metricd processor locks first, and either blocks
API process OR  doesn't allow API to guarantee 'all measures processed'.

i imagine these scenarios are not critical unless a very large 
processing interval is defined or if for some unfortunate reason, the 
metric-based actions are perfectly timed to lock out background processing.

alternatively, this could be solved by keeping per-metric locks in 
addition to per-sack locks. this would effectively double the number of 
active locks we have so instead of each metricd worker having a single 
per-sack lock, it will also have a per-metric lock for whatever metric 
it may be publishing at the time.


cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 kolla becoming more popular (tripleo I think is using it, and ...)
> and the containers it creates making isolated per-application
> environments it makes me wonder what of global-requirements is still
> valid (as a concept) and what isn't.
>
> I do remember the days of free for all requirements (or requirements
> sometimes just put/stashed in devstack vs elsewhere), which I don't
> really want to go back to; but if we finally all agree that
> co-installability isn't what people actually do and/or care about
> (anymore?) then maybe we can re-think some things?

agree with all of ^... but i imagine to make progress on this, we'd have 
to change/drop devstack usage in gate and that will take forever and a 
lifetime (is that a chick flick title?) given how embedded devstack is 
in everything. it seems like the solution starts with devstack.

cheers,

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 notification topic, EventsNotificationEndpoint
>  in event/endpoint.py will handle it, however, when I send the same
> event again, with log/pdb enabled, the event is not processed in
> EventsNotificationEndpoint any more, and I can't find where it is done.
> It looks so weird or maybe that is by design for some reason? The
> behavior is same with/without definition in event_definition.yaml

this listener[1] is loading EventsNotificationEndpoint. if you look at 
EventsNotificationEndpoint, you can see it picks up stuff on .info and 
.error topics and normalises them to Event obj.

i'm assuming you're using oslo.messaging to push to queue as well. i 
don't think the system works if you are pushing your own format to queue.


>
> So I wonder how is different for the workflow by sending same events twice.

there is no difference. only difference is a different agent might be 
handling it (if you have multiple notification agents)

[1] 
https://github.com/openstack/ceilometer/blob/stable/mitaka/ceilometer/notification.py#L242-L245

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 EventsNotificationEndpoint() , however, the second
> time, neither the AMQPIncomingMessage or the EventsNotificationEndpoint
> can see it, but it does can list from ceilometer event-list. So I wonder
> how is the event processing with the same event type?
>

not sure what version you are using, but basic workflow since mitaka (i 
think) is the notification agent listens to 'notifications.*' topics on 
specific exchanges (including) ceilometer. for events, it attempts to 
match incoming message against known events[1]. it will build event 
based on definition. if there is no, definition, it will create a sparse 
event with a few attributes. from there it is processed according to 
pipeline[2]. you'll noticed by default it pushes to gnocchi so it won't 
get stored in ceilometer/panko storage. you can edit it accordingly.

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_pipeline.yaml

cheers,
-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 now.
>
> I think we want it to be configurable, though most people would probably
> not tweak it. But I can imagine some setups where increasing it would
> make sure that.
> There's some sense of exposing it anyway, even if it does not change
> much. For example, we never exposed TASKS_PER_WORKER but in the end it
> seems the 16 value is not optimal. But since we did not expose it,
> there's barely no way for tester to try to tweak it and see what value
> works best. :)

well argued. take it :)

>
> You're completely right, we needed to discuss that anyway. All your
> patches version and tries build up our knowledge and expertise on the
> subject, so it was definitely worth the effort, and kudos go to you for
> taking that job!
>
> What will probably make you go back to hashring?

i think your argument that hashring can be configured effectively to 
"work on everything" was a good argument.

cheers,

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev