| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-06 | |||
| 16:33:03 | sean-k-mooney | we cant merge feature incase there is a bug fix needed | |
| 16:33:11 | sean-k-mooney | branches will be create at rc1 | |
| 16:33:35 | elodilles | bauzas: ++ | |
| 16:33:40 | bauzas | #agreed Client patches are on Client libs freeze, please don't accept to merge new changes until RC1 happens | |
| 16:33:52 | bauzas | voila | |
| 16:33:53 | dansmith | did the rebuild bfv change merge? | |
| 16:34:02 | bauzas | the novaclient one, not | |
| 16:34:02 | dansmith | for the client I mean | |
| 16:34:17 | bauzas | we were reviewing it today, hence my question | |
| 16:34:40 | bauzas | we have novaclient support until 2.92 | |
| 16:34:42 | dansmith | hmm, seems bad to not have that present in the client if we've got it as a server feature | |
| 16:34:49 | bauzas | and OSC support until 2.91 IIRC | |
| 16:35:31 | sean-k-mooney | dansmith: that is why i was suggesting we do a release in a few weeks | |
| 16:35:31 | bauzas | dansmith: fwiw, we have a difference between what the server supports and what the client can negociate | |
| 16:35:48 | bauzas | yoga didn't had this issue, no microversion patch was merged | |
| 16:35:56 | bauzas | so, this is my first time :) | |
| 16:36:21 | dansmith | okay, so you're saying we wait for rc1 then do a client release soonly so people will be able to actually use it? | |
| 16:36:28 | sean-k-mooney | its not the first time we have not had parity between api and cli | |
| 16:36:31 | sean-k-mooney | dansmith: yep | |
| 16:36:37 | dansmith | okay | |
| 16:36:38 | sean-k-mooney | dansmith: at leat that is what im suggesting | |
| 16:36:48 | bauzas | dansmith: I'm not saying anything, I'm asking for help | |
| 16:37:15 | bauzas | if we all agree on the discrepancy, we should also agree on the fact this isn't great | |
| 16:37:29 | dansmith | as long as there's a short timeline to getting the client released then I guess that's okay | |
| 16:37:34 | bauzas | that client libs freeze doesn't really help, fwiw | |
| 16:37:43 | sean-k-mooney | it does | |
| 16:37:46 | sean-k-mooney | normally | |
| 16:37:59 | bauzas | ideally, we should have a one week difference I think between the server freeze and the client freeze | |
| 16:38:09 | dansmith | bauzas: do we not? | |
| 16:38:21 | dansmith | I guess I'm confused, seems like this is the week to get the client things finalized | |
| 16:38:23 | bauzas | dansmith: not in the zed schedule | |
| 16:38:37 | bauzas | hence my call for clarification | |
| 16:38:42 | dansmith | hrm okay | |
| 16:38:54 | dansmith | that | |
| 16:38:57 | dansmith | is a bit of a bummer | |
| 16:39:11 | bauzas | can't disagree | |
| 16:39:25 | dansmith | I dunno what distros do for picking client releases, but they'd need to know that they need the one right after the zed server release to have this | |
| 16:39:28 | dansmith | but whatever | |
| 16:39:35 | sean-k-mooney | feedback i guess for tc/cross project ptg session | |
| 16:39:41 | bauzas | agrred | |
| 16:39:46 | dansmith | I think that's just for the release team | |
| 16:39:57 | bauzas | the antelope schedule is already accepted but I guess we can debate it at the PTG | |
| 16:40:00 | sean-k-mooney | ya perhaps | |
| 16:40:03 | dansmith | we approve the schedule but don't really do much other than that I think | |
| 16:40:30 | sean-k-mooney | well the schdule can be updated if we think it need changes | |
| 16:40:32 | bauzas | just as a hint for next cycle https://releases.openstack.org/antelope/schedule.html | |
| 16:40:34 | sean-k-mooney | its just anohter review | |
| 16:40:51 | bauzas | anyway, moving on | |
| 16:41:19 | bauzas | #link https://review.opendev.org/c/openstack/releases/+/855974 Nova Zed cycle highlights | |
| 16:41:29 | bauzas | I'd appreciate if people could review my prose | |
| 16:41:52 | bauzas | even if we didn't had a lot of blueprints, this was a productive cycle | |
| 16:42:07 | bauzas | and I guess the marketing folks will love all the buzz words I used | |
| 16:42:36 | bauzas | kudos to the team for the hard work you made, very well appreciated | |
| 16:42:44 | gibi | I will re-review shortly | |
| 16:42:58 | bauzas | gibi: YAMLs don't help with fancy formatting, unfortunatelty | |
| 16:43:19 | bauzas | next topic then | |
| 16:43:20 | gibi | that makes me sad | |
| 16:43:25 | bauzas | #topic PTG planning | |
| 16:43:33 | bauzas | thanks to gibi, | |
| 16:43:36 | bauzas | #link https://etherpad.opendev.org/p/nova-antelope-ptg Antelope PTG etherpad | |
| 16:43:50 | gibi | I needed it as I had a topic :) | |
| 16:44:00 | bauzas | feel free to add your items you'd like to discuss | |
| 16:44:07 | bauzas | the earlier be the better | |
| 16:44:32 | bauzas | since we didn't had an agenda yet, I made a proposal : | |
| 16:44:35 | gibi | also we should add a retro topic about prorities and more frequent deadlines | |
| 16:44:38 | bauzas | #info bauzas has asked for 4 hours per day for Tuesday to Friday (Bexar room) | |
| 16:44:52 | bauzas | gibi: feel free to add anything | |
| 16:45:04 | gibi | anything? :) no you don't want that :D | |
| 16:45:22 | bauzas | well, this is an open text file | |
| 16:45:31 | gibi | just joking :) | |
| 16:45:37 | bauzas | but yeah, we'll have a retro, of course | |
| 16:45:56 | bauzas | so, about the proposed schedule | |
| 16:46:03 | bauzas | I booked 4x4 hours | |
| 16:46:12 | bauzas | with the bexar room | |
| 16:46:17 | bauzas | maybe we would need less | |
| 16:46:25 | bauzas | I can unbook the room if so | |
| 16:46:38 | bauzas | so, the plan is to not feel constrained by the schedule | |
| 16:47:08 | bauzas | but obviously, if we keep with 4x4hours, we'll manage decent time offs :) | |
| 16:47:24 | bauzas | #link https://ptg.opendev.org/ptg.html PTG schedule | |
| 16:47:40 | bauzas | anyone having serious concerns with the proposed timeslots ? | |
| 16:47:47 | bauzas | anyone wanting an asian-friendly timeslot ? | |
| 16:48:14 | bauzas | I don't hear anything | |
| 16:48:15 | bauzas | sold. | |
| 16:48:34 | bauzas | last point, and I'm rushing because time flies | |
| 16:48:37 | bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html operator friendly timeslots, which ones for Nova ? | |
| 16:49:07 | bauzas | as you probably already read, TC proposes us to reserve some slots for operators-friendly discussions | |
| 16:49:14 | bauzas | I'm more than happy with the idea | |
| 16:49:39 | bauzas | so, shall we reserve one hour per day about this ? | |
| 16:49:53 | bauzas | or just, for example, one hour on the first two days ? | |
| 16:49:58 | gibi | do we need 4 hours total? | |
| 16:50:01 | gibi | sorry | |
| 16:50:03 | bauzas | or two hours back-to-back ? | |
| 16:50:11 | bauzas | or no operator hours at all ? | |
| 16:50:23 | bauzas | personnally, I feel this can be more than interesting | |
| 16:50:26 | dansmith | the idea is just one of those slots for nova | |
| 16:50:39 | bauzas | and we should have at least 2 hours at the beginning of our talks | |
| 16:50:46 | dansmith | so you can have more slots than that, but the idea is that they're not overlapping so operators have only one place to be, if they have multiple interests | |
| 16:50:56 | bauzas | in order to discuss about what they told us during the other days | |
| 16:51:21 | bauzas | dansmith: yean, we could reserve other slots than the 4x4 hours we already have | |
| 16:51:44 | bauzas | but honestly, I just hope we can find propre timeslots ? | |