07:03:00 #startmeeting masakari 07:03:01 Meeting started Tue Dec 8 07:03:00 2020 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:03:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:03:04 The meeting name has been set to 'masakari' 07:03:09 #topic Roll-call 07:03:12 \o/ 07:04:40 ping 07:05:02 O/ 07:05:12 \o/ 07:05:34 #topic Agenda 07:05:43 * Roll-call 07:05:43 * Agenda 07:05:43 * Announcements 07:05:43 * Review action items from the last meeting 07:05:43 * CI status 07:05:44 * Backports pending reviews 07:05:44 * Release planning https://etherpad.opendev.org/p/masakari-wallaby-vptg 07:05:44 * Open discussion 07:06:04 #topic Announcements 07:06:07 I have none 07:06:11 do you have any? 07:06:15 No 07:06:40 none 07:08:08 #topic Review action items from the last meeting 07:08:17 and there were... 07:08:19 none! 07:08:30 #topic CI status 07:08:41 checking... 07:10:20 yoctozepto: i see you have changes to introduce periodic jobs 07:10:30 looks healthy but we don't have periodic jobs approved 07:10:32 jopdorp: yes 07:10:46 https://review.opendev.org/q/topic:%22ci-periodic-jobs%22+(status:open%20OR%20status:merged) 07:11:04 please approve them (I can do it myself but it's no fun) 07:12:05 Yes 07:12:19 How ofen the periodic job runs? 07:12:49 suzhengwei: daily 07:16:35 If one patch is hold by gerit too long, would there be many times ci jobs if no changes? 07:18:39 suzhengwei: periodics run against current state of the branch they are active one; they do not act upon proposed changes 07:19:09 all right, moving on 07:19:13 (please approve) 07:19:23 #topic Backports pending reviews 07:19:29 ok 07:19:40 #link https://review.opendev.org/q/(project:openstack/masakari+OR+project:openstack/masakari-monitors+OR+project:openstack/python-masakariclient+OR+project:openstack/masakari-dashboard)+status:open+-branch:master 07:19:42 No changes! 07:20:04 #topic Release planning https://etherpad.opendev.org/p/masakari-wallaby-vptg 07:20:15 what are you progresses on the above? 07:20:21 https://review.opendev.org/c/openstack/masakari-monitors/+/761704 07:20:24 I have seen nautik's mail to the mailing list 07:20:50 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019252.html 07:20:55 no response so far though 07:21:01 suzhengwei: looking 07:21:35 suzhengwei: where is the blueprint/spec? 07:22:03 https://review.opendev.org/c/openstack/masakari-specs/+/761499 07:23:41 yoctozepto: I noticed one email from nautik. [ironic][masakari] Should masakari rely on Ironic to power fence failing hosts? 07:24:36 suzhengwei: yes, I wrote about it exactly 07:24:45 the link is above 07:25:37 suzhengwei: ok, I tabbed myself the blueprint+spec+patch trio 07:25:50 I will act upon it this week, will try today but no promises 07:26:05 thanks 07:26:18 I see jopdorp has already +2 so I assume it will go smoothly :-) 07:26:35 all right, anything more on the wallaby progress? 07:26:40 jopdorp's docs perhaps? :-) 07:27:12 I did some change based on your comments 07:27:52 In this 07:27:55 https://review.opendev.org/c/openstack/masakari/+/762490/7#message-89a89607e68c1e3197ffbf7064de7eabbc1d15a9 07:28:53 jopdorp: ack, tabbed as well 07:29:12 There is still this open blueprint https://review.opendev.org/c/openstack/masakari-specs/+/762517 07:29:56 If it gets approved I will write another blueprint about migrating instances back to the recovered hosts 07:30:43 There is this one that su approved 07:30:46 https://review.opendev.org/c/openstack/masakari/+/458793 07:32:18 Enable/Disable evacuation segment wise, I think it is ready for implent. 07:33:01 suzhengwei: yes, we agreed the naming is fine so it is good to proceed with reviews 07:33:29 jopdorp: yeah, this is spec; it should be linked to a blueprint 07:33:36 oh, I'm having a bad connection to gerrit. Can't open the above link. 07:34:00 suzhengwei: hmmmm, let us know if this persists 07:34:43 jopdorp: regarding v1/ fixing, I have yet to confirm whether there should be a redirect there or something else, will check 07:35:09 just today. 07:35:16 I will make a blueprint 07:36:54 jopdorp: thanks 07:36:59 #topic Open discussion 07:37:08 aand now for anything else 07:39:05 Hello guys, sorry for being late 07:39:24 nautik: better late than never ;-) 07:39:52 don't hesitate if any question about the blueprint I wrote 07:40:11 nautik: Long time to see 07:40:28 yes indeed, hope you are well! 07:41:20 I discovered more about the nova system scopes, which is a way (since ussuri) to differenciate the admin of a project from a "super-admin", having system rights on the whole deployment 07:41:59 yeah, that makes sense; any docs on that? 07:42:37 https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team 07:42:50 https://etherpad.opendev.org/p/policy-popup-wallaby-ptg 07:43:04 the links in "reference" are useful 07:44:32 At some point it could be interesting to implement the "new defaults" in masakari's policies (relying on this system-scope permissions) 07:44:49 But so far it has been done nearly only in nova so probably no rush 07:45:24 we tried to implement it in a deployment, but it is really a pain to use as cinder or neutron have not yet implemented this 07:45:41 nautik: it's as much of a rush as we think is right ;-) 07:45:47 nautik: yeah, I can imagine 07:46:06 any idea how much "not started" this really is for them? 07:46:32 Anyway, just wanted to share the information as this is a step in the good direction IMO :) 07:46:52 agreed. 07:47:41 Well actually it is really not a huge work I think, as oslo_policy implements this. So you can simply set a custom policy using `system-scope:all` rule and it will be correctly set 07:47:42 agreed here as well; pretty much this should have been like this from the very beginning :-) 07:47:50 we've tried it in glance for example 07:48:07 well, I guess this is tricky in the little bits 07:48:26 the work it to set the alternative "new defaults" instead of requiring the operator to customize its policies to use it 07:48:52 haven't looked into this much yet 07:49:24 and for cinder they actually have more work to do before that, which is relying on the token to determine the role of a user (I think) 07:49:40 instead of the `project_id` that is set in the cinder endpoint url 07:50:13 because when using system-scope, you don't have a project_id anymore, so currently you can't talk to cinder ^^ 07:50:43 it was the same in masakari FYI, but I tried just removing the `tenant_id` from the endpoint URL and it works well 07:50:49 yeah, I've seen that 07:50:58 slight ommission :-) 07:51:07 So on our side I think it is just changing a default or documentation somewhere 07:51:15 for this endpoint thing 07:51:26 could be, need to read up on it 07:51:36 I advise others read up too if they have time 07:53:47 Ok 07:54:08 Anyway, in the same topic, don't hesitate to check out this blueprint and its implementation: https://blueprints.launchpad.net/masakari/+spec/support-nova-system-scope-policies 07:54:08 The idea is not to implement system-scope in masakari (in the masakari api), but rather for now "be able to talk to a nova that has system-scoped permissions enforced" 07:54:52 I would like to read up on it. 07:58:57 nautik: ack, makes sense 07:59:31 nautik: I'll read up on it and let you know whether blueprint is sufficient or we need a spec 07:59:40 I believe bp is sufficient 07:59:45 all right 07:59:48 sure, tell me 07:59:52 thank you all for joining and being active 08:00:07 jopdorp, suzhengwei, nautik 08:00:14 bye 08:00:15 #endmeeting