02:31:46 <ekcs> #startmeeting congressteammeeting
02:31:47 <openstack> Meeting started Fri Jul 13 02:31:46 2018 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:31:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
02:31:50 <openstack> The meeting name has been set to 'congressteammeeting'
02:31:54 <ekcs> hello all
02:31:57 <ekcs> happy friday
02:31:59 <masahito> hello
02:32:07 <akhil_jain_> hello
02:32:08 <ekcs> topics here as usual: https://etherpad.openstack.org/p/congress-meeting-topics
02:32:15 <ekcs> hi masahito !
02:32:18 <ekcs> hi akhil_jain_ !
02:34:26 <ekcs> ok let’s get started.
02:34:34 <ekcs> #topic congressclient docs job blocked
02:34:42 <ekcs> most just a quick announcement.
02:34:58 <ekcs> the job is failing Likely caused by the sphinx upgrade.
02:35:03 <ekcs> Will probbaly need a similar but smaller fix as was done on congress server
02:35:08 <ekcs> https://review.openstack.org/#/c/576601/
02:35:17 <ekcs> I started looking at it but don’t have a fix yet.
02:36:02 <ekcs> #topic rocky-3
02:36:29 <ekcs> just a quick reminder that rocky-3, feature freeze, and final client release are in less than two weeks!
02:37:28 <ekcs> it’s a good time to figure out which things can be done and focus on those.
02:37:58 <ekcs> on congress server side, it can make sense to focus on featureful changes, while leaving bug fixes and other nonfeatureful changes to after feature freeze.
02:40:04 <ekcs> #topic patches
02:40:12 <ekcs> any patches people want to discuss?
02:41:56 <masahito> nothing from my side.
02:42:34 <ekcs> cool.
02:42:35 <akhil_jain_> nothing from my side either
02:42:43 <ekcs> here’s a patch that may be ready to merge: https://review.openstack.org/#/c/567075/
02:44:39 <ekcs> #topic opens discussion
02:44:54 <ekcs> cool moving along then! anything else we’d like to discuss today?
02:45:37 <akhil_jain_> ekcs: one thing about deleting rows in pushed driver data
02:45:50 <akhil_jain_> do we set 240 hours as standard?
02:46:50 <ekcs> I think it depends on the particular driver and the particular data.
02:47:47 <ekcs> on vitrage alarms I just set a long time. in general we never really need to delete except that if we NEVER delete then eventually too much stuff accumulates
02:48:02 <ekcs> worst case situation we run out of memory haha.
02:48:18 <ekcs> are you thinking about monasca situation akhil_jain_ ?
02:48:33 <akhil_jain_> yes asked for that
02:49:28 <ekcs> personally I think for alarm data my thinking is, just keep alarms for a long time, but not forever.
02:49:43 <ekcs> as long as we don’t run into memory and performance issues it’s fine.
02:50:10 <ekcs> if policy cares about using only recent alarms, then the policy can explicitly check for it.
02:50:45 <ekcs> not something to handle using cleanup mechanism.
02:51:35 <akhil_jain_> but we need to clean old data eventually
02:52:08 <ekcs> right. so I kind of use a nice round number like 10 days to be long time but not forever.
02:52:28 <ekcs> no special reason for it. for monasca it could be same or different.
02:53:03 <akhil_jain_> ok great thanks for your input
02:54:44 <ekcs> np! anything else on monasca or anything else?
02:56:40 <akhil_jain_> thats all for now, will discuss later about test cases in monaca pushed driver
02:57:22 <ekcs> cool!
02:58:30 <ekcs> alright then one last thing: there are a couple new specs submitted. take a look if interested!
02:58:31 <ekcs> https://review.openstack.org/#/q/project:openstack/congress-specs
02:58:51 <ekcs> one is from pierre about a new datalog engine for very large data sets.
02:58:57 <ekcs> that’s all from me.
02:59:38 <akhil_jain_> ok i will go through it
02:59:56 <ekcs> great.
03:00:02 <ekcs> end meeting then if there’s nothing else for today?
03:01:01 <akhil_jain_> yes nothing else from my side
03:01:10 <masahito> nothing from my side
03:10:32 <ekcs> cool talk to you next time then!
03:10:34 <ekcs> #endmeeting