08:00:10 <ifat_afek> #startmeeting vitrage
08:00:11 <openstack> Meeting started Wed Jan  3 08:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:14 <openstack> The meeting name has been set to 'vitrage'
08:00:15 <ifat_afek> Hi :-)
08:00:24 <najjar> Hi :D
08:00:32 <yujunz> Hi o/
08:01:05 <eyalb> \o/
08:03:06 <idan_hefetz> Hi
08:03:21 <ifat_afek> Agenda:
08:03:33 <ifat_afek> •	Status and Updates
08:03:33 <ifat_afek> •	Queens roadmap follow-up
08:03:34 <ifat_afek> •	Open Discussion
08:03:39 <ifat_afek> #topic Status and Updates
08:03:49 <ifat_afek> One general update: Vitrage was added to kolla-ansible
08:03:54 <ifat_afek> #link https://review.openstack.org/#/c/432608/
08:04:12 <ifat_afek> My update: I am still working on the execute-mistral refactoring. I pushed the change that supports different template validation and template loading per template versions.
08:04:19 <ifat_afek> #link https://review.openstack.org/#/c/529332
08:04:29 <ifat_afek> As part of this change, I changed the structure of the existing execute_mistral action.
08:04:45 <ifat_afek> Now I’m working on the last part that is needed to complete the integration with Mistral – I’m writing the code to add functions to the templates.
08:05:04 <ifat_afek> The first (and for now the only) function will be get_attr(entity, attr). For example: get_attr(instance, name).
08:05:14 <ifat_afek> That’s it for me
08:05:29 <ifat_afek> Who’s next?
08:06:11 <yujunz> My update
08:06:18 <yujunz> Still working on suspect alarm
08:06:20 <yujunz> #link https://review.openstack.org/#/c/519250/
08:06:50 <yujunz> I realized that how to aggregate it with monitored alarm need to be clarified
08:07:10 <yujunz> Thanks to idan_hefetz reminding
08:07:41 <yujunz> I'm not quite familiar with the value normalization and aggregation in current code.
08:07:50 <yujunz> Looking into it and will update the blueprint soon.
08:08:11 <yujunz> Besides I added it to the topic for coming PTG
08:08:31 <yujunz> #link https://etherpad.openstack.org/p/vitrage-ptg-rocky
08:09:11 <ifat_afek> yujunz: Good idea. In general there are four states:
08:09:18 <yujunz> This part seems to be a major deviation from ZTE's use case
08:09:18 <ifat_afek> 1. state - as appears in the datasource
08:09:31 <ifat_afek> 2. vitrage state - the deduced state
08:09:56 <ifat_afek> 3. aggregated state - combined from the datasource(s) and vitrage. Could be practically anything, depending on the datasource
08:10:33 <ifat_afek> 4. operational (aka normalized) state - one of 4-5 predefined values, needed by the UI (to show red/yellow/green status)
08:10:42 <ifat_afek> But I’m not sure this is what you are talking about...
08:10:43 <yujunz> As far as I know, we prioritize the value by time, currently in vitrage, it is ordered by configured priority then create time.
08:11:07 <ifat_afek> Ok, so it is an interesting discussion
08:11:45 <yujunz> I'll discuss with the ZTE's project team to see how to resolve it.
08:11:48 <ifat_afek> The issue is the aggregated state. The operational state is a normalized version of the aggregated one, so I think this part can remain the same
08:12:13 <yujunz> Yes. Thank you for the inputs, ifat_afek
08:12:22 <ifat_afek> Ok, we’ll be happy to hear your ideas
08:12:39 <idan_hefetz> yujunz: is your issue only with state or all the actions?
08:12:51 <yujunz> With raise_alarm action
08:13:06 <ifat_afek> I assume also with set state?
08:13:19 <idan_hefetz> OK, i will try to think about it too :)
08:13:32 <yujunz> I think state is not used in our fault model at the moment
08:13:40 <yujunz> All the RCA is about alarms
08:13:41 <ifat_afek> Ok.
08:13:58 <yujunz> That's all from me
08:14:22 <najjar> i will update o/
08:14:46 <najjar> update on graph snapshot aka(with its new name) graph persistor.
08:14:55 <najjar> #link https://review.openstack.org/#/c/530650
08:15:10 <najjar> It is a part from Vitrage HA and History Vision
08:15:19 <najjar> #link https://docs.openstack.org/vitrage/latest/contributor/vitrage-ha-and-history-vision.html
08:15:49 <najjar> I'm working now on patch 4 - considering and fixing all the comments.
08:16:07 <najjar> Please review and ask everything that comes in your mind
08:17:06 <najjar> I'm done updating
08:17:59 <ifat_afek> Thanks. Anyone else?
08:18:19 <peipei> I'll update.
08:18:30 <peipei> I am working on sending parsed alarms to the message bus last week.
08:18:38 <peipei> Bp: #link https://review.openstack.org/#/c/486812/12/specs/queens/approved/snmp-parsing-service.rst
08:19:07 <peipei> And now I am adding tempest tests.
08:19:31 <peipei> But I'm confused that should datasources futher process parsed alarms, and which datasource will process them?
08:19:46 <ifat_afek> How are you adding the tempest tests? do you have a mock that sends snmp traps?
08:20:02 <ifat_afek> I understood that you have your own ZTE datasource, right?
08:20:50 <peipei> Yes, I have a mock rhat sends snmp traps.
08:21:44 <peipei> If graph has added an alarm vertex, the test is passed.
08:21:50 <peipei> We add our own alarm datasource that process with snmp triggered traps, but community protogenetic alarm datasource does not deal with snmp triggered traps.
08:22:17 <peipei> Should I add codes in the datasource Doctor to process with them?
08:22:44 <ifat_afek> That’s a good question… so you would like to have a tempest so you could know if something breaks, but your datasource is not upstream
08:23:26 <peipei> Yes.
08:24:22 <ifat_afek> idan_hefetz changed the Doctor datasource so it can handle different types of alarms. Maybe you can use it. I’m not sure about it, and idan_hefetz is not here at the moment. But I think this should probably be the solution
08:25:04 <ifat_afek> Let us know if you need help with that
08:25:46 <peipei> Ok. Then I will process with the snmp alarms in Doctor datasource.
08:25:50 <ifat_afek> And note that the tempest tests are just about to move to a new location: https://github.com/openstack/vitrage-tempest-plugin
08:26:05 <peipei> Thanks o/
08:26:17 <peipei> That's all from me.
08:26:25 <ifat_afek> This was defined as a Queens community goal, and it will happen once the following change is approved:
08:26:34 <ifat_afek> #link https://review.openstack.org/528528
08:27:17 <ifat_afek> Also note that currently changes in Vitrage will trigger the tempests; but changes in vitrage-tempest-plugin will NOT trigger the tempests. This is another change that has to be done
08:27:57 <ifat_afek> And BTW, thanks yujunz for reminding me: you are all welcome to add ideas to the PTG etherpad:
08:28:05 <ifat_afek> #link https://etherpad.openstack.org/p/vitrage-ptg-rocky
08:28:20 <ifat_afek> Anyone else has updates?
08:29:46 <ifat_afek> #topic Queens roadmap follow-up
08:29:59 <ifat_afek> A reminder about the Queens release timeframe:
08:30:04 <ifat_afek> The release deadline for python-vitrageclient: January 25
08:30:14 <ifat_afek> This week is also declared as the “feature freeze”, although we are not committed to it (as we are following the cycle-with-intermediary release model).
08:30:19 <ifat_afek> The release candidate deadline is February 5-9
08:30:41 <ifat_afek> I updated some of the statuses on the etherpad with the roadmap:
08:30:48 <ifat_afek> #link https://etherpad.openstack.org/p/vitrage-ptg-queens
08:32:05 <ifat_afek> Important tasks that I believe will be finished by January 25: Mistral integration, configurable notifications, graph persistor, templates CRUD
08:32:23 <ifat_afek> That’s it for me
08:33:16 <yujunz> For the complete features related to proactive RCA, it seems not possible to catch up with the date.
08:33:30 <yujunz> But I do hope to complete suspect alarm in this release.
08:33:51 <ifat_afek> Ok. Will you be able to use it, if it’s only this part?
08:35:40 <yujunz> I would say not fully functional but viable.
08:35:47 <ifat_afek> Ok
08:37:09 <ifat_afek> #topic Open Discussion
08:37:22 <ifat_afek> Anything else we should discuss?
08:37:37 <yujunz> A bit curious on a patch under review
08:37:39 <yujunz> #link https://review.openstack.org/#/c/530629/
08:37:53 <yujunz> What is the purpose of adding controller node?
08:38:29 <ifat_afek> Well - we are showing controller nodes in our Nokia solution, and Yuval Adar realized that Nova can actually give us this information.
08:39:17 <ifat_afek> The question is, actually, why filter it *out*. This is the current behavior, that only hosts are returned by the nova.host driver
08:39:38 <ifat_afek> And ideally, we would like Vitrage to have as much information as possible, right?
08:39:44 <yujunz> OK. I was thinking it is not a part of virtual infrastructure resource, but the manager.
08:40:22 <ifat_afek> Vitrage can be used to show resources of all layers - infra, physical, virtual, etc.
08:40:29 <ifat_afek> But this is the TripleO controller
08:41:23 <yujunz> OK. Understood.
08:42:11 <yujunz> Another question is about Rocky PTG time table. Is the time slot allocated?
08:42:35 <yujunz> I might be interested to join some discussion in other projects
08:42:40 <ifat_afek> All we have is the etherpad
08:42:42 <yujunz> Trying to make a time table
08:42:51 <ifat_afek> I still didn’t see an agenda of the PTG. Have you?
08:43:13 <yujunz> You mean from the organizer?
08:43:21 <ifat_afek> Yes
08:43:25 <yujunz> No
08:43:39 <ifat_afek> We should know, as a first stage, on which dates we have the room available
08:43:42 <yujunz> I am also wondering why there is so few updates from the PTG organizer...
08:43:53 <ifat_afek> But it might be a good time to start adding ideas to the etherpad
08:44:20 <ifat_afek> These two weeks everyone is on vacation… but I understand what you are talking about
08:44:31 <yujunz> There are few discussion in the mailing list. I don't know where to get more information.
08:44:40 <ifat_afek> Once I hear something I will notify everyone
08:44:49 <ifat_afek> About the PTG?
08:44:50 <yujunz> How was your last attendance to PTG?
08:44:54 <yujunz> in Denvor?
08:45:07 <ifat_afek> They sent a document with proposed agenda, and after a few weeks it was updated
08:45:44 <ifat_afek> The agenda was very high level: first two days were cross-project, and the next three days were for project specific discussions
08:46:00 <ifat_afek> On the project-specific, only rooms were allocated, and the agenda was managed by internal etherpads
08:46:28 <ifat_afek> Then the created an html page where the PTLs (or someone else) could send update whenever a new discussions was started
08:46:42 <yujunz> OK. Let's wait and see. Thank you for the information ifat_afek
08:46:55 <ifat_afek> I got the feeling that the agenda kept changing
08:47:29 <ifat_afek> It’s not as organized ahead as the big summits
08:47:41 <ifat_afek> Anyway, I’ll keep you updated once I know something
08:48:18 <yujunz> That would be good. Thank you
08:49:02 <ifat_afek> Any other issue?
08:49:48 <yujunz> No more from me
08:49:59 <ifat_afek> Ok
08:50:08 <ifat_afek> See you next week :-)
08:50:20 <eyalb> bye
08:50:32 <idan_hefetz> bye
08:50:47 <ifat_afek> #endmeeting