08:00:43 #startmeeting vitrage 08:00:44 Meeting started Wed Jun 21 08:00:43 2017 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:47 The meeting name has been set to 'vitrage' 08:00:50 Hi :-) 08:00:54 \o/ 08:00:55 Hi 08:02:37 Hi :) 08:02:56 Hi 08:03:12 #topic Status and Updates 08:03:16 Hi 08:03:47 Reminder: Sydney CFP is open 08:03:56 #link https://www.openstack.org/summit/sydney-2017/call-for-presentations/ 08:04:03 Feel free to add your ideas to the etherpad below. The CFP deadline is July 14th. 08:04:10 #link https://etherpad.openstack.org/p/vitrage-sydney-cpf 08:04:44 For now what we had in mind is a vitrage project updates session (as we had in Boston), an advanced use cases session, and the hands-on lab again 08:04:56 More ideas are welcome 08:05:39 Last week was the OPNFV Summit in Beijing. I don’t have any update regarding that. 08:05:54 yujunz, dwj: was there anything interesting? 08:06:13 I have some updates from doctor project 08:06:45 We did some experimental improvement about notification time performance 08:07:09 By replacing nova reset-state with a direct notification to consumer 08:07:41 #link https://docs.google.com/presentation/d/1thwtzSLSDcfZsRvDWnZmEFipux9RzQPPyjLLN7BXOOs/edit 08:08:09 Thanks for the link, I’ll go over it after the meeting 08:08:17 The consumer is a VNFM? 08:09:08 Could be. Or application manager if in a more general concept 08:09:22 Hi guys 08:09:32 The one who cares about the resource status and do the active/standby switch 08:10:13 The results is from sample inspector and congress, it could be quite interesting to see how vitrage performance in this part 08:10:53 Of course 08:11:10 And we tried to use osprofiler to reveal the details 08:11:35 I need to finish adding Vitrage to the Doctor test (I guess I will need to refactor my existing change, since many changes were made in the tests). Then I’ll be happy to do the performance tests for Vitrage 08:11:36 Hi :) 08:11:37 But met some limitation on asynchronous operation such as event notification 08:12:00 Where did you use the osprofiler? in which project(s)? 08:12:32 Some details in slide 25 08:12:43 Plus the sample inspector and monitor 08:13:13 What does a star stand for? 08:13:26 tick for supported, start for needed :-) 08:13:36 :-) 08:13:40 As written in title 08:13:59 That’s very interesting, I’ll be happy to add Vitrage to the tests 08:14:24 That's the basic content about the presentation. 08:14:55 Thanks for the update. Was there something interesting in the design sessions? 08:15:16 #link https://etherpad.opnfv.org/p/doctor-profiler 08:15:42 The etherpad page of the discussion for profiling 08:15:56 Thanks! 08:16:35 #link https://etherpad.opnfv.org/p/doctor-maintenance 08:16:44 #link https://etherpad.opnfv.org/p/doctor-python 08:16:58 Some other things discussed, but not highly related to vitrage 08:17:29 I’ll go over it, thanks for the links 08:17:47 I didn't attend the other two, you may ask tomi or dwj for details if anything unclear :-) 08:18:00 Ok :-) 08:18:29 Nothing special from my side, just continue to work the refactoring with python. 08:18:46 Does it mean refactoring the tests? 08:18:56 Yes, test script 08:19:30 Ok, so I’ll talk with you when I’ll get back to working on the Vitrage script 08:20:06 Too bad I didn’t finish it back then, I guess… 08:20:15 with pleasure. :) 08:20:25 Thanks! 08:20:53 So here is my update: I started implementing the external actions spec, as a first step to support the integration with Mistral 08:21:07 #link https://blueprints.launchpad.net/vitrage/+spec/support-external-actions 08:22:11 I’m almost done with the first stage, of adding an execute_mistral action in the template, and converting it to a general-purpose ExecuteExternal action in the code. The ExecuteExternal action can later on be used for an integration with Congress for example 08:22:36 I also did some refactoring in the template validation code, so it will be easier to add external actions validations 08:22:57 I will push this change before I continue to the actual execution phase (of calling the Mistral notifier) 08:23:00 +1 for that 08:23:01 That’s it for me 08:23:15 i will update 08:23:31 pushed two patches to gerrit 08:23:41 one for client and one for server 08:24:27 to support different kind of authentication types 08:25:03 first stage is to be able to work with vitrage without authentication i.e. without keystone 08:25:28 use will configure the auth_mode to be noauth in vitrage 08:25:46 and will use the client with the noauth plugin 08:26:09 which will ask for an endpoint , user and project id 08:26:23 when connecting to vitrage 08:26:28 What is `noauth` for? Just for development purpose or there is also use case in production? 08:26:59 second phase i will implement a keycloak plugin to use instead of keystone 08:27:13 you can use noauth for testing 08:27:46 and if you want to use it in your own project and you dont want to use keystone or any other authentication 08:28:10 I a also added some api test for the vitrage api 08:28:21 and did some refactoring of old code 08:29:00 and added a healthcheck option for vitrage which will return 200 ok when calling with /healthcheck url 08:29:14 Cool 08:29:24 Who is calling the healthcheck? 08:29:32 this ca be used in load balancers 08:29:46 no one at the moment 08:30:20 but if you have an ha proxy or zabbix that wants to check the api you can use ir 08:30:45 it only retruns 200 ok to see that its alive 08:31:05 its a feature added by oslo middleware that other projects use 08:31:24 please review the changes 08:31:28 thats all 08:31:37 Ok, I’ll review. Thanks! 08:32:27 Does it reflects the living status of api server? Or it does the healthy checks on other services such as listener, graph and etc? 08:33:05 yujunz: we got some requirements to use Vitrage in a non-openstack environment. Since it is architectured in a pluggable way, you can connect different datasources and the engine should work the same. This is one motivation for eyalb’s change 08:33:32 Of course, the main use cases of Vitrage are still openstack 08:33:38 just that the api is healthy ie the web server is alive 08:33:55 you can probably extend it to check the other backends 08:34:08 I see. Thanks eyalb 08:34:43 it has a detail option which is off at the moment 08:35:00 where you can give more information on the health status 08:35:36 #link https://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html 08:35:48 ifat_afek I assume you were answering my question on 'noauth', not 'healthcheck'. Yes, that would be useful for non-openstack usage. 08:35:58 Right 08:38:14 Anything else on that issue? 08:38:22 No more from my side 08:38:26 nope 08:38:37 I'll update 08:38:52 On the Northbound interface / rest notifications. 08:39:52 Aside from the notifications spec which I pushed last week, I pushed a "registration" spec for the http post notification's address / credentials / regex 08:40:49 Since I need DB, same as Alosha and probably a few other developers, I'm working on a requirements spec for sqlalchemy / db requirements / other for first / second stage development 08:41:15 we will need it also for CRUD templates 08:41:22 Yup 08:41:39 That doesn't mean that SQLAlchemy isn't currently developed in parallel by other team member(s) that might update in this IRC 08:41:50 That's it 08:42:09 you should look at other openstack projects that use sqlalchemy and see what is best 08:42:09 I will update 08:42:40 I went over AODH / Heat / Nova, and my requirements are adapted accordingly 08:43:07 I'm a strong believer on copy paste from good sources 08:43:13 +1 08:43:27 I will update 08:43:38 I have a several updates 08:43:47 "a" or "several" ? 08:44:32 1. I have opened a new linux service called the collector which will be responsible for collecting the data from the datasources 08:44:53 it will now use the rabbitmq to push the data to the processor 08:45:04 instead of using the multiprocessing queue 08:45:31 The reason we have done that is because of the HA vision 08:46:06 2. I have started to work on the Persistent Service which will be responsible to push the events to the Database 08:46:18 and also remove old events and snapshots 08:46:35 Wow, what is the database backend for the moment? 08:46:42 Already integrated? 08:46:44 The snapshot thread (oslo service) will run in the processor service because it needs to read the whole graph 08:47:31 it will be done by exporting the graph to a json using the networkx export and then push it to the db as a blob and then retrieve it from there when needed 08:47:39 yujunz: I have written an “HA vision” document which is still under review, you are welcome to read (and comment) 08:47:59 3. One of the things that are missing is the DB API that we don't have at the moment 08:48:13 Danny has talked about it a bit 08:48:20 #link https://review.openstack.org/#/c/455065/ 08:48:27 I have already started working on it, because we need it ASAP 08:49:10 yujunz: the database backend is what ever you have in the openstack/devstack 08:49:20 meaning mysql/postgres 08:49:44 We are using the new datamodel for history that we talked about in the HA vision 08:49:59 which is to use the event sourcing 08:50:22 it is all explained in the HA vision that Ifat has wrote 08:50:36 thats it for now 08:51:08 OK I'll review it after meeting. 08:51:20 Yujun, 08:51:44 yes? 08:51:52 You'll of course need to configure basic parameters in vitrag.conf, same as any other project 08:51:55 For example : 08:52:48 connection = mysql://root:pass@127.0.0.1:8999/vitrage 08:52:52 mysql_sql_mode = TRADITIONAL 08:52:56 idle_timeout = 3600 08:52:59 min_pool_size = 1 08:53:03 And so on.... 08:53:14 It's done in heat, aodh, and other. 08:53:34 Thanks danoffek 08:53:39 The SQLAlchemy implementation is already being written by Alosho. 08:53:42 Alosha 08:54:05 I will update now 08:54:17 I am working on the machine learning feature 08:54:17 I am working on the machine learning feature 08:54:33 As a first step, it will be able to find correlations between alarms in order to help to build new templates, based on this information 08:54:46 I hope I will finish this step soon, it's almost finished already 08:54:56 In the future this tool should be able to identify causation between alarms, not only correlation, and maybe also build templates automatically 08:55:10 But it will take some time till that happens 08:55:58 Great, thanks 08:56:03 thats all 08:57:01 An another update: I know that idan_hefetz did some performance improvements. But he is not here at the moment to update 08:57:17 Anything else? it was a long meeting ;-) 08:58:22 nope 08:58:36 bye 08:58:40 Bye 08:58:43 bye 08:58:49 bye 08:58:54 bye 08:58:55 bye bye 08:59:04 #endmeeting