15:00:46 <gouthamr> #startmeeting manila
15:00:46 <openstack> Meeting started Thu Feb  4 15:00:46 2021 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:50 <openstack> The meeting name has been set to 'manila'
15:00:52 <dviroel> o/
15:00:53 <carloss> o/
15:00:57 <maaritamm> o/
15:00:58 <carthaca> hi
15:01:01 <andrebeltrami> hi
15:01:04 <vhari> o/
15:01:12 <gouthamr> courtesy ping: ganso vkmc lseki carloss tbarron felipe_rodrigues esantos
15:01:13 <felipe_rodrigues> o/
15:01:20 <tbarron> yo!
15:01:26 <gouthamr> beat you by a second, felipe_rodrigues
15:01:27 <tbarron> io
15:01:43 <chuan137> hi
15:01:56 <gouthamr> hello everyone! thanks for joining in!
15:02:14 <ecsantos> o/
15:02:25 <gouthamr> hey there chuan137! don't believe we have met, but thanks for the os-profiler reviews!
15:02:42 <gouthamr> here's the agenda for today: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:02:51 <chuan137> thanks, am colleague of carthaca
15:02:52 <gouthamr> lets get started
15:03:02 <gouthamr> chuan137: nice, welcome!
15:03:07 <gouthamr> #topic Announcements
15:03:29 <gouthamr> as you're aware, today's the new driver submission deadline
15:04:17 <vkmc> o/
15:04:27 <disap> o/
15:04:40 <gouthamr> we have one driver that's met the deadline a few weeks ago, and is going through reviews
15:04:46 <gouthamr> #link https://review.opendev.org/768590
15:05:06 <gouthamr> thanks for reviewing dviroel carloss
15:05:32 <dviroel> yep, just added a comment about its CI
15:05:38 <gouthamr> looks good there, we may need to push the other two that were targeted for this release to Xena
15:05:55 <dviroel> It is reporting Succeeded, but its failing in some tests
15:06:13 <dviroel> nothing that can be fixed in the following weeks, i think
15:06:22 <dviroel> s/can/can't
15:06:36 <gouthamr> nice, that's a relief
15:06:42 <gouthamr> good catch, dviroel
15:07:04 <gouthamr> next week is our feature proposal freeze
15:07:15 <gouthamr> #link: https://releases.openstack.org/wallaby/schedule.html (Wallaby release schedule)
15:07:30 <gouthamr> per the schedule: "All new Manila features must be proposed and substantially completed, with unit, functional and integration tests by the end of the week."
15:08:13 <gouthamr> i know a number of things are in flight, so as we've said here before, reviewer attention at this point would be our biggest strength :)
15:08:47 <dviroel> we still have a feature to propose
15:09:23 <dviroel> isn't a 14k lines change this time
15:09:26 <dviroel> :)
15:09:33 <carloss> hehe
15:09:34 <gouthamr> that's always good to hear
15:10:20 <gouthamr> that's all for announcements today, a slew of end-of-release activity should begin soon
15:11:07 <gouthamr> oh wait, i had another - if you're relying on upstream releases for stable branches, we have a few that went out last week:
15:11:19 <gouthamr> #link http://lists.openstack.org/pipermail/release-announce/2021-February/010565.html (manila 9.1.5 (train))
15:11:35 <gouthamr> #link http://lists.openstack.org/pipermail/release-announce/2021-February/010567.html (manila 10.0.2 (ussuri))
15:11:46 <gouthamr> #link http://lists.openstack.org/pipermail/release-announce/2021-February/010566.html (manila 11.0.1 (victoria))
15:13:00 <dviroel> 👏
15:13:28 <gouthamr> i think we should expect a refresh with more bugfixes that are in the pipeline around m-3 (4 weeks from now)
15:13:42 <gouthamr> any other announcements for today?
15:14:18 <gouthamr> #topic OpenStackSDK spec review
15:15:17 <gouthamr> this is a short one
15:15:51 <gouthamr> as you're aware, we embarked on adding manila API support in openstacksdk earlier in the cycle
15:16:20 <gouthamr> driven by three senior year students at Boston University
15:16:58 <gouthamr> they've submitted a release-independent specification here:
15:17:05 <gouthamr> #link https://review.opendev.org/c/openstack/manila-specs/+/768516 (Add Manila Support on OpenStack SDK)
15:17:51 <gouthamr> the spec includes a link to the task tracker, and highlights the APIs intended to be addressed, by priority determined by them
15:18:12 <gouthamr> i'd like for more eyes on this
15:19:12 <gouthamr> we're still targeting to get a few things merged in wallaby, albeit the deadline's fast approaching
15:20:14 <gouthamr> #link https://review.opendev.org/q/topic:%22openstacksdk-manila-support%22
15:20:36 <gouthamr> ^ if you're interested in helping with reviews, that's the gerrit topic for patches :)
15:21:42 <gouthamr> that's what i had on the topic
15:22:20 <gouthamr> you can reach out to me/vkmc/maaritamm with questions at the moment, the students have no irc bouncers yet, but we meet with them regularly
15:23:29 <gouthamr> in related news, they've been working with maaritamm to propose bugfixes in manilaclient/OSC and learning a lot
15:24:06 <tbarron> maaritamm++
15:24:39 <gouthamr> cool, that's all about $topic - thank you for reviews! :)
15:24:45 <gouthamr> #topic Dropping project_id from API URLs
15:24:49 <vkmc> maaritamm++
15:26:49 <gouthamr> lbragstad was working with testing the secure rbac work in cinder, and he noticed that the service catalog for system users doesn't list the cinder endpoint
15:27:03 <gouthamr> he started a discussion on the mailing list
15:27:10 <gouthamr> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020103.html ([dev][cinder][keystone] Properly consuming system-scope in cinder)
15:27:49 <gouthamr> interestingly, we have the same issue with manila
15:28:31 <gouthamr> and we've discussed the question of removing the project_id in the API URLs in the past
15:29:44 <gouthamr> there's code in the manila api that relies on this project_id - many API routes need it to be present
15:29:49 <gouthamr> although, we never really use it
15:30:42 <gouthamr> we do validate it however
15:31:03 <gouthamr> when a project_id is present, we want to be sure the request is coming from who they say they are
15:31:07 <gouthamr> #link https://opendev.org/openstack/manila/src/commit/39efc2bde81c2a0c747a491d3a778b822ca263b8/manila/api/openstack/wsgi.py#L816-L821
15:31:57 <gouthamr> but the authorization components ignore the project_id in the URL everywhere else in the API code
15:32:32 <gouthamr> and they rely on the request context object that's constructed with the help of keystone and the token used by the caller
15:33:30 <gouthamr> and in case you're running manila in a standalone mode, we set the project_id to "admin" so we can pass the validation above to conform to the URL structure
15:34:45 <gouthamr> for noauth, it doesn't really have to be "admin" - in our testing, we use "fake" and "openstack" - so really any string
15:35:21 <gouthamr> the problem with having the project_id in the URL is that system users that interact with manila will not have one
15:36:36 <gouthamr> system users are meant to operate outside of projects and domains
15:36:59 <tbarron> so we are insisting on project id in the url even though nowadays it is the keystone request context that is used,
15:37:07 <gouthamr> +1
15:37:26 <tbarron> for example, to restrict regular project members acess to resources to the appropriate scope
15:37:54 <tbarron> just checking my understading.
15:38:21 <gouthamr> yes - we have the scope and project information from the request context and we rely solely on that
15:39:06 <gouthamr> to ensure RBAC on resources (APIs and database objects)
15:40:29 <gouthamr> so, we could drop this project_id requirement from the URLs and not lose any important validation
15:40:53 <tbarron> +1
15:41:18 <gouthamr> other projects that required project_id in the API URLs have removed it
15:41:47 <gouthamr> notably, nova
15:41:56 <gouthamr> #link https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id16
15:42:50 <gouthamr> #link https://opendev.org/openstack/nova/commit/1f16a763e793098b26f37110db35828024e44025
15:43:20 <gouthamr> the idea is to advertise API routes with and without project_id
15:44:18 <gouthamr> since we cannot just drop the requirement altogether, this could break clients
15:44:39 <gouthamr> and for making such major breaking changes, we'd need a new major version of the API
15:45:31 <gouthamr> the reason i don't think that's warranted is because we can easily provide this compatibility, following nova's path and using our microversions framework
15:45:54 <gouthamr> we signal to end users by increasing the API microversion
15:46:31 <gouthamr> and let them know that if their cloud supports that microversion, it would mean that they don't need to use their project_id in the URLs
15:47:06 <gouthamr> if they choose to, however, it wouldn't be a big deal, since it'll still be accepted by the service
15:47:15 <gouthamr> and everything works as it is today
15:47:39 <gouthamr> including the validation that your the project_id derived from the caller's token matches the project_id that they provide in the URL
15:48:20 <gouthamr> any thoughts/objections to this?
15:49:06 <tbarron> well you already know I like this approach, but for the record.
15:49:25 <dviroel> gouthamr: thanks for the clarification and for working on this
15:49:52 <gouthamr> #link https://review.opendev.org/q/topic:%22bp%252Fremove-project-id-from-urls%22
15:50:15 <gouthamr> ^ these are the changes
15:50:36 <tbarron> alternative approaches like hacking the client to fake a project in the url when it's not supplied by the user would just be a stop gap and
15:50:51 <tbarron> leave holes for anyone not usint the right client
15:51:02 <tbarron> using
15:51:25 <gouthamr> +1 - that's true, and even with that case, keystone would not be able to give us the project_id with the token
15:51:48 <gouthamr> so we'll have to modify the API code to allow system scope users to bypass the project_id validation
15:53:03 <gouthamr> since we're not breaking anyone and dropping the project_id is desirable in the long run
15:53:25 <gouthamr> i advocate for doing that instead
15:54:14 <gouthamr> it'd be a pita if _every_ client/sdk/application had to fake a project ID
15:54:49 <gouthamr> that sort of change breaks existing clients if they want to interact as system scope users
15:55:40 <gouthamr> sorry we've spent a long time on this discussion
15:56:00 <gouthamr> we can't get to the rest of our agenda today - which are regular items
15:56:50 <gouthamr> with the few mins left, any further thoughts on $topic?
15:57:40 <tbarron> Thanks for the expanation, gouthamr, should make review a lot easier.
15:58:12 <gouthamr> you're welcome - i'm happy to answer questions, thank you for reviewing!
15:58:18 <gouthamr> #topic Open Discussion
15:58:40 <gouthamr> last couple of minutes to kick start anything on record and take it to #openstack-manila :)
15:59:04 <gouthamr> sorry about the loss of bug triage time, vhari
15:59:30 <vhari> gouthamr, how about this new bug #link https://bugs.launchpad.net/manila/+bug/1914453
15:59:31 <openstack> Launchpad bug 1914453 in OpenStack Shared File Systems Service (Manila) "CephFS Native driver gets blacklisted during startup with Ceph Octopus " [Undecided,New]
16:00:06 <gouthamr> ouch, we are testing with octopus
16:00:32 <vhari> np, but maybe a good topic for openstack-manila :)
16:00:41 <gouthamr> ack, thank you vhari
16:00:49 <vhari> gouthamr, yw
16:00:51 <gouthamr> we'll continue the triage in #openstack-manila
16:01:02 <gouthamr> thanks everyone for joining, see you here next week
16:01:08 <gouthamr> #endmeeting