08:14:46 #startmeeting pinpoint 08:14:46 Meeting started Thu Dec 3 08:14:46 2015 UTC. The chair is adi__. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:14:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:14:46 The meeting name has been set to 'pinpoint' 08:15:07 hi all 08:15:23 hi 08:15:29 hi 08:15:46 it seems that we will not have goto meeting on this meeting so I will handle it in the IRC 08:16:18 As this meeting is the first one , maybe we should introduce ourselves 08:16:57 I am Adi form Huawei and I lead the project 08:18:14 hello ! I'm Mishael from Huawei, working also on the Pinpoint project 08:18:35 ohad, product manager in CloudBand, Alcatel-Lucent. we are working on Vitrage - OpenStack project for RCA. 08:19:15 Hi :-) I am Ifat, a software engineer working on CloudBand, Alcatel-Lucent. PTL of Vitrage 08:19:55 Hi Malla anything you would like to share? 08:21:14 I have put an initial version of the use case document on the pinpoint web page on the OPNFV site and this is going to be the starting point of the project 08:21:41 Can you send us the link? 08:21:54 Hi all, this Malla, working in Docomo Euro-labs as a researcher 08:21:59 sure, just a minute 08:23:31 https://wiki.opnfv.org/projects/pinpoint 08:24:50 On the page there is a link to the project presentation and to the use case document 08:25:40 Did you find it? 08:26:11 yes, thanks 08:27:46 Adi, maybe you have to talk with the Multi - site lead about the timing. They are having meeting an hour earlier, maybe they forgot the winter timing. 08:27:57 https://wiki.opnfv.org/meetings/multisite 08:28:08 I don't think it will be very usefull to do a common reading on the IRC so I suggest that we will go over the first one and then continue the process next week when we will have a goto meeting 08:28:09 CET 10:00 am - 11:00 am 08:28:40 Hi Malla , I will solve the goto meeting issue one way or another 08:28:49 :) 08:29:13 In which time zone are you? 08:29:42 CET 08:30:31 Ok I will schedule the meeting for next week in a time that will be conviniant for all of us 08:30:53 Malla did you find the document? 08:31:01 I am fine with the present timing. 08:31:16 yes 08:32:07 The document contains 12 failures, some of them from the physical domain and some of them are from the virtual domain 08:33:47 in the next column there are the symptoms that each failure will cause and in the next column the requiered info/ API needed to locate the failure 08:34:04 Any questions on the structure of the document? 08:35:18 API needed for each failure are APIs for the RCA engine? 08:35:54 OK, lets go over the second use case which is simple 08:37:23 The APIs are the ones that the RCA engine will need to activate to get the required information from the different entities relevant for this failure 08:39:05 for example the virtual topology may be acquired from Nova and Neutron so we have to go to those project and find out if they hold the information on the virtual topology and if they have an API that we can use to get it 08:39:35 Is it this clear? 08:41:32 Ok, lets go on the second use case 08:41:50 physical switch port down 08:42:35 sorry, I disconnected. 08:43:19 It depend of course on the specific port that went down, is it between switches, switch and TOR switch, TOR switch and host 08:43:57 symptoms are for use cases without redundancy. are you intent to add also HA? 08:44:08 It also depend on the quality of the redundancy mechanism 08:44:30 The analysis should be on both with and without HA 08:45:35 In this draft i wrote only on non HA, We should add the "with" HA" as well 08:47:12 So the symptoms will be the ones written in the second column 08:48:01 and the information required is the one mentioned in the third column 08:48:26 we must have API to reveal this information 08:48:29 What do you mean by with HA? 08:48:34 any questions? 08:48:48 High availability 08:49:55 :) you said that these are non HA scenarios, then what is with HA scenarios? 08:50:43 In most physical networks we have more then one connection between each two points so we will not loose service if a physical failure happened 08:51:31 in HA scenario the vms and applications will not report any failure as they will not experiance it 08:52:07 so it changes the picture 08:53:07 I will expand the document to include HA and non HA scenarios for the exisiting use cases 08:53:35 do you think we should add/ remove use cases 08:53:48 anyone? 08:54:35 Adi: from your point of view, who should hold the topology? the RCA engine? or it has to be build ad-hoc from the different sources each time when you have a failure? 08:56:45 Both are possible, I have no clear opinion on this yet, both scenarios require the same API which is my focus right now 08:57:18 another question: are all of these use cases written here for RCA purpose? so in case of HA some of them will not exist at all? in Vitrage we can raise deduced alarms also if everything works fine (thanks to HA), but just as a warning that something may go wrong 08:59:39 I agree, this is a good point, we can talk about next week after I will split the document to HA and non-HA 09:00:03 sorry, I was disconnected 09:00:28 We are out of time, lets close the meeting and meet next week this time with goto meeting 09:00:51 ok, thanks. 09:00:58 thanks, see you next week 09:01:15 Thank you all 09:01:23 #endmeeting