14:00:35 <rafaelweingartner> #startmeeting cloudkitty
14:00:35 <opendevmeet> Meeting started Mon Jan 19 14:00:35 2026 UTC and is due to finish in 60 minutes.  The chair is rafaelweingartner. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:35 <opendevmeet> The meeting name has been set to 'cloudkitty'
14:00:40 <rafaelweingartner> Hello guys!
14:00:43 <rafaelweingartner> Roll count
14:00:44 <rafaelweingartner> \o
14:00:46 <mattcrees> o/
14:01:33 <jwysogla_> o/
14:02:16 <jlarriba> o/
14:03:55 <priteau> o/
14:04:50 <rafaelweingartner> \o!
14:05:03 <rafaelweingartner> nice to see you all here
14:05:35 <rafaelweingartner> #topic Target reviews
14:06:21 <rafaelweingartner> #link https://review.opendev.org/c/openstack/cloudkitty/+/953827 is a feature from our side. It would be good to get the feedback from the CRs to see if we can get this into 2026.1 release.
14:10:35 <mattcrees> It looks like a useful feature. I've not had time to review/test it yet myself. But certainly let's aim to get it in this release
14:11:41 <rafaelweingartner> mattcrees: thanks!
14:11:45 <rafaelweingartner> the reviews are welcome!
14:11:50 <jlarriba> i believe it is very useful, corrects a behaviour that is not good, which is storing hundreds (thousands) of 0 values in the dataframe storage
14:12:32 <rafaelweingartner> we actually had millions of zeros...
14:12:33 <rafaelweingartner> :0
14:12:54 <mattcrees> wow
14:12:56 <jlarriba> yeah, i can believe it, we have just started to hit this like once month ago in our test envs and it is already annoying :)
14:13:51 <priteau> If the main use case is skipping vol = 0, could the new feature be hardocded to do this rather than use eval? Still worried about this eval() usage
14:14:00 <priteau> What do others think?
14:14:31 <rafaelweingartner> the trigger was that one, but we have seen other possibilities that we use in PROD.
14:14:37 <jlarriba> completely agree with you priteau, my concerns over using eval() are in the patch itself, and I dont know why someone would need all those 0s to be generated
14:14:43 <rafaelweingartner> such as skipping values (rated data) with zero values, and so on
14:17:17 <rafaelweingartner> that is we implemented this way. We know that there can be other use cases we do not see, and therefore, it felt more reasonable to make the solution flexible; it is the same idea/concept we did in Ceilometer
14:24:28 <rafaelweingartner> Moving on, we have #link https://review.opendev.org/c/openstack/cloudkitty/+/969934
14:24:51 <rafaelweingartner> the patch was rebased, let's see if it passes the tests
14:30:13 <mattcrees> The patch itself looks fine, I'm happy to approve if CI comes back successful
14:30:22 <rafaelweingartner> agree
14:31:43 <jwysogla> yes same with me. I was waiting for the CI to get through, but it looked good when I checked last week
14:32:09 <rafaelweingartner_> I got kicked
14:32:34 <rafaelweingartner_> Moving on, #link https://review.opendev.org/c/openstack/cloudkitty-specs/+/966753, we have the spec, which is interesting
14:32:54 <rafaelweingartner_> It basically adds a layer of authentication on top of prometheus via Keystone
14:33:08 <rafaelweingartner_> to me, it is fine to be merged, and moved on
14:33:11 <jlarriba> Aetos makes prometheus a first class citizen in OpenStack ;)
14:33:30 <jlarriba> so it enjoys secure connections just like all other services do
14:37:37 <jwysogla> Yea. It'll be quite nice once we get some more usage with it. BTW I tested Aetos with ceilometer and with openstack-exporter. It works with both. It requires keystone authentication for accessing prometheus and it returns metrics from projects based on where the request comes from, what's the user's roles, etc (kind of what gnocchi does). The spec is written to still keep the current prometheus
14:37:37 <jwysogla> collector, so using aetos will be optional from CK POV.
14:40:25 <mattcrees> I've added second approval to the spec. I'm not familiar with Aetos myself, but the explanations in the spec sound good to me.
14:41:19 <mattcrees> My main concern would be that the existing way of Prometheus still works, which the spec accounts for :)
14:41:44 <rafaelweingartner_> And that is basically it from my side for today. Do you guys have something else to add before we close the meeting?
14:43:37 <mattcrees> Nothing new from me this time
14:44:18 <jlarriba> i have submitted a proposal of new cloudkitty-dashboard looks here enable_plugin neutron https://opendev.org/openstack/neutron unmaintained/2023.1  # Source neutron's octavia helper manually since legacy mode doesn't run neutron plugin.sh  source_opt_if /opt/stack/neutron/devstack/lib/octavia
14:44:48 <jlarriba> sorry, wrong thing pasted :(
14:44:58 <opendevreview> Merged openstack/cloudkitty-specs master: Add Aetos collector  https://review.opendev.org/c/openstack/cloudkitty-specs/+/966753
14:45:21 <jlarriba> this is the patch: https://review.opendev.org/c/openstack/cloudkitty-dashboard/+/973486
14:46:00 <jlarriba> i have also pasted some screenshots, jut to get a feeling over if the community would be open to these kind of ui changes
14:47:38 <rafaelweingartner_> thanks!
14:51:12 <rafaelweingartner_> If there is nothing else, I guess we can close for today.
14:52:26 <jlarriba> ok for me!
14:52:57 <rafaelweingartner_> Thank you for participating. Have a nice week.
14:53:02 <mattcrees> Thanks!
14:53:58 <rafaelweingartner_> #endmeeting
14:54:55 <rafaelweingartner_> #endmeeting
11:15:37 <opendevreview> Merged openstack/cloudkitty master: Delay string interpolations at logging calls  https://review.opendev.org/c/openstack/cloudkitty/+/969934