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