15:00:13 <carloss> #startmeeting manila
15:00:13 <opendevmeet> Meeting started Thu Mar  9 15:00:13 2023 UTC and is due to finish in 60 minutes.  The chair is carloss. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:13 <opendevmeet> The meeting name has been set to 'manila'
15:00:28 <haixin> o/
15:00:32 <gouthamr> o/
15:00:34 <MatheusAndrade[m]> o/
15:00:42 <vhari> o/
15:01:02 <HelenaDantas[m]> o/
15:01:05 <felipe_rodrigues> hi
15:01:15 <lucasmoliveira059> \o
15:01:33 <caiquemello[m]> hi
15:03:07 <freyes> hi
15:03:59 <thiagoalvoravel> o/
15:04:34 <carloss> o/ hello everyone
15:04:50 <carloss> courtesy ping: dviroel
15:05:24 <carloss> a reminder to you: if you would like to receive a courtesy ping in the beginning of this meeting, please edit this page: https://wiki.openstack.org/wiki/Manila/Meetings
15:05:32 <carloss> and add your name to the courtesy ping list
15:05:52 <carloss> that said, let's start with today's meeting agenda:
15:05:54 <carloss> #link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:06:05 <carloss> #topic Announcements
15:06:11 <carloss> Schedule and Deadlines:
15:06:15 <carloss> #link https://releases.openstack.org/antelope/schedule.html
15:06:44 <luizsantos[m]> o/
15:06:53 <carloss> RC1 was last week and we are a couple of weeks away from Antelope release
15:07:50 <carloss> and PTG is also right around the corner
15:08:07 <carloss> next ptg we will have will be virtual
15:08:08 <carloss> #link https://openinfra.dev/ptg/
15:08:16 <carloss> dates are: March 27-31, 2023
15:08:59 <carloss> I have already booked the slots for Manila, you can see the slots in the PTG site
15:09:01 <carloss> #link #link https://ptg.opendev.org/ptg.html
15:09:33 <carloss> you will notice a reduction of hours (for this year, we will have 3 hours less than the usual)
15:09:45 <carloss> please take a look at the slots and let me know if you have suggestions
15:10:06 <carloss> the PTG planning etherpad is this:
15:10:08 <carloss> #link #link https://etherpad.opendev.org/p/manila-bobcat-ptg-planning
15:10:19 <carloss> please add the topics you would like to discuss with the community during PTG
15:10:31 <carloss> we will talk scheduling in one or two weeks
15:10:48 <carloss> that's all I had for $topic
15:10:54 <carloss> do you have an announcement to share with us today>
15:11:02 <carloss> ?
15:13:26 <carloss> okay, next topic then
15:13:38 <carloss> #topic Manila Client API version behind Server API (felipe_rodrigues)
15:13:47 <carloss> felipe_rodrigues: floor is yours
15:13:55 <felipe_rodrigues> thanks carloss
15:14:43 <felipe_rodrigues> I added this topic because the server is upper than the client
15:15:22 <felipe_rodrigues> It means that the operator cannot run with the features since there is no Client
15:15:46 <felipe_rodrigues> The patch that would make client updated
15:15:48 <felipe_rodrigues> #link https://review.opendev.org/c/openstack/python-manilaclient/+/869709
15:16:15 <felipe_rodrigues> I fixed the comments and passed on community CI
15:16:34 <felipe_rodrigues> This is very important for NetApp customer
15:16:59 <felipe_rodrigues> Canonical team is here to explain the use case and the importance
15:17:23 <felipe_rodrigues> Vinod_____: do you want to add something ?
15:17:59 <Vinod_____> only that our client won't be able to move this in production without the client
15:18:34 <Vinod_____> and we plan to move this to production in Q2 timeframe
15:18:34 <felipe_rodrigues> Nice
15:19:06 <felipe_rodrigues> Can we work on it to have It merge asap ?
15:20:04 <wolsen[m]> fwiw, aiui the server side feature isn't really usable without the client side implementation correct?
15:20:56 <Vinod_____> yes, that this correct
15:22:39 <gouthamr> why unusable? If we merge this patch now, and can canonical take it into its antelope release content?
15:23:51 <gouthamr> the patch didn’t make it in time for the client release/code freeze for antelope which happened alongside the feature freeze for the service repo
15:24:11 <wolsen[m]> gouthamr: unusable in the sense that there's not a client interface for general users to use
15:24:35 <wolsen[m]> one could use raw interactions with the api using http requests
15:24:49 <wolsen[m]> but it seems like the client would be desired to show completeness of the feature
15:25:35 * dviroel o/
15:25:43 <wolsen[m]> gouthamr: would the patch be eligible for backporting to the antelope client release?
15:26:14 <wolsen[m]> in your opinion?
15:26:47 <gouthamr> no, since it’s a feature, our backport policies prevent it.. but, you could use newer or older versions of the client with newer or older versions of the server…
15:28:48 <wolsen[m]> right, so we look to avoid backporting features into Ubuntu packages as well and try not to deviate in significant manners from upstream repositories
15:28:49 <carloss> > but, you could use newer or older versions of the client with newer or older versions of the server…
15:28:49 <carloss> ++
15:29:13 <wolsen[m]> sure, you can use newer versions of the client with older versions of the server - when is the next version of the client expected to be available - in the bobcat release right?
15:29:58 <gouthamr> we’re a week away from the bobcat release I think, but yes
15:30:28 <wolsen[m]> from starting the bobcat release
15:30:35 <wolsen[m]> not releasing the bobcat release
15:31:20 <carloss> next version is expected during the bobcat release. We try to tag releases a couple of times in the cycle
15:31:48 <gouthamr> or in my opinion, generate fast and frequent releases :)
15:32:01 <wolsen[m]> are there implications to the SLURP support for differences between client and server?
15:32:13 <gouthamr> we just haven’t found the need to tag more than a few for the client through a release
15:32:13 <wolsen[m]> for example, if a feature is available in the server, but the client is not yet available
15:32:27 <wolsen[m]> how are the client validations done to ensure the capability from one SLURP release to the next in this scenario?
15:32:34 <wolsen[m]> is it not supported if its not fully exposed to the client or ?
15:34:57 <gouthamr> am not sure i understood the question
15:35:36 <gouthamr> SLURP affects us more with regard to feature deprecations and removals
15:35:55 <gouthamr> what do you mean by client validation?
15:37:18 <wolsen[m]> I guess what I was trying to understand is whether there are implications to the SLURP support for features
15:37:20 <wolsen[m]> some features will be introduced as part of a cycle
15:37:23 <wolsen[m]> and some of those will have both a client side implementation and a server side implementation
15:37:38 <wolsen[m]> its clear the feature is introduced and supported when there's both client and server portions delivered in the same cycle
15:38:09 <wolsen[m]> but if a feature is introduced which isn't normally exposed without the client enablement as well, when is that feature officially introduced and supported for consideration across release upgrades and such?
15:38:58 <gouthamr> all manila APIs are fully supported unless they're experimental: https://docs.openstack.org/manila/latest/contributor/experimental_apis.html
15:39:28 <gouthamr> this feature wasn't experimental, so is no different
15:39:56 <wolsen[m]> and supported only means that you can access the API, e.g. with curl - rather than client side support actually exists for it
15:40:10 <gouthamr> around here we try to ship the client integration asap because we do understand its used by human operators as well as tools that rely on the SDK
15:40:41 <gouthamr> but, we do occasionally come across issues where we cant merge a client patch in time to ship a release
15:40:42 <wolsen[m]> right, which is partly why I'm a bit confused about supporting something without the reference client implementation available
15:41:30 <wolsen[m]> (and to be clear, I'm not here to twist arms one way or another - I'm here to ask various questions to understand both the specifics and generalities of such scenarios)
15:41:39 <gouthamr> no that's fair
15:42:48 <wolsen[m]> I guess to me, it seems odd to "support" something that relies on a client being able to use something but not having that client available. I understand there's a fine line and there's differences between the client and the server
15:43:03 <wolsen[m]> that client support available*
15:43:42 <gouthamr> server and client have their own feature support policy - the support stance for a client is to work against N-1, N and N+1 releases of the server --- but, we try to be more flexible; and especially with the SLURP process --- a major version of the client will be compatible with N-2,N-1,N,N+1,N+2 versions of the server
15:45:22 <gouthamr> being compatible is the goal, not to support newer features...
15:46:21 <wolsen[m]> sure, but it feels uncomfortable to use the antelope client and not being able to support a feature in the antelope server - but perhaps that just my intuition where I try to match clients with services
15:47:36 <gouthamr> seeing how my distro works, i get you.. and we have had to do distro-only backports several times
15:47:39 <wolsen[m]> okay, I think I've said my piece at this point - thank you for the information on the support policies, etc
15:48:11 <wolsen[m]> yes, we just really try hard not to backport features for a variety of reasons
15:49:47 <gouthamr> ack, then i'm sure you're sympathetic towards our policies: https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
15:49:55 <wolsen[m]> 100%
15:50:28 <wolsen[m]> which is why I was chiming if the client final release has not yet been cut, trying to make a case
15:50:52 <wolsen[m]> trying to avoid the backport challenges :-)
15:52:03 <gouthamr> wolsen[m]: we're late to that party unfortunately
15:52:04 <gouthamr> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032137.html
15:52:26 <gouthamr> the final client has been released - we will make minor tag updates as we backport fixes
15:52:26 <wolsen[m]> gouthamr: thanks! it is what it is then :-)
15:53:48 <gouthamr> thanks for bringing up this concern wolsen[m] and felipe_rodrigues; i think if the code's ready for review, we proceed with going through reviews and merging it soon
15:54:12 <felipe_rodrigues> thanks gouthamr
15:54:19 <wolsen[m]> thanks for entertaining my questions
15:54:26 <carloss> thanks felipe_rodrigues wolsen[m] felipe_rodrigues :)
15:55:28 <carloss> we have 5 minutes remaining to this meeting - I'm afraid it's not much for bug triaging
15:55:39 <carloss> #topic Open Discussion
15:56:09 <carloss> is there something very urgent with bug triaging though vhari?
15:56:25 <vhari> carloss, not atm
15:56:50 <carloss> ack, thanks :)
15:58:06 <vhari> yw carloss :)
15:58:36 <carloss> 2 minutes to go... thank you for joining this meeting - see you in #openstack-manila :)
15:58:38 <carloss> #endmeeting