| *** chuanm1 is now known as chuanm | 00:34 | |
| *** chuanm2 is now known as chuanm | 04:19 | |
| *** chuanm5 is now known as chuanm | 09:13 | |
| *** chuanm5 is now known as chuanm | 10:35 | |
| *** chuanm2 is now known as chuanm | 11:02 | |
| *** chuanm6 is now known as chuanm | 12:03 | |
| carloss | #startmeeting manila | 15:00 |
|---|---|---|
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'manila' | 15:00 |
| haixin | o/ | 15:00 |
| gouthamr | o/ | 15:00 |
| MatheusAndrade[m] | o/ | 15:00 |
| vhari | o/ | 15:00 |
| HelenaDantas[m] | o/ | 15:01 |
| felipe_rodrigues | hi | 15:01 |
| lucasmoliveira059 | \o | 15:01 |
| caiquemello[m] | hi | 15:01 |
| freyes | hi | 15:03 |
| thiagoalvoravel | o/ | 15:03 |
| carloss | o/ hello everyone | 15:04 |
| carloss | courtesy ping: dviroel | 15:04 |
| 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 |
| carloss | and add your name to the courtesy ping list | 15:05 |
| carloss | that said, let's start with today's meeting agenda: | 15:05 |
| carloss | #link https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting | 15:05 |
| carloss | #topic Announcements | 15:06 |
| carloss | Schedule and Deadlines: | 15:06 |
| carloss | #link https://releases.openstack.org/antelope/schedule.html | 15:06 |
| luizsantos[m] | o/ | 15:06 |
| carloss | RC1 was last week and we are a couple of weeks away from Antelope release | 15:06 |
| carloss | and PTG is also right around the corner | 15:07 |
| carloss | next ptg we will have will be virtual | 15:08 |
| carloss | #link https://openinfra.dev/ptg/ | 15:08 |
| carloss | dates are: March 27-31, 2023 | 15:08 |
| carloss | I have already booked the slots for Manila, you can see the slots in the PTG site | 15:08 |
| carloss | #link #link https://ptg.opendev.org/ptg.html | 15:09 |
| carloss | you will notice a reduction of hours (for this year, we will have 3 hours less than the usual) | 15:09 |
| carloss | please take a look at the slots and let me know if you have suggestions | 15:09 |
| carloss | the PTG planning etherpad is this: | 15:10 |
| carloss | #link #link https://etherpad.opendev.org/p/manila-bobcat-ptg-planning | 15:10 |
| carloss | please add the topics you would like to discuss with the community during PTG | 15:10 |
| carloss | we will talk scheduling in one or two weeks | 15:10 |
| carloss | that's all I had for $topic | 15:10 |
| carloss | do you have an announcement to share with us today> | 15:10 |
| carloss | ? | 15:11 |
| carloss | okay, next topic then | 15:13 |
| carloss | #topic Manila Client API version behind Server API (felipe_rodrigues) | 15:13 |
| carloss | felipe_rodrigues: floor is yours | 15:13 |
| felipe_rodrigues | thanks carloss | 15:13 |
| felipe_rodrigues | I added this topic because the server is upper than the client | 15:14 |
| felipe_rodrigues | It means that the operator cannot run with the features since there is no Client | 15:15 |
| felipe_rodrigues | The patch that would make client updated | 15:15 |
| felipe_rodrigues | #link https://review.opendev.org/c/openstack/python-manilaclient/+/869709 | 15:15 |
| felipe_rodrigues | I fixed the comments and passed on community CI | 15:16 |
| felipe_rodrigues | This is very important for NetApp customer | 15:16 |
| felipe_rodrigues | Canonical team is here to explain the use case and the importance | 15:16 |
| felipe_rodrigues | Vinod_____: do you want to add something ? | 15:17 |
| Vinod_____ | only that our client won't be able to move this in production without the client | 15:17 |
| Vinod_____ | and we plan to move this to production in Q2 timeframe | 15:18 |
| felipe_rodrigues | Nice | 15:18 |
| felipe_rodrigues | Can we work on it to have It merge asap ? | 15:19 |
| wolsen[m] | fwiw, aiui the server side feature isn't really usable without the client side implementation correct? | 15:20 |
| Vinod_____ | yes, that this correct | 15:20 |
| gouthamr | why unusable? If we merge this patch now, and can canonical take it into its antelope release content? | 15:22 |
| 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:23 |
| wolsen[m] | gouthamr: unusable in the sense that there's not a client interface for general users to use | 15:24 |
| wolsen[m] | one could use raw interactions with the api using http requests | 15:24 |
| wolsen[m] | but it seems like the client would be desired to show completeness of the feature | 15:24 |
| * dviroel o/ | 15:25 | |
| wolsen[m] | gouthamr: would the patch be eligible for backporting to the antelope client release? | 15:25 |
| wolsen[m] | in your opinion? | 15:26 |
| 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:26 |
| 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 |
| carloss | > but, you could use newer or older versions of the client with newer or older versions of the server… | 15:28 |
| carloss | ++ | 15:28 |
| 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 |
| gouthamr | we’re a week away from the bobcat release I think, but yes | 15:29 |
| wolsen[m] | from starting the bobcat release | 15:30 |
| wolsen[m] | not releasing the bobcat release | 15:30 |
| carloss | next version is expected during the bobcat release. We try to tag releases a couple of times in the cycle | 15:31 |
| gouthamr | or in my opinion, generate fast and frequent releases :) | 15:31 |
| wolsen[m] | are there implications to the SLURP support for differences between client and server? | 15:32 |
| gouthamr | we just haven’t found the need to tag more than a few for the client through a release | 15:32 |
| wolsen[m] | for example, if a feature is available in the server, but the client is not yet available | 15:32 |
| wolsen[m] | how are the client validations done to ensure the capability from one SLURP release to the next in this scenario? | 15:32 |
| wolsen[m] | is it not supported if its not fully exposed to the client or ? | 15:32 |
| gouthamr | am not sure i understood the question | 15:34 |
| gouthamr | SLURP affects us more with regard to feature deprecations and removals | 15:35 |
| gouthamr | what do you mean by client validation? | 15:35 |
| wolsen[m] | I guess what I was trying to understand is whether there are implications to the SLURP support for features | 15:37 |
| wolsen[m] | some features will be introduced as part of a cycle | 15:37 |
| wolsen[m] | and some of those will have both a client side implementation and a server side implementation | 15:37 |
| wolsen[m] | its clear the feature is introduced and supported when there's both client and server portions delivered in the same cycle | 15:37 |
| 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 |
| gouthamr | all manila APIs are fully supported unless they're experimental: https://docs.openstack.org/manila/latest/contributor/experimental_apis.html | 15:38 |
| gouthamr | this feature wasn't experimental, so is no different | 15:39 |
| 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:39 |
| 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 |
| gouthamr | but, we do occasionally come across issues where we cant merge a client patch in time to ship a release | 15:40 |
| wolsen[m] | right, which is partly why I'm a bit confused about supporting something without the reference client implementation available | 15:40 |
| 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 |
| gouthamr | no that's fair | 15:41 |
| 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:42 |
| wolsen[m] | that client support available* | 15:43 |
| 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:43 |
| gouthamr | being compatible is the goal, not to support newer features... | 15:45 |
| 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:46 |
| gouthamr | seeing how my distro works, i get you.. and we have had to do distro-only backports several times | 15:47 |
| wolsen[m] | okay, I think I've said my piece at this point - thank you for the information on the support policies, etc | 15:47 |
| wolsen[m] | yes, we just really try hard not to backport features for a variety of reasons | 15:48 |
| 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 |
| wolsen[m] | 100% | 15:49 |
| 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 |
| wolsen[m] | trying to avoid the backport challenges :-) | 15:50 |
| gouthamr | wolsen[m]: we're late to that party unfortunately | 15:52 |
| gouthamr | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032137.html | 15:52 |
| gouthamr | the final client has been released - we will make minor tag updates as we backport fixes | 15:52 |
| wolsen[m] | gouthamr: thanks! it is what it is then :-) | 15:52 |
| 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:53 |
| felipe_rodrigues | thanks gouthamr | 15:54 |
| wolsen[m] | thanks for entertaining my questions | 15:54 |
| carloss | thanks felipe_rodrigues wolsen[m] felipe_rodrigues :) | 15:54 |
| carloss | we have 5 minutes remaining to this meeting - I'm afraid it's not much for bug triaging | 15:55 |
| carloss | #topic Open Discussion | 15:55 |
| carloss | is there something very urgent with bug triaging though vhari? | 15:56 |
| vhari | carloss, not atm | 15:56 |
| carloss | ack, thanks :) | 15:56 |
| vhari | yw carloss :) | 15:58 |
| carloss | 2 minutes to go... thank you for joining this meeting - see you in #openstack-manila :) | 15:58 |
| carloss | #endmeeting | 15:58 |
| opendevmeet | Meeting ended Thu Mar 9 15:58:38 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:58 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/manila/2023/manila.2023-03-09-15.00.html | 15:58 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/manila/2023/manila.2023-03-09-15.00.txt | 15:58 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/manila/2023/manila.2023-03-09-15.00.log.html | 15:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!