14:00:31 <rosmaita> #startmeeting cinder
14:00:31 <openstack> Meeting started Wed May 12 14:00:31 2021 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:34 <openstack> The meeting name has been set to 'cinder'
14:00:38 <rosmaita> #topic roll call
14:00:42 <whoami-rajat> Hi
14:00:44 <jungleboyj> o/
14:00:51 <enriquetaso> hi
14:00:52 <walshh_> hi
14:01:14 <e0ne> hi
14:02:04 <fabiooliveira> hi
14:02:09 <felipe_rodrigues> hi
14:02:23 <geguileo> hi! o/
14:02:52 <tosky> hi
14:03:08 <eharney> hi
14:03:47 <rosmaita> good turnout, let's get started
14:03:58 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-meetings
14:04:12 <rosmaita> #topic announcements - upcoming deadlines
14:04:22 <rosmaita> here's my weekly reminder of what's coming up
14:04:31 <rosmaita> this week: R-21
14:04:39 <rosmaita> xena milestone 1: R-19 (week of 24 May)
14:04:50 <rosmaita> yep, 2 weeks away
14:04:59 <rosmaita> cinder spec freeze: R-15 (week of 21 June)
14:05:10 <rosmaita> cinderlib wallaby release: R-14 (week of 28 July, though we can release earlier)
14:05:33 <rosmaita> #topic announcements - train goes to EM
14:05:47 <rosmaita> train goes to Extended Maintenance mode soon ... like this week
14:06:07 <rosmaita> thanks to whoami-rajat for organizing getting the final train releases out
14:06:17 <rosmaita> release patch: https://review.opendev.org/c/openstack/releases/+/790473
14:06:28 <rosmaita> EM tag patch: https://review.opendev.org/c/openstack/releases/+/790737
14:06:35 <whoami-rajat> thanks everyone for the stable branch reviews!
14:06:55 <rosmaita> #topic announcements - xena midcycles
14:07:10 <rosmaita> save the dates for the R-18 and R-9 midcycles
14:07:20 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022306.html
14:07:31 <rosmaita> and, start thinking about what should be discussed
14:07:40 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-mid-cycles
14:08:05 <rosmaita> #topic announcements - cycle priorities
14:08:16 <rosmaita> we had kind of a light turnout last week
14:08:24 <rosmaita> so I just want to mention this again
14:08:32 <rosmaita> #link https://wiki.openstack.org/wiki/CinderXenaPTGSummary#Xena_Cycle_Priorities
14:08:47 <rosmaita> key thing to pay attention to are the priorities throughout the cycle
14:09:19 <rosmaita> please use the topics stated there on any patches, it will help us prioritize reviews
14:09:42 <rosmaita> #topic announcements - SQLAlchemy 1.4 in upper-constraints
14:09:54 <rosmaita> rajat mentioned this a few weeks ago
14:10:20 <rosmaita> there are some non-backward-compat changes in 1.4 to get people ready to move to 2.0
14:10:33 <rosmaita> thanks to geguileo for fixing some bugs yesterday
14:10:41 <rosmaita> so it looks like cinder is ready
14:10:59 <whoami-rajat> great!
14:11:10 <rosmaita> i just want to mention this because not all projects that use sqlalchemy run cross-project tests on the u-c change patches
14:11:20 <rosmaita> #link https://review.opendev.org/c/openstack/requirements/+/788339/
14:11:53 <rosmaita> so if you are working on such a project, you might want to run your tests with sqlalchemy 1.4.13 to make sure nothing breaks
14:12:24 <rosmaita> there were some regressions between 1.4.0 and 1.4.12 that were fixed
14:12:42 <rosmaita> so don't test against older 1.4.x versions
14:13:04 <rosmaita> ok, that's all the announcements from me
14:13:08 <rosmaita> anyone else?
14:14:17 <rosmaita> looks like no
14:14:27 <rosmaita> #topic interop guidelines review part 2
14:14:57 <rosmaita> we were asked at the PTG to review the current guidelines and see if anything should be added
14:15:05 <rosmaita> as a reminder, what we are looking for is
14:15:22 <rosmaita> Block Storage API calls that should be supported in all clouds
14:15:44 <rosmaita> right now, there are only 3.0 calls in the required section
14:16:10 <rosmaita> the idea is that we want to promote workload portability
14:16:39 <rosmaita> so that users can move their workloads to any openstack cloud and expect them to work
14:16:44 <rosmaita> (within reason)
14:17:10 <rosmaita> at this point, we would introduce any new calls as "advisory"
14:17:38 <rosmaita> and then after a while, the interop group will make them required (or, i guess, reject them)
14:18:05 <rosmaita> last week I mentioned 3 capabilities as advisory candidates
14:18:09 <rosmaita> 1 - user messages
14:18:19 <rosmaita> 2 - new transfer API
14:18:25 <rosmaita> 3 - attachments API
14:19:00 <rosmaita> what we need for each is that (1) there exist tempest tests for the capability, and (2) we propose a patch to the interop group making the tests advisory
14:19:27 <rosmaita> i like the user messages from the standpoint of encouraging people to pay attention to them
14:19:40 <rosmaita> but i'm not so sure about their relevance for workload portablity
14:19:53 <jungleboyj> ++
14:19:58 <rosmaita> though they might contain sufficient info for you to recover from a failure scenario?
14:20:18 <rosmaita> anyway, we can think about those because there's another problem
14:20:31 <rosmaita> the existing tempest tests are admin tests
14:21:11 <rosmaita> i think they'd have to be moved to non-admin before they'd be accepted
14:21:43 <rosmaita> i think they're in the admin section of tempest so that a failure scenario can be caused, something like that
14:22:08 <rosmaita> i should be more specific.  there are 2 tests
14:22:22 <rosmaita> idempotent_id('50f29e6e-f363-42e1-8ad1-f67ae7fd4d5a') - tempest.api.volume.admin.test_user_messages.UserMessagesTest.test_list_show_messages
14:22:36 <rosmaita> idempotent_id('c6eb6901-cdcc-490f-b735-4fe251842aed') - tempest.api.volume.admin.test_user_messages.UserMessagesTest.test_delete_message
14:23:19 <rosmaita> does anyone have an opinion on this, or is everyone reading their email?
14:23:53 <jungleboyj> :-)
14:24:01 <eharney> the user message tests shouldn't be admin-oriented
14:24:17 <jungleboyj> Right.  Otherwise they aren't user messages.  :-)
14:24:26 <rosmaita> yeah, i think they're in there because you need an admin cred to cause the failure scenario to prompt a user message
14:25:17 <rosmaita> in any case, we can talk about this later in the cycle, maybe at R-9 midcycle
14:25:42 <rosmaita> need to decide: (a) should they be included, and (b) how to restructure the tempest tests
14:25:56 <rosmaita> ok, #2 - new transfers api
14:26:08 <rosmaita> this is microversion 3.55 (and 3.57)
14:26:53 <rosmaita> so all it does is change the REST resource from 'os-volume-transfer' to 'volume-transfers'
14:27:27 <rosmaita> this is before my time, it think the idea is the os- one was needed for 3.0 to be compatible with 2.0
14:27:49 <rosmaita> and i guess eventually we want to stop supporting os-volume-transfer in the URL?
14:27:53 * jungleboyj can't remember why that was.
14:27:55 <eharney> just for clarity... does a cloud meet interop guidelines if it chooses to disable volume transfer via policy configuration?
14:28:29 <rosmaita> that's a good question
14:28:32 <eharney> yes, the os-volume-methods are generally named that way because they were extensions, and it is now "volume-transfers" because it's a proper part of the API
14:28:53 <jungleboyj> eharney:  Oh, that is right.  Thank you.
14:29:27 <rosmaita> to answer Eric's question, as long as it's exposed for some users, i believe it's ok
14:29:47 <rosmaita> of course, on that interpretation, a cloud could expose it only to the test user and nobody else
14:30:08 <rosmaita> not sure there's anything we can do about that
14:30:43 <rosmaita> i guess the important question is whether we think volume-transfer should be a required capability
14:31:29 <eharney> i don't know, i would assume that since some clouds surely don't have any users that would need it, some admins would prefer to turn it off
14:31:55 <rosmaita> i looked into this a bit last week ... there are tempest tests for the "old" api, so i put up a patch to include tests for the "new" api
14:32:08 <rosmaita> #link https://review.opendev.org/c/openstack/tempest/+/790201
14:32:09 <eharney> it only makes sense on clouds where users would have a reason to share volumes between each other in some way
14:32:48 <rosmaita> well, i'm thinking of a 3rd party thing, where you could set up volumes with DBs and stuff as a service, and transfer the prepared volume to your customers
14:33:12 <jungleboyj> Maybe I am missing something here.
14:33:49 <jungleboyj> The interop test it to validate the things that should work in all clouds.  Not testing what the administrator has decided to enable or not.
14:34:08 <eharney> it's an API-only feature
14:34:10 <jungleboyj> What am I missing?
14:34:26 <eharney> the only way for it to not work is if the admin doesn't allow it
14:34:56 <eharney> i think we just need more clarity (or i do) on what it means to test for interop of a feature like this
14:35:33 <rosmaita> yeah, i am a bit unclear on this too
14:35:36 <jungleboyj> Yeah, me too.  So, if we say that it is something that should work and an admin has disabled it by policy then that cloud would fail the interop tests?
14:35:51 <eharney> that's the part i'm not clear on
14:35:56 <rosmaita> well, it depends on how much it's disabled, i think
14:36:00 <tosky> shouldn't that apply to all interop tests?
14:36:02 <eharney> the flip side of that is -- why test it at all
14:36:23 <rosmaita> right, because if you have the software, you have all the stuff you need to run the full API
14:36:26 <eharney> you are really just testing if they are running a new enough version of cinder if you're ignoring the part where admins don't allow it via policy
14:37:21 <rosmaita> ok, maybe we need to invite the interop-WG to the R-9 midcycle so we can discuss this in person
14:37:32 <rosmaita> my hidden agenda with the transfers api is:
14:37:55 <rosmaita> if we are ever going to remove the "old" api, it would be good to know that people are using the "new" one
14:38:09 <rosmaita> because that would be the required capability
14:38:25 <jungleboyj> ++ to further discussion.
14:39:02 <rosmaita> ok, that makes sense ... real quickly, though
14:39:11 <rosmaita> item #3 ... the attachments API
14:39:21 <rosmaita> there aren't any tempest tests
14:39:36 <whoami-rajat> isn't it tested with nova tests?
14:39:39 <rosmaita> there's a patch from February 2018 to add an "attachments client"
14:39:54 <rosmaita> but it's still sitting there
14:40:12 <rosmaita> #link https://review.opendev.org/c/openstack/tempest/+/487884
14:40:20 <eharney> it would be tested via nova tests, but maybe there aren't tests that validate anything about the API itself
14:40:31 <rosmaita> right
14:40:34 <eharney> i.e. from tempest manipulating attachments directly instead of just by attaching volumes to nova
14:41:01 <whoami-rajat> ok
14:41:13 <rosmaita> yes, it's tested indirectly, but might be worth testing directly
14:41:18 <rosmaita> just wanted to mention that
14:41:43 <whoami-rajat> yeah nova might not be testing attachment_get at all (not sure though)
14:42:03 <rosmaita> ok, so the conclusion now is:
14:42:15 <rosmaita> 1 - we don't have anything to add to next.json at this time
14:42:32 <rosmaita> 2 - we want to meet with the interop-WG to get a better handle on the whole thing
14:42:51 <rosmaita> that's all
14:43:15 <rosmaita> #topic Minor version bump for config option added in drivers
14:43:18 <jungleboyj> ++
14:43:29 <rosmaita> this is prompted by the train release patch
14:43:42 <rosmaita> #link https://review.opendev.org/c/openstack/releases/+/790473
14:44:12 <whoami-rajat> with reference to config option added in this patch
14:44:14 <whoami-rajat> #link https://review.opendev.org/c/openstack/cinder/+/783866
14:44:14 <rosmaita> we proposed cinder 15.5.2 or something
14:44:31 <rosmaita> the release team asked us to make it 15.6.0
14:45:25 <eharney> minor version bumps are generally not a big deal, so, seems fine
14:45:33 <jungleboyj> eharney:  ++
14:45:44 <rosmaita> the guidelines are here:
14:45:46 <jungleboyj> I don't have a strong opinion.  If that is what they want, then we can do that.
14:45:47 <rosmaita> #link https://releases.openstack.org/reference/reviewer_guide.html#release-x-y-z-will-include
14:45:59 <whoami-rajat> my main concern here is that we haven't done similar things before and if do we want to standardize it for the next releases, just to be consistent
14:46:38 <rosmaita> i think it's going to be difficult to maintain consistency on this
14:46:58 <rosmaita> we've also had the situation where we were asked to downgrade a minor bump to a patch bump
14:47:13 <rosmaita> a lot of times, it's a judgement call
14:48:01 <eharney> i suspect that most people are deciding to upgrade based on "this is still stable/train" and not minor vs patch version numbers, and if the minor bump tells them to scan the release notes, maybe that's good
14:48:28 <jungleboyj> eharney:  ++
14:49:01 <whoami-rajat> but we can easily monitor if a config option is added or not, it can be similar to when we bump dependencies
14:50:10 <rosmaita> we also have a weird situation because the release team wants us to do an early release of libraries in a cycle, you have wallaby brick 5.0, say, and then first early xena is 5.1, so all the rest of wallaby bricks can only be patch increments
14:50:34 <rosmaita> i think what it comes down to is basically what eric said
14:50:51 <rosmaita> you have to look at the series and not so much the version number
14:51:24 <whoami-rajat> in that case we do patch bumps for even dependency updates
14:51:32 <rosmaita> right
14:51:53 <whoami-rajat> i just wanted to be consistent with the later releases and not specifically regarding stable/train but if consistency is not a major concern here then I'm good
14:52:21 <rosmaita> it's a good thing to bring up
14:52:38 <rosmaita> i think we should try to be consistent, but not get too worried about it
14:53:12 <whoami-rajat> +1
14:53:28 <tosky> (not for the last release of train which should go out yesterday - and I'm the one who usually likes to nags for consistency)
14:53:54 <rosmaita> :)
14:54:15 <rosmaita> #topic open discussion
14:56:07 <rosmaita> i think Eric asked last week or at the festival of mypy about what happened to the "Toggle CI" button in gerrit
14:56:22 <rosmaita> i put an item on the opendev meeting agenda to ask them about that
14:56:24 <eharney> well, i was definitely noting that it was missed :)
14:56:31 <rosmaita> i just need to remember to go to the meeting
14:57:17 <rosmaita> i thought it was on the feature gap list for the gerrit web UI update, but it's not
14:58:00 <rosmaita> anyway, it would be nice to get that back
14:58:40 <whoami-rajat> ++
14:58:52 <whoami-rajat> really hard to find reviewer comments in between those CI comments
14:59:13 <rosmaita> i agree
14:59:32 <enriquetaso> ++
14:59:37 <rosmaita> the comment thread tab is nice, but it only shows inline comments
14:59:53 <rosmaita> ok, we need to make way for horizon
15:00:04 <rosmaita> have a good week everyone, and thanks for attending
15:00:09 <rosmaita> #endmeeting