09:00:41 #startmeeting vitrage 09:00:42 Meeting started Wed Dec 16 09:00:41 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:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:46 The meeting name has been set to 'vitrage' 09:01:06 Hi everyone :-) 09:01:10 hi 09:01:16 Today’s agenda: 09:01:20 ין 09:01:22 hello 09:01:24 Hello :) 09:01:26 hi :) 09:01:35 -:) 09:01:49 Hi 09:01:54 hi 09:02:47 Hi 09:03:11 hey 09:04:50 hi 09:05:06 Hi again. Our agenda: 09:05:14 * Current status and progress from last week 09:05:25 * Review action items 09:05:35 * Next steps 09:05:53 * Open Discussion 09:06:08 #topic Current status and progress from last week 09:06:21 First a reminder: Gerrit will be upgraded today at 17:00 UTC, and will be down for a few hours 09:06:58 It turns out that networkx is already a part of OpenStack :-) 09:07:04 Hi 09:07:13 a project named TaskFlow is already using it (version 1.0), which means we can use it too without a need for someone to approve it (as a 3rd party library) 09:07:57 My update: I verified that we can create a semi-event alarm with no alarm actions and set its state from the api. 09:08:16 great 09:08:20 No notifications are sent about the state change, but for mitaka we don’t need them. 09:08:32 . I’m still checking if there are better alternatives. Once I’m done, I’ll update ceilometer blueprint. 09:08:55 We had a meeting with Marina and Eliran, who explained to us the basics of tempest tests. 09:09:03 Marina, do you want to update? 09:09:41 My update: The vitrage_tempest_tests folder appears temporarily under "vitrage project", but it's purely tempest tests for rca block. 09:10:02 cool, thanks 09:10:47 BTW, some of us got a mail where we can select a name for N* release 09:11:09 Who else wants to update? 09:11:10 Also the "O" release 09:11:15 We had another vitrage synchronizer desgin meeting, and we need to learn the some oslo components to proceed 09:12:09 I also check the ability of ceilometer to monitor switches 09:12:24 any interesting conclusions? 09:12:30 Not yet 09:12:35 ok 09:13:25 I've been working on upgrading the mock functionality, to match the updated format of nova synchronizer info. 09:13:40 and in the process, also supporting more "logical" flows 09:13:57 hope to get it done in a few days, bugs allowing :) 09:14:03 thats it 09:16:05 I am still working on authentication and authorization of the client and server 09:17:09 we need to figure out what are the roles for authorization for our api 09:17:43 who can see the the topology for example 09:17:52 thats it 09:18:09 Ohad, what do you think? 09:19:40 good point - we need to further look in it. I think that we can start with admin. 09:20:03 makes sense 09:20:40 Eyal, Elisha and I have defined the minimal functionality needed at this point to allow graph queries for the first use case. 09:20:51 That is, perform a query by depth with filtering over the the edges and vertices properties. 09:21:08 great 09:21:30 Eyal regards your question, I think we need to filter the resources the user see by his project 09:22:27 but does it make sense that a customer can see the topology of the entire system? we need to think about it... 09:22:54 QA team started working on creating basic tempest tests which will later on be integrated and monitor our progress when things will start running on Vitrage 09:23:02 Only Amanda can see the entire system. 09:23:08 regarding the alarms, emalin you are right - each customer should see the relevant alarms 09:23:17 Who is Amanda ? 09:23:52 You don't know who Amanda is? 09:24:39 ShaharTesterChoi thanks! 09:25:55 I think that each member should see the vitrage RCA relevant to his project 09:26:29 of course. the question is what if the root cause is an alarm that belongs to the admin 09:27:31 Amanda is the datacenter owner. I agree that each user should only see resources that he's aloowed to use. We do need to think who to give access to the full picture as this has lots of value. Could be per deployment 09:27:41 we should check what is OpenStack policy regarding visibility of admin resources to the projects 09:28:15 I think that a customer should see the alarm belong to admin (example: host alarm) just for what relevant to him but not the entire system. 09:28:46 Problem is that a host may serve more then one tennant 09:29:21 maybe a customer should not see all information for admin resources but at least to know that this alarm/s are part of the root cause pattern, 09:30:55 we should keep our policy as we do in cloudband 09:30:56 Ohad, I agree. so let's make it the behavior for now 09:31:29 let's move on. who else wants to update? 09:31:37 we need to enforce it in the UI and API? 09:32:05 the API will make the decisions I think 09:32:29 based on the user that called this API 09:32:53 great 09:32:59 omer_etrog, any updates regarding the UI progress? 09:33:14 Makes sense 09:33:58 we in a process to create a POC for the entity graph 09:34:47 great, thanks 09:34:53 any other updates anyone? 09:35:21 let's move on to the action items 09:35:26 #topic Review action items 09:35:39 • ifat_afek check Aodh integration workaround and update Ceilometer blueprints 09:36:03 this is in progress. like I already said, I have a workaround, but still looking for a better solution 09:36:26 #action ifat_afek check Aodh integration workaround and update Ceilometer blueprints 09:36:37 • decide how to implement list alarms UI 09:36:52 For now the decision is that there will be Vitrage UI for list alarms (different from the ceilometer horizon UI that ^Gal^ checked). 09:37:07 Vitrage UI will get the list of alarms from Aodh 09:37:18 • start discussing the tempest tests 09:37:40 Done, need to continue the discussions. 09:38:37 • finalize synchronizer design 09:38:52 synchronizer design is in progress 09:39:17 • checkin a basic synchronizer FW for the vitrage graph to interface with and see that we are on the same page 09:39:36 It's also in progress 09:39:39 this was nadav_yakar's action item, and he is on vacation. let's wait for his update 09:40:01 #action nadav_yakar checkin a basic synchronizer FW for the vitrage graph to interface with and see that we are on the same page 09:40:11 • elisha_r end-to-end API flow for the first use cases 09:40:36 Idan, eyal and I have started looking into this, as idan updated 09:42:29 • create puppet-vitrage project (maty) 09:43:21 Aya's response (she has a technical problem to connect): still in progress. the puppet has a new convention, we will be the first ones to use it, so it takes more time 09:43:46 Aya: we are waiting for +2 on our change 09:44:01 #topic Next Steps 09:45:20 we should go on with the tempest tests, and understand what kind of tests we want to write 09:46:42 we should also start thinking about our documentation - developer's guide, how to, etc. 09:47:17 #action ifat_afek check how we should add vitrage documentation 09:47:18 Please notice that we added Vitraege Exception and a list of Vitrage errors. You can use it in your code and you can add new relevant errors 09:48:04 anything else? 09:48:26 I noticed that we did not yet talk about the set-state use case. We don’t even have a blueprint for it. Note that it means that the topology view will show Nova state for all entities, and not the vitrage deduced state. 09:50:24 Good point - lets scedule a meeting and to disccuss on it and next Vitrage use case 09:50:29 ok 09:50:46 #action decide on Vitrage next use cases 09:50:54 #topic Open Discussion 09:51:05 anything? 09:51:17 goodbye then :-) 09:51:22 bye 09:51:25 Bye :) 09:51:30 see you next week 09:51:33 :) 09:51:35 goodbye :) 09:52:37 #endmeeting 09:53:41 #endmeeting 09:53:47 #endmeeting 09:54:32 #endmeeting