16:00:51 #startmeeting sdk_osc 16:00:51 Meeting started Thu Mar 18 16:00:51 2021 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:54 The meeting name has been set to 'sdk_osc' 16:01:18 diablo_rojo, diablo_rojo_phon, gouthamr, gtema, stephenfin, amotoki is anybody here for the meeting? 16:01:26 o/ 16:01:43 I am here but I don't think I have anything I need to discuss? 16:02:02 not really, perhaps vPTG planning 16:02:11 Its mostly if any of the students need to discuss anything 16:02:17 Oh thats a good idea 16:02:38 Deadline will be before our next meeting 16:03:06 I definitely think we should meet for a couple hours one or two days like last time. 16:03:10 I opened ethercalc and my system froze ;-) 16:03:26 I booked Wed 21 15-17 16:03:36 but haven't really planned anything yet. 16:03:43 gtema, yeah I botched making that link- I somehow managed to use, not our instance of ethercalc and so it likes to freeze. 16:03:46 Is there a demand for PTG? 16:03:57 gtema, maybe make a planning etherpad and circulate it? 16:04:23 something I wanted to do over a week already, but haven't really managed 16:04:47 Honestly, I think it would be cool to get all the students together, but also for you to do a braindump of like.. what all needs to be done so we can get that into storyboard so its easier for people to pick things up? 16:04:50 what was the link I need to follow also for getting booked? 16:05:20 I have one thing for the PTG - it's a R1.0 planning with all the challenges 16:05:27 so there is something to be discussed 16:05:37 https://openinfrafoundation.formstack.com/forms/april2021_vptg_survey 16:05:41 and getting all the students is surely cool 16:05:42 Apparently so 16:05:45 lol 16:05:56 thks 16:06:03 No problem! 16:06:04 o/ 16:06:10 Also, don't forget to register: https://april2021-ptg.eventbrite.com/ 16:06:17 Hello stephenfin :) Just chatting about the PTG 16:07:05 diablo_rojo - filled the survey. Thanks, lost the link 16:07:27 gtema, no worries :) 16:08:09 I will try not to forget to send email with planning 16:09:40 are there other interesting topics to discuss? 16:09:59 gtema, if you don't by the middleish of next week I can try to remember. 16:10:03 Nothing else from me? 16:10:14 thks 16:10:31 was it a question? "Nothing else from me?" 16:10:41 I've one thing 16:10:45 Releases 16:11:19 I _think_ we're currently tied to trailing release or some such thing for OSC 16:11:28 i.e. we have 'stable/{release}' branches 16:11:46 ah yeah, this one is also completely lost in overload this week 16:11:56 gtema, no question :) Sorry to be confusing. 16:12:25 Do we want to look at changing that to independent? 16:12:37 diablo_rojo - was more a joke ;-) 16:12:46 I feel like that's reasonable stephenfin ? 16:12:51 Rationale being that OSC isn't really tied to any particular OpenStack release. In theory it should support every release 16:13:05 gtema, lol I am too tired to catch that sorry. Need more caffeine. 16:13:29 I have no problems with that. But maybe TC have something in mind? 16:13:52 Yeah, I'm not sure how we do it, but I can investigate 16:14:13 I think we are still in sync with our release to some extent I think. 16:14:16 From a TC standpoint, I don't think we care? It's more the release team? 16:14:24 I figure we can and should release any time we have enough "stuff" to justify it 16:14:28 * diablo_rojo digs through pile of hats for release hat 16:14:36 amotoki: You think? How so? 16:15:20 stephenfin: I thoght we are discussing about _indepedent release, but I might misundertand the context. 16:15:52 No, you understood correctly :) 16:15:55 we sometimes have things related to releases 16:16:12 Most of our work now is less about keeping up with new changes, since APIs change less frequently than before. It's more about filling in gaps in old releases 16:16:13 we can actually release client things for not yet released stuff 16:16:14 so stable branches can help us regarding backports. 16:16:36 and you can use new OSC versions with old service versions 16:16:49 Hmm, can we get stable branches that are based on releases instead? 16:16:58 i.e. stable/5.0 ? 16:17:14 Maybe that's too much work unless we're very careful about how often we release 16:17:14 ugh, that's interesting 16:17:37 it is debatable. we cover most releases, so it is not a problem for most cases I think, 16:17:59 I actually dislike heavily stable branches for SDK and OSC. They are made to be always backward compatible 16:18:04 so I don't have strong preference on this 16:18:24 gtema: True, though we do occasionally do things like drop Python versions 16:18:32 yes 16:18:53 and we are also potentially caught in the service using dedicated version of SDK 16:18:54 that's less of an issue for OSC though, since that's only used in the client environment 16:19:16 yeah, more of an issues for sdk since that can be embedded in the service 16:19:19 I would be careful here 16:19:23 yes for most cases. no stable branches sometimes disallow us to fix bugs in released versions 16:19:37 that's all I see as a minus point. 16:19:46 but that would be minor. 16:20:00 let me think about it more and maybe discuss with release management folks 16:20:03 recently I landed image command redesign (to rely on SDK) and some time later figured out that some other dependent client got broken by that 16:20:03 I mean big fixes 16:20:18 I guess it was masakari 16:20:30 It's not high priority. It just occurred to me that we might want to change things when gtema was working through patches ahead of the release 16:20:57 amotoki: Yeah, that's a good point. I'll pay particular attention to this 16:21:19 it clear stephenfin and I am also currently "bombed" by release team wishing a release of OSC 16:21:33 do you need help? 16:21:47 I've got some spare time at the moment since nova is in feature freeze 16:21:57 not much but some :) 16:21:58 well, it's generally just cur a release 16:22:05 cut 16:22:39 and I landed today few things, one self-approved with project cleanup, since around a year it lacks reviews, but people permanently ask for it 16:22:51 so I guess we can cut release now 16:23:10 Oh, yes, I saw that. I thought we were still waiting for the openstacksdk side of that to merge so I hadn't reviewed it. Sorry /o\ 16:23:21 antoher way is to overcome it by cutting more releases from master branch independently from OpenStack release cycle 16:23:24 it landed actually 1,5 year ago 16:23:46 gtema: Ouch. Then I'm doubly sorry. I missed that 16:23:47 but we still need to take into account our OpenStack distributors like RHOSP 16:23:49 I could probably help with that if you need too. I vaguely remember how to do it. 16:23:53 fwiw, I reviewed this morning and it looks good to me 16:23:56 there is continuous place for improvement and adding new services inside, but OSC side is now at least capable calling it 16:25:11 amotoki: Also a good idea. fwiw, we're having discussions about how we can improve our OSC situation internally at the moment. We kind of ignore it now (as in there is no one person in charge of it) since most people are using OSC from their clients which aren't necessarily running the same stack as their servers 16:25:40 so RHOSP shouldn't be a major concern in any changes to lifecycle, IMO 16:25:49 I can't speak for any other distro, however 16:26:00 dear RedHatters - clarify it ;-) 16:26:44 I see lot of "distos" and cloud providers try to tie to the release 16:26:47 * mordred could never get anyone to care about OSC or SDK while I was there ... 16:26:56 James Palmer proposed openstack/openstacksdk master: Add support for Resource Filters https://review.opendev.org/c/openstack/openstacksdk/+/776271 16:26:57 and always they consider SDK/OSC part of that 16:27:14 thanks, so perhaps it is better to keep our release on OSC/SDK from the mater continuously 16:27:30 mordred: Horizon either. It's not classed as core, I guess 16:27:39 even though it's what 90% of users see, I know 16:28:01 hehe, as my hat of horizon, horizon faield to support system-scope in Wallaby :-( 16:28:03 gtema: If we're cutting a release, do we want to go through the final few "not in merge conflict" patches for OSC and see if any are good to go? 16:28:16 Or should we just cut and punt those to the next release? 16:28:30 stephenfin - yupp, let's do that 16:28:38 Okay, I'll spend tomorrow at that so 16:28:45 I mean the first one (time lag is killing the sense) 16:28:49 oh 16:28:55 okay yeah 16:29:27 I see about 30 or so, and many more in merge conflict. Will see how many are ready to roll and defer the rest 16:29:34 This will be a big release 16:29:50 yupp, but moslty only covering gaps 16:30:08 Yeah, true 16:30:17 Even still, exciting to have progress on things 16:30:23 indeed 16:30:51 yeah, I sadly admit I failed to complete switch of compute things to use SDK 16:31:14 started good but then lost the track 16:31:53 and then figured out that for SDK R1 we also need lot of love in parallel 16:32:40 anything else we want to discuss? 16:32:56 not from me 16:33:26 nothing from me too 16:33:47 this timeslot per month works for me :) 16:33:58 great 16:34:18 okay, then I wish everybody a nice day/evening/sleep 16:34:30 #endmeeting