06:03:13 #startmeeting masakari 06:03:13 Meeting started Tue Jul 27 06:03:13 2021 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. 06:03:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 06:03:13 The meeting name has been set to 'masakari' 06:03:19 o/ 06:03:24 o/ 06:03:39 o/ 06:05:09 o/ 06:08:03 ok, let's start 06:08:09 agenda for today 06:08:22 * CI status 06:08:22 * Important pending reviews (important bugfixes, backports) 06:08:22 * Next release planning 06:08:22 ** Cleaned up blueprints https://blueprints.launchpad.net/masakari Watch for priority-assignee-series triple. 06:08:22 ** [shenxinxin, suzhengwei] vm evacuations for host recovery https://review.opendev.org/c/openstack/masakari-specs/+/789432 06:08:24 * Open discussion 06:08:50 #topic CI status 06:09:10 I used it a bit recently and it seems green still 06:09:13 good winds 06:09:20 #topic Important pending reviews (important bugfixes, backports) 06:09:38 https://review.opendev.org/c/openstack/masakari-monitors/+/794162 06:09:45 thanks suzhengwei for re-reviewing 06:09:53 merging this now 06:10:51 one note - please backport only *after* the change merges on master to get the proper commit id 06:10:51 I have chery-pick it to train/victoria/ussuri. 06:11:16 another note - remember we have also stable/wallaby now and train is in EM so there is no urgency to patch it 06:11:43 in other words, let's wait for the patch to merged and then retry the cherrypicks please 06:11:51 ok 06:12:16 ok, another important patch https://review.opendev.org/c/openstack/masakari/+/796732 06:13:39 and two others - ready bandit patches: 06:13:42 https://review.opendev.org/c/openstack/masakari-dashboard/+/791922 06:13:50 https://review.opendev.org/c/openstack/python-masakariclient/+/791924 06:14:16 I am also merging this old trivialfix by XinxinShen https://review.opendev.org/c/openstack/python-masakariclient/+/793595 06:14:41 I think I have gone through all of them now 06:14:59 I will give you a minute or two to go over them 06:15:05 and then we move onto the next release planning 06:18:13 ok, I hope you had the time to get acquainted with them 06:18:18 please review 06:18:29 #topic Next release planning 06:18:35 two subtopics in here 06:18:37 first of all 06:18:46 Cleaned up blueprints https://blueprints.launchpad.net/masakari Watch for priority-assignee-series triple. 06:18:55 I also mailed to the openstack-discuss mailing list about that 06:19:13 http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023811.html 06:19:34 this gives a better overview over what's really happening in the Masakari world 06:19:44 please try to keep it up to date 06:21:01 any questions so far? 06:21:48 Merged openstack/python-masakariclient master: Replace deprecated UPPER_CONSTRAINTS_FILE variable https://review.opendev.org/c/openstack/python-masakariclient/+/793595 06:22:18 ok 06:22:33 the next topic is 06:22:35 [shenxinxin, suzhengwei] vm evacuations for host recovery https://review.opendev.org/c/openstack/masakari-specs/+/789432 06:22:46 I have left a lot of comments there 06:22:53 please ask me any questions to help resolve them 06:23:34 we also have a thread on the openstack-discuss ml on enhancing nova: http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023819.html 06:23:38 Merged openstack/masakari-monitors master: Fix hostmonitor hanging forever after certain exceptions https://review.opendev.org/c/openstack/masakari-monitors/+/794162 06:24:35 I have read the mail. 06:26:11 My opnion, we can still push forward the work without nova-api changed. 06:27:36 probably, we can at least create the data structure as I described 06:28:30 For priority evcuation, it will need firshly calculate and record the instance in masakari DB, and then evacuation. 06:30:01 indeed 06:30:20 so it starts with null migration_uuid anyway 06:30:24 It need to create the data structure between notifications and instancese. 06:31:18 It is ok without migration_uuid. 06:33:17 ok 06:33:27 let me see the refreshed spec then 06:33:41 perhaps we just have most of what we need anyway 06:33:49 Moreover, it doesn't used migration_uuid to check whether evacuation finished. 06:34:14 though migration_uuid would be great for provenance 06:34:29 yeah, we need that info for quick queries 06:34:50 so it is stored in our database anyhow 06:35:02 yes. 06:37:11 ok 06:38:01 so I am just waiting for the refreshed spec 06:38:02 good 06:38:26 as for the consul, I will try to get to it later this week 06:38:36 do we have anything else on release planning? 06:39:14 Priority evcuation and migration back both based on notification event, so we need one more table to record the releation between instance evacautin and notification. 06:40:53 Do we need guide for consul usage? 06:42:35 suzhengwei: don't we have this foreign key already? I guess we would just need an extra column to track if the evacuation was "undone" 06:43:07 suzhengwei: yes, please, let it look better on us than it does with pacemaker; I will help with language 06:45:59 Priority is for both notifications and instances releated to one host notificaion. 06:46:26 What do you means "foreign key"? 06:47:08 Sorry, I can't catch you. 06:47:37 suzhengwei: I meant we already reference the notification for the particular evacuation via the notification uuid (this is the "foreign key", it's a database theory term for that) 06:47:58 * yoctozepto is hard to catch :-) 06:48:51 🤸‍♂️ 06:49:11 Yes, it used notification_uuid as the foreign key. 06:49:51 jopdorp: Hi, what do you think? 06:51:20 I'm not sure 06:51:28 suzhengwei: yes, I know :-) 06:51:34 ok, just waiting for spec update 06:51:36 we should be good 06:51:41 the idea is great 06:51:50 ok, let's move onto open discussion 06:51:54 #topic Open discussion 06:52:12 all questions allowed 06:59:16 ok, I'm wrapping this up then, thanks 06:59:18 #endmeeting