09:00:20 #startmeeting vitrage 09:00:21 Meeting started Wed Nov 18 09:00:20 2015 UTC and is due to finish in 60 minutes. The chair is ifat_afek_. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:25 The meeting name has been set to 'vitrage' 09:00:35 Hi everyone  09:00:48 Our agenda today: 09:00:57 * Current status and progress from last week 09:01:08 * Review action items 09:01:18 * Next steps 09:01:24 * Open Discussion 09:01:38 #topic Current status and progress from last week 09:01:58 Almost all of our blueprints are up to date, and in the process of being reviewed. 09:02:13 . Missing one blueprint with the use cases we are about to support in mitaka. 09:02:24 Please invest the time to review each-other’s blueprints. 09:02:46 We have also asked people from Pinpoint, Doctor, Ceilometer and Monasca to review our blueprints. We got some reviews from Gal Sagie from Pinpoint, which is great. 09:03:06 Let’s try to finish the review process by next week. 09:03:53 To clarify: the missing bp is related to the RCA/deduced alarm use case. initial use cases for mitaka in other areas of Vitrage have been determined 09:04:28 We had a design meeting where we decided on our first use case – show all topology 09:04:38 We split the use case into tasks and assign them between us.. 09:05:17 Show all Topology use case includes building the entity graph with Nova.instances and Nova.hosts and exposing show topology API. 09:05:35 we have also made a progress in our synchronizer design - 09:06:04 it is now adapted to listen for openstack message bus notifications 09:06:27 in addition to the former design which samples OS services via REST API 09:07:05 once we finalise this design and break it down to tasks, 09:07:23 I am going to update our blueprint and gerrit accordingly 09:07:52 great. once the API is finished, please add it to vitrage wiki page 09:08:11 lhartal, that goes for your API as well 09:09:30 #action lhartal document API in Vitrage wiki page 09:10:48 ifat, we are not currently planning on revealing any external API 09:11:06 ok, so no need to document it 09:11:31 I will clarify - the latest design is that we are going to be used as an internal library by vitrage 09:12:14 cool. how is the UI progressing? 09:12:26 Hey.... We have some good news ! 09:12:58 We have "Hello World" plugin working on the Horizon 09:13:06 #link http://docs.openstack.org/developer/horizon/plugins.html?cm_mc_uid=47957347875914472483394&cm_mc_sid_50200000=1447685453 we use this as a reference to our vitrage horizon plugin 09:14:03 We have a new launchpad for the UI Vitrage project, So we'll move our blueprints 09:14:05 https://launchpad.net/vitrage-dashboard 09:14:25 #link https://launchpad.net/vitrage-dashboard 09:15:42 that's great news 09:15:59 We got some help from robcresswell and it was very helpful 09:16:49 ok, thanks. any other updates anyone? 09:18:13 We created a new python-vitrageclient project and launchpad 09:18:35 added some files 09:18:46 great! 09:20:21 #link https://launchpad.net/python-vitrageclient 09:21:02 also moved the cli blueprint from vitrage to vitrage-pythonclient 09:21:47 great. so we have one blueprint in vitrage-pythonclient launchpad, and another blueprint on vitrage-dashboard launchpad 09:22:15 I am currently looking for a best practice for concurrency handling in openstack projects. 09:22:27 Although I see that many projects already use the Eventlet library, I’d rather work with python’s multiprocessing library, since for my understanding, the later works with processes, in contrast to eventlet. 09:22:59 and do you know of any project using the multiprocessing library? 09:23:04 or all use Eventlet? 09:23:31 it is better than use the threading in python 09:23:33 I have taken a peek at Nova and seen they uses Eventlet, 09:23:59 I think that ceilometer should be good reference 09:24:16 but GNOCCHI uses the standard python multiprocessing library\ 09:24:46 I am about to talk with Julian, their PTL 09:24:49 Vitrage is more similar to ceilometer than nova 09:25:37 to my understanding if your program is mostly oi bound then there is no issue with the GIL so you can use threads 09:26:04 #link https://docs.python.org/2/library/multiprocessing.html 09:26:39 GIL is always released when doing I/O 09:27:09 #link https://docs.python.org/2/glossary.html#term-global-interpreter-lock 09:28:32 thanks Eyal. I will have a look, although that I believe that we'd rather use processes if possible 09:29:20 ok. let's move on 09:29:26 #topic Review action items 09:29:46 let's see if what was our progress regarding the action items from last week 09:30:05 1. ifat_afek make sure we finish updating our blueprints in the following days 09:30:16 this is almost done. one blueprint is missing 09:30:36 #action ifat_afek finish the last blueprint. 09:30:55 2. talk with them at room openstack-searchlight 09:32:49 we have used searchlight for a reference for using oslo messaging 09:33:20 so the way that I see it, this AI is done 09:33:30 no need to talk with them? 09:33:44 not at this stage 09:33:47 ok 09:33:54 3. all finish the discussions regarding the synchronizer, and optionally update its blueprint 09:35:07 as I said, we are going to finalize our blueprints once we finish our design and breakdown our tasks 09:35:20 so it's an action item for next week? 09:36:05 #action nadav_yakar update synchronizer blueprint and gerrit 09:36:14 thanks. moving on 09:36:24 4. all assign blueprints to developers 09:36:47 done. I assigned the correct developer for each of the blueprints that are going to be implemented in the coming few weeks. Some of them will be implemented by more than one person. 09:37:12 5. alexey_weyl contact Doctor guys, ask them to review our blueprints 09:37:44 I sent an email to Doctor PTL 09:37:53 and main Doctor contributers 09:38:04 But they hasn't answered yet 09:38:32 If the won't answer untill tommorow, I will send them a remainder 09:39:33 ok 09:39:35 next 09:39:37 6. ifat_afek contact PinPoint guys, ask them to review our blueprints 09:39:57 I sent an email to PinPoint guys. Adi said he would review our blueprints. Gal already did 09:40:13 7. elisha_rosenswei check horizon alarm management blueprint 09:40:56 <^Gal^> I can update 09:41:05 so we verified the existence of the ceilometer (actually, Aodh) api to list all the alarms, and began checking the ui for this 09:41:06 go ahead 09:41:24 <^Gal^> so the Horizon blueprint assigned to sanjana 09:41:44 <^Gal^> I tried to contact him via mail 09:42:10 <^Gal^> to offer our assistance and ask where things stand 09:42:28 <^Gal^> I don't know if he's still involved with openstack 09:42:42 when did you email him? 09:42:42 <^Gal^> his account doesn't seem active, and I didn't get a reply back 09:42:47 <^Gal^> week ago 09:43:10 <^Gal^> I would attend Horizon meeting today and ask their ptl for advise 09:43:24 great 09:43:42 so it's an action item 09:43:48 One thing we will need to decide, though, is if we want to use this Aodh ui, or a different one. The main consideration here is to think what we will do if and when we integrate with other projects , like Monasca 09:44:33 #action ^Gal^ understand the status of ceilometer alarms ui blueprint 09:44:42 <^Gal^> sure do, thanks 09:46:48 elisha, I think that if we want to push deduced alarms to AODH, we better write the UI on top of AODH 09:48:02 who wants to take this action item? 09:48:17 I'll take it\ 09:49:21 #action elisha_rosensweig decide on where to get the list alarms ui 09:49:29 #action nadav_yakar find a best practice for concurrency handling in openstack projects 09:50:06 ok. let's move to the next topic... 09:50:07 #topic Next Steps 09:50:16 I think we talked about most of them already 09:50:42 #action finish review of the blueprints 09:50:57 hopefully by next week our blueprints should pass review 09:51:54 anything else? 09:52:04 #topic Open Discussion 09:54:14 One thing we will need to decide regarding the interaction of the Synchronizer and the graph. Do we assume that all the information, including which resources to attach to in the graph, is contained in the event? or can/should the graph query for additional info after an event arrives? 09:54:41 Good question Elisha 09:56:18 elisha, we are still in the process of investigating which data is available for each entity on the message bus 09:56:40 I think it's specific to each entity and reach event 09:56:43 this is an ongoing task 09:57:00 *each 09:57:07 true 09:57:18 hence it would be an ongoing task 09:57:30 Hopefully we want to get all the needed info and the initial event. this will help us in performence - because we dont want to query back and forth for each event 09:58:09 We should sit and check this more thoroughly 09:58:48 we need to finish, let's discuss it later 09:59:15 #action decide what information is part of the synchronizer events 09:59:21 thanks everybody 09:59:46 #endmeeting