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