08:00:42 <ifat_afek> #startmeeting vitrage
08:00:43 <openstack> Meeting started Wed Jun  6 08:00:42 2018 UTC and is due to finish in 60 minutes.  The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:47 <openstack> The meeting name has been set to 'vitrage'
08:00:50 <ifat_afek> Hi :-)
08:01:12 <e0ne> hi
08:01:15 <eyalb> Hi
08:02:48 <nivo> Hi
08:03:29 <nivo> I am currently working on adding tempest tests to test the new AODH alarm types
08:03:29 <ifat_afek> Agenda:
08:03:42 <ifat_afek> Thanks :-)
08:04:08 <ifat_afek> You already pushed the aodh code itself, right?
08:05:45 <nivo> Yes i pushed the code
08:05:50 <ifat_afek> Cool, thanks
08:05:56 <nivo> :-)
08:06:01 <ifat_afek> Back to the agenda:
08:06:06 <ifat_afek> •	Vancouver recap
08:06:11 <ifat_afek> •	Status and updates
08:06:15 <ifat_afek> •	Open discussion
08:06:22 <ifat_afek> #topic Vancouver recap
08:06:37 <ifat_afek> I think we had a great success with Vitrage sessions in Vancouver
08:06:49 <ifat_afek> . In two sessions we had over 80 attendees. More than 30 came to our lab, and the forum sessions were also very productive. I’ll send a detailed recap later this week.
08:07:08 <ifat_afek> A list of all sessions related to Vitrage:
08:07:08 <ifat_afek> #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=vitrage
08:07:09 <e0ne> I missed the lab:(
08:07:40 <ifat_afek> Unfortunately it wasn’t recorded :-(
08:07:41 <eyalb> Unfortunately it is not recorded
08:08:04 <eyalb> I can try and send you the material
08:08:40 <e0ne> eyalb: it would be awesome
08:08:53 <eyalb> You will need to install a devstack with some predefined services running
08:09:01 <e0ne> I'm newbie to Vitrage, but I'm interesting in this project
08:09:10 <eyalb> Cool
08:09:27 <ifat_afek> You are very welcome to join
08:09:37 <eyalb> I will ask Muhammad to send you the slides
08:10:25 <ifat_afek> Moving on - here are the links to our forum etherpads:
08:10:33 <ifat_afek> #link https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s
08:10:39 <ifat_afek> #link https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases
08:10:54 <ifat_afek> I was asked to give feedback on the project onboarding session. The questions are:
08:11:00 <ifat_afek> •	About how many attended?
08:11:01 <ifat_afek> •	Slides? (If you have them/want to share them)
08:11:02 <ifat_afek> •	What went well?
08:11:03 <ifat_afek> •	What will you do differently next time?
08:11:04 <ifat_afek> •	Anything else? Other feedback?
08:11:21 <ifat_afek> If you have any feedback you think I should mention, let me know
08:11:47 <ifat_afek> And BTW, Berlin CFP is already open!
08:12:28 <ifat_afek> Any other comment/feedback related to Vancouver?
08:13:32 <ifat_afek> #topic Status and updates
08:13:43 <ifat_afek> We need to mark a first release of python-vitrageclient this week
08:13:57 <ifat_afek> I understand that it is quite stable, so I plan to release it together with vitrage and vitrage-dashboard later today. Let me know if you think there is a problem with this release.
08:14:44 <ifat_afek> Another issue – Yuval Adar reported a bug that when using a remote client that has a different time zone, the Zabbix alarm time does not match the time that is shown in Vitrage.
08:15:20 <ifat_afek> Apparently Zabbix shows the server time while Vitrage shows the client time. I understand that Nova and Heat act the same as Zabbix. I’m currently not sure what is the best solution
08:16:07 <e0ne> ifat_afek: fyi, it's not required to release client this week. it's required to do it in rocky-3
08:16:35 <eyalb> The problem is that the dashboard uses the  browser timezone and not the server timezone
08:17:49 <ifat_afek> eOne: I understood from the last “release countdown” mail that we should release twice during Rocky. So I think now makes sense. In the previous release we released very late (because we had several api changes “almost working”)
08:18:58 <ifat_afek> eyalb: My question is: is it really a problem? because I would expect it to be the wanted behavior (to use the client time zone), but apparently it is not the common one
08:19:19 <e0ne> ifat_afek: makes sense. I missed it
08:20:36 <eyalb> The problem is that time zone is not displayed in horizon so when a person sees a time stamp he dies
08:20:36 <ifat_afek> eOne: Actually, after reading it again, I’m not so sure… but I think that in any case we are in a good position to make a first release now
08:20:45 <e0ne> ifat_afek: +1
08:21:23 <eyalb> He does not know if it is a local time
08:21:42 <eyalb> or server time
08:22:24 <eyalb> Nova mistral and heat don't display time zone near the timestamp
08:22:43 <ifat_afek> I just wonder if the behavior we’ve seen in Nova, Heat and Mistral was on purpose or just without thinking about it too much
08:23:22 <e0ne> usually, dashboard shows time values in client time zone
08:23:40 <ifat_afek> But apparently this is not the case in OpenStack…
08:24:02 <ifat_afek> And also not in Zabbix
08:24:41 <ifat_afek> Another issue for Vitrage is that in the alarms view we might show alarms coming from different monitors, and if we don’t use the client time zone we could have it all mixed up
08:25:41 <e0ne> do we have timezone info from zsbbix?
08:26:08 <ifat_afek> I believe so
08:26:46 <ifat_afek> The bug that was reported is that the end user saw the client time in Vitrage and the server time in Zabbix UI, so it was confusing
08:27:11 <e0ne> oh.. I see
08:29:53 <e0ne> in horizon, user can set timezone manually if he or she wants to view time data in other timezon
08:30:15 <ifat_afek> Where is it done?
08:30:25 <e0ne> user settings page
08:30:35 <ifat_afek> So the assumption is that the user should see the same timezone everywhere?
08:30:49 <ifat_afek> And we should convert to the time zone that is defined in the user settings?
08:31:10 <e0ne> ifat_afek: we can only do it for horizon, not zabbix ui
08:31:21 <ifat_afek> Of course not for Zabbix
08:31:29 <e0ne> ifat_afek: +1 for converting data to user time zone
08:31:34 <ifat_afek> But we are trying to figure out what the Horizon convention is
08:31:57 <ifat_afek> And if the user has an option to set the Horizon timezone to match the server timezone, then I guess we’re good
08:32:41 <e0ne> +1
08:34:28 <ifat_afek> najjar: Hi, eOne asked about our lab earlier
08:35:21 <ifat_afek> I see that he was disconnected…
08:35:31 <ifat_afek> Any other updates or issues?
08:36:38 <najjar> Hi e0ne, I understand that you want to do the hands-on lab
08:37:27 <e0ne> najjar: hi yes. it could help he to understand vitrage better
08:38:01 <najjar> I can send you the requirements by email, so could you give me your email ?
08:38:36 <e0ne> najjar: sure, I'll send you it in dm
08:39:10 <najjar> what is dm ?
08:39:21 <e0ne> direct message :)
08:40:10 <ifat_afek> Thanks. Any other updates by anyone?
08:41:02 <najjar> so my update is that i'm back to work on Prometheus datasource
08:41:52 <e0ne> najjar: it would be awesome to get it in Rocky
08:42:30 <najjar> I believe it will be ready till then :D
08:42:40 <najjar> (y)
08:42:45 <e0ne> :)
08:43:11 <ifat_afek> Cool
08:43:16 <ifat_afek> Anything else?
08:44:24 <ifat_afek> #topic Open discussion
08:44:36 <e0ne> I've got one topic to discuss
08:44:42 <ifat_afek> Sure
08:45:03 <e0ne> we're thinking about adding vitrage to one of the our next distro
08:45:19 <e0ne> but it's required to have project upgrades procedure
08:45:43 <e0ne> I'm going to implement database schema migrations if the team is OK with it
08:46:21 <e0ne> we've got at least one DB change in Rocky, so vitrage couldn't be easy upgraded from Queens to Rocky :(
08:46:39 <ifat_afek> What DB change is that?
08:46:46 <e0ne> also, cold upgrades could be a community goal  for S
08:46:47 <ifat_afek> We actually didn’t expect a problem
08:47:09 <ifat_afek> We only introduced a DB in Queens, so we are not so familiar with these issues
08:50:33 <e0ne_> sorry, I'd got an issue with internet connection
08:51:04 <ifat_afek> Ok, I just said that we didn’t expect a problem with DB changes, but we are less familiar with these issues. What problems do you expect to have?
08:51:14 <e0ne_> here is a new db change in Rocky https://governance.openstack.org/tc/reference/
08:51:58 <e0ne_> ifat_afek: we changed column type. how data will be migrated from Queens to Rocky?
08:52:12 <ifat_afek> I believe you sent the wrong link?
08:52:28 <e0ne_> oops
08:52:31 <e0ne_> here is it https://github.com/openstack/vitrage/commit/8f8c8eec1d19e0b4f39c9f6ac60d9fc3b6460ba1#diff-733bcd8aa10c5aaeaf9195f196978f6b
08:53:05 <ifat_afek> Ok, I see now. Two things:
08:53:54 <ifat_afek> 1. The snapshot code was written in Queens but was not completed, so we don’t expect anyone to use it. I’m almost sure that this code was completely disabled in Queens. We only used it internally for testing
08:54:17 <ifat_afek> 2. We have vitrage-dbsync command that fixes the db schema
08:54:39 <e0ne_> ifat_afek: ok, I'll check it and let you know
08:54:42 <ifat_afek> Do you think it is good enough? it is only a matter of re-defining the table, but there shouldn’t be any data loss because there shouldn’t be any data
08:55:02 <e0ne_> I need to check it
08:55:05 <ifat_afek> I’ll be happy to know if you expect problems, and thanks for notifying us about this issue…
08:55:13 <e0ne_> btw, I'm ready to volunteer to implement these requirements https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements for vitrage
08:55:37 <ifat_afek> We’ll be more than happy if you do :-)
08:55:43 <e0ne_> :)
08:56:23 <ifat_afek> Any other issue?
08:56:49 <e0ne_> ok. I'll try queens-rocky upgrade and let you know what is my result
08:57:11 <e0ne_> also, I'll file a blueprint for this if any activity is needed
08:57:18 <ifat_afek> Great, thanks
08:58:17 <ifat_afek> We are almost out of time… so see you next week :-)
08:58:36 <najjar> thanks bye
08:58:43 <e0ne_> see you next week!
08:59:15 <ifat_afek> #endmeeting