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