08:14:46 <adi__> #startmeeting pinpoint
08:14:46 <collabot> 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 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:14:46 <collabot> The meeting name has been set to 'pinpoint'
08:15:07 <adi__> hi all
08:15:23 <Ohad> hi
08:15:29 <ifat_afek_> hi
08:15:46 <adi__> it seems that we will not have goto meeting on this meeting so I will handle it in the IRC
08:16:18 <adi__> As this meeting is the first one , maybe we should introduce ourselves
08:16:57 <adi__> I am Adi form Huawei and I lead the project
08:18:14 <Mishael> hello ! I'm Mishael from Huawei, working also on the Pinpoint project
08:18:35 <Ohad> ohad, product manager in CloudBand, Alcatel-Lucent. we are working on Vitrage - OpenStack project for RCA.
08:19:15 <ifat_afek_> Hi :-) I am Ifat, a software engineer working on CloudBand, Alcatel-Lucent. PTL of Vitrage
08:19:55 <adi__> Hi Malla anything you would like to share?
08:21:14 <adi__> 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 <ifat_afek_> Can you send us the link?
08:21:54 <Malla> Hi all, this Malla, working in Docomo Euro-labs as a researcher
08:21:59 <adi__> sure, just a minute
08:23:31 <adi__> https://wiki.opnfv.org/projects/pinpoint
08:24:50 <adi__> On the page there is a link to the project presentation and to the use case document
08:25:40 <adi__> Did you find it?
08:26:11 <ifat_afek_> yes, thanks
08:27:46 <Malla> 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 <Malla> https://wiki.opnfv.org/meetings/multisite
08:28:08 <adi__> 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 <Malla> CET 10:00 am - 11:00 am
08:28:40 <adi__> Hi Malla , I will solve the goto meeting issue one way or another
08:28:49 <Malla> :)
08:29:13 <adi__> In which time zone are you?
08:29:42 <Malla> CET
08:30:31 <adi__> Ok I will schedule the meeting for next week in a time that will be conviniant for all of us
08:30:53 <adi__> Malla did you find the document?
08:31:01 <Malla> I am fine with the present timing.
08:31:16 <Malla> yes
08:32:07 <adi__> The document contains 12 failures, some of them from the physical domain and some of them are from the virtual domain
08:33:47 <adi__> 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 <adi__> Any questions on the structure of the document?
08:35:18 <Ohad> API needed for each failure are APIs for the RCA engine?
08:35:54 <adi__> OK, lets go over the second use case which is simple
08:37:23 <adi__> 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 <adi__> 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 <adi__> Is it this clear?
08:41:32 <adi__> Ok, lets go on the second use case
08:41:50 <adi__> physical switch port down
08:42:35 <Ohad> sorry, I disconnected.
08:43:19 <adi__> 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 <Ohad> symptoms are for use cases without redundancy. are you intent to add also HA?
08:44:08 <adi__> It also depend on the quality of the redundancy mechanism
08:44:30 <adi__> The analysis should be on both with and without HA
08:45:35 <adi__> In this draft i wrote only on non HA, We should add the "with" HA" as well
08:47:12 <adi__> So the symptoms will be the ones written in the second column
08:48:01 <adi__> and the information required is the one mentioned in the third column
08:48:26 <adi__> we must have API to reveal this information
08:48:29 <Malla> What do you mean by with HA?
08:48:34 <adi__> any questions?
08:48:48 <adi__> High availability
08:49:55 <Malla> :) you said that these are non HA scenarios, then what is with HA scenarios?
08:50:43 <adi__> 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 <adi__> in HA scenario the vms and applications will not report any failure as they will not experiance it
08:52:07 <adi__> so it changes the picture
08:53:07 <adi__> I will expand the document to include HA and non HA scenarios for the exisiting use cases
08:53:35 <adi__> do you think we should add/ remove use cases
08:53:48 <adi__> anyone?
08:54:35 <Ohad> 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 <adi__> 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 <ifat_afek_> 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 <adi__> 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 <ifat_afek> sorry, I was disconnected
09:00:28 <adi__> We are out of time, lets close the meeting and meet next week this time with goto meeting
09:00:51 <Ohad> ok, thanks.
09:00:58 <ifat_afek> thanks, see you next week
09:01:15 <adi__> Thank you all
09:01:23 <adi__> #endmeeting