04:00:39 #startmeeting masakari 04:00:41 Meeting started Tue Oct 9 04:00:39 2018 UTC and is due to finish in 60 minutes. The chair is samP. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:00:44 The meeting name has been set to 'masakari' 04:00:49 tpatil: Hi 04:01:50 sorry for long absence 04:02:05 I look into past meetings, 04:02:27 following patches to stable/queens are merged 04:02:37 Quick update: some of the patches are merged which are back ported into the stable/rocky 04:02:39 #link : https://review.openstack.org/#/c/590735/ 04:02:45 #link : https://review.openstack.org/#/c/562973/ 04:02:49 #link : https://review.openstack.org/#/c/591557/ 04:02:53 #link : https://review.openstack.org/#/c/599479/ 04:04:19 about 599479, I abandoned it, cause it was too early 04:04:28 I guess now it is oK 04:06:13 samP: correct 04:06:50 The above two patches back ported into the stable/rocky branch should be merged 04:09:05 it seems that we have a merge conflict for 599479 04:09:12 I will fix that and merge 04:09:30 tpatil: Thanks, I will review them 04:10:15 Once we merge them, I will propose release for new version for stable/queens, stable/rocky 04:10:44 Any other patches/bugs need to discuss? 04:11:59 No 04:13:10 One observation: Bug fixes are not mentioned in the release notes. I will check this issue. 04:13:44 tpatil: Thanks, you were mentioned it earlier also. 04:14:03 #topic Stein Work Items 04:14:08 #link https://etherpad.openstack.org/p/masakari-ptg-stein 04:14:32 Any updates on work items? 04:15:31 Notification implementation : It's in progress. 04:15:46 tpatil: great. 04:16:10 For apis, notifications are in progress. I hope it should be up for review in the next week 04:16:37 I will ping hoangcx about Proactive HA. 04:16:42 tpatil: great, thanks 04:17:10 I want to discuss about host/instance/process notifications. During execution of workflow for each of these notifications, I'm planning to emit notification/event information which will help operator to understand the current progress of the notification 04:17:36 right now, operator get only status info, i.e. running 04:18:11 Should this data be added as events/notifications? 04:18:28 if we decide to add it as events, we may need to add few tables to store this info 04:20:11 I think it useful for operators. I dont have exact idea about what tables we need to store this info. 04:21:19 Can you share some details later about what to store 04:22:01 for e.g. host notifications, it execute a workflow which contains more than one task. In each task, we can emit useful details to give operator some meaningful information. Like how many instances will be evacuated and what is the current progress, like evacuating 1 out of 10 instances, something like that. 04:25:41 To store this info, we will need to add few db tables if we decide to emit as a event rather than notifications. As you know notifications data is not stored in masakari db. It depends on the oslo_messaging_notifications driver 04:26:35 I think it should be stored as an event rather than notifications. 04:28:24 tpatil: OK understand 04:29:17 tpatil: #link https://review.openstack.org/#/c/473057/ 04:30:09 This is the original spec for this feature 04:30:19 the above event notification info will be stored as per the driver you have configured in oslo_messaging_notifications section 04:30:44 It is possible to add those info to this spec? 04:32:36 In case of adding info to above spec, the spec needs to re-propose to stein 04:33:08 before amending above specs, I wanted to discuss this point whether we should club both these details into one. i..e API changes + workflow execution 04:35:04 tpatil: no objection to put those 2 changes together. 04:35:07 The above specs addresses changes to the API which emit notifications. Operator can subscribe to such notifications and process it separately outside masakari if need be 04:36:08 tpatil: correct 04:37:21 IMO, workflow execution details should be part of masakari db and for that we need another spec 04:37:54 if you agree, I will submit a new specs for it 04:40:35 tpatil: no problem. In that case separate spec would be better. 04:40:49 samP: Ok 04:41:13 Add functional tests in openstacksdk 04:41:14 tpatil: Please submit a new spec for db changes. 04:41:21 samP: Ok 04:42:29 Should the functional tests reside in masakari repo or openstacksdk repo? 04:42:52 in ether pad, you also have mentioned about adding functional tests 04:44:16 I think functional test would be in openstacksdk repo. However, we need to discuss this with sdk team 04:45:36 tpatil: What I mentioned in etherpad was functional test for maskari, which is kind of same as what you proposed. 04:46:34 plus some scenarios for host, process, vm failures. 04:46:58 I am considering to implement those with eris. 04:47:15 in that case, I think it's better to write functional test in masakari repo itself. what do you think? 04:48:02 We have already started writing functional tests in openstacksdk but it's possible to move it to masakari repo with minimal changes 04:49:53 tpatil: Other projects have there functional tests in own repo, right? 04:51:18 Yes, but it doesn't call RestFul apis using it's own python client libraries 04:52:01 If we decide to write functional tests in masakari repo itself using openstacksdk interface, it possible to test both openstacksdk code and masakari RestFul APIs 04:52:12 On sdk side they have API validation tests..(just looking at them) 04:52:39 tpatil: right. 04:53:54 so we need to decide whether functional tests should be written in openstacksdk or masakari repo 04:54:58 Now, it seems to me that those functional test should stay in masakari repo. 04:57:01 the only catch is if you are modifying openstacksdk code, then the functional tests won't run on the actual changes of sdk code but the previous openstacksdk lib released. Also, you will need to import openstacksdk lib in masakari which doesn't seems to be correct 04:58:22 tpatil: thatz what I am worry about 04:58:49 give me some time to think about this. I will share my thoughts in email 04:59:30 we should make sure that there are no duplicate functional tests in masakari and openstacksdk 04:59:48 We can decide on our next meeting, where to put the functional tests 05:00:07 times up! 05:00:17 ok 05:00:23 lets discuss further on email or IRC 05:00:29 thank you all! 05:00:33 #endmeeting