| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-23 | |||
| 17:01:07 | sean-k-mooney | ok im gong to more or less call it a day. | |
| 17:01:34 | sean-k-mooney | ill likely do some code review on my ipad while i cook/order dinner but im going to drop off irc ffor the day | |
| 17:01:45 | gibi | sean-k-mooney: have a nice evening o/ | |
| 17:15:02 | opendevreview | Elod Illes proposed openstack/nova stable/train: [ironic] Minimize window for a resource provider to be lost https://review.opendev.org/c/openstack/nova/+/853546 | |
| 17:16:05 | JayF | elodilles: thanks, I had that on my todo list but I appreciate it \o/ | |
| 17:22:33 | elodilles | JayF: np, just re-applied the cherry-pick to have the right format of the commit message, otherwise it seems right, so +2'd it already | |
| 17:22:46 | JayF | So, what you want in the commit is | |
| 17:23:05 | elodilles | it's not the commit message in general o:) | |
| 17:23:06 | JayF | cherry-picked-from (master SHA)\ncherry-picked-from (master-1 sha)\n etc etc | |
| 17:23:17 | JayF | which is achieved by a clean cherry pick from stable N -> stable N-1 | |
| 17:23:23 | elodilles | but to do the cherry-picking branch-by-branch, | |
| 17:24:22 | elodilles | so that one can see that the cherry picking was in the right order, from the right (latest) patch sets, etc. | |
| 17:25:09 | JayF | so for my most recent master change, I'd cherry-pick it to stable/yoga, then cherry pick *the yoga change* onto xena, and so on | |
| 17:25:40 | JayF | and if at any point one patch in the cycle is changed or rebased (whoops), the ones after it have to be re-cherry-picked | |
| 17:26:26 | elodilles | JayF: exactly :) | |
| 17:26:44 | JayF | is this a nova-ism? Or something generally that most OpenStack projects do that Ironic has never really enforced? | |
| 17:27:54 | elodilles | the backports should be done branch-by-branch according to stable policy | |
| 17:28:08 | JayF | ack, so I'll update how I do it in Ironic world too | |
| 17:28:37 | elodilles | but yes, probably only nova has this check as (we) stable cores were picky about this one o:) | |
| 17:29:00 | JayF | Yeah, I've been focused on stable reviews in Ironic for a long time, and this is *never* something I've checked for | |
| 17:29:03 | elodilles | to avoid wrong/not latest/missing backports | |
| 17:29:11 | JayF | frankly, I doubt I'd -1 a change for this now -- but I do always manually check the earlier branches | |
| 17:29:18 | JayF | and I'll start doing it right for me ;D | |
| 17:29:22 | JayF | **my changes | |
| 17:30:12 | elodilles | :) | |
| 17:32:35 | elodilles | also note, that the rebase is unnecessary as Zuul is always doing it. the only time when it is needed, when there's a merge conflict | |
| 17:43:54 | JayF | tbh rebase button is my shortcut for "clear verify and re-run tests on this" except now I realize there are negative side effects in this context | |
| 17:59:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: Request filter for PCI in placement https://review.opendev.org/c/openstack/nova/+/852771 | |
| 17:59:48 | opendevreview | Balazs Gibizer proposed openstack/nova master: Map PCI pools to RP UUIDs https://review.opendev.org/c/openstack/nova/+/854118 | |
| 17:59:48 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support resource_class and traits in PCI alias https://review.opendev.org/c/openstack/nova/+/853316 | |
| 17:59:49 | opendevreview | Balazs Gibizer proposed openstack/nova master: Filter PCI pools based on Placement allocation https://review.opendev.org/c/openstack/nova/+/854120 | |
| 17:59:49 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make allocation candidates available for scheduler filters https://review.opendev.org/c/openstack/nova/+/854119 | |
| 17:59:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: Func test for PCI in placement scheduling https://review.opendev.org/c/openstack/nova/+/854122 | |
| 17:59:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: Store allocated RP in InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/854121 | |
| 17:59:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: Test PCI scheduling during move operations https://review.opendev.org/c/openstack/nova/+/854247 | |
| 18:08:11 | opendevreview | Merged openstack/nova master: Revert "Test attached volume extend actions in the nova-next job" https://review.opendev.org/c/openstack/nova/+/854132 | |
| 18:23:41 | opendevreview | Elod Illes proposed openstack/nova stable/queens: WIP: [stable-only] Remove grenade jobs https://review.opendev.org/c/openstack/nova/+/854252 | |
| 18:47:52 | opendevreview | Merged openstack/nova master: nova-live-migration tests not needed for Ironic https://review.opendev.org/c/openstack/nova/+/853529 | |
| 18:47:59 | opendevreview | Merged openstack/nova stable/victoria: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821350 | |
| 19:14:21 | opendevreview | Jay Faulkner proposed openstack/nova stable/ussuri: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821351 | |
| 19:15:37 | JayF | https://review.opendev.org/c/openstack/nova/+/853546 (to stable/train) needs one more core review, then this one will be backported as far as I plan to take it | |
| 19:16:26 | opendevreview | Jay Faulkner proposed openstack/nova stable/yoga: nova-live-migration tests not needed for Ironic https://review.opendev.org/c/openstack/nova/+/854257 | |
| 19:17:41 | opendevreview | Jay Faulkner proposed openstack/nova stable/yoga: nova-live-migration tests not needed for Ironic https://review.opendev.org/c/openstack/nova/+/854257 | |
| 19:18:36 | opendevreview | Jay Faulkner proposed openstack/nova stable/ussuri: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821351 | |
| 19:20:11 | JayF | elodilles: took a couple of tries, but I think I got them right now ^^ had to do two rounds, first used `-x` then I realized I needed the `-X` :D | |
| 19:20:19 | JayF | ty for the guidance | |
| 19:22:40 | JayF | https://review.opendev.org/c/openstack/nova/+/821351 and https://review.opendev.org/c/openstack/nova/+/854257 should both be good for reviews now, no-change-backports of stuff already merged, shouldn't be controversial :D | |
| 19:22:53 | JayF | thank you all again for helping me plow thru this ironic-driver-backport tech debt | |
| 22:08:26 | melwitt | sean-k-mooney, gibi: I'm off today and tomorrow, thanks for getting the revert done and sorry for the trouble ☹️ | |
| #openstack-nova - 2022-08-24 | |||
| 03:52:06 | sean-k-mooney[m] | melwitt: sorry didnt realise that enjoy your time off | |
| 05:26:30 | auniyal__ | Hi O/ | |
| 05:26:37 | auniyal__ | please review these | |
| 05:26:39 | auniyal__ | https://review.opendev.org/c/openstack/nova/+/853811 | |
| 05:26:53 | auniyal__ | https://review.opendev.org/c/openstack/nova/+/853812 | |
| 06:46:09 | crohmann | Hey lovely nova folks. I was just about to raise a bug about duplicate indices for tables of Nova and Placement, but then found an old, but unfixed bug: https://bugs.launchpad.net/nova/+bug/1641185 | |
| 06:47:58 | crohmann | Since this is already assigned to ABHAY (since 2018) I believe this might be under the radar. Any chance this could be reassigned or place onto the list of "open isuses" ? | |
| 06:52:33 | crohmann | This also appears to have a simple fix in removing the double definitions of colums as primary indexes as well as them having a unique constraint. | |
| 07:21:37 | gibi | crohmann: hi! thanks for checking before reporting a new bug. Do you plan to proposa a fix? | |
| 07:22:07 | gibi | if so, then feel free to reassing the bug | |
| 07:22:35 | gibi | (or I can reassing it to you if you don't have the rights) | |
| 07:39:53 | crohmann | gibi: I did assign me and also raised a bug for placement at https://storyboard.openstack.org/#!/story/2010251. | |
| 07:40:45 | crohmann | Regarding a fix ... I suppose there are two sides: Fixing the schema for new installs, but also dropping them for existing ones, right? | |
| 07:41:04 | crohmann | "them" = the duplicate index | |
| 07:44:52 | gibi | crohmann: you are correct | |
| 07:45:41 | gibi | you need to drop it from the schema and also propose a db schema migration to drop it from existing dbs during upgrade | |
| 09:04:38 | opendevreview | Gorka Eguileor proposed openstack/nova master: Support os-brick specific lock_path https://review.opendev.org/c/openstack/nova/+/849328 | |
| 09:08:41 | opendevreview | Gorka Eguileor proposed openstack/nova master: Support os-brick specific lock_path https://review.opendev.org/c/openstack/nova/+/849328 | |
| 09:11:22 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check for VM snapshot fail while quiesce https://review.opendev.org/c/openstack/nova/+/852171 | |
| 09:15:37 | sean-k-mooney | the unique key is the one that should be kept | |
| 09:19:29 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support move operations with PCI tracking in placement https://review.opendev.org/c/openstack/nova/+/854247 | |
| 09:20:45 | opendevreview | ribaudr proposed openstack/nova master: Default Nova persistent objects without soft delete. https://review.opendev.org/c/openstack/nova/+/854355 | |
| 09:23:16 | sean-k-mooney | gibi: since the update userdata feature will need a new trait and a new os-traits reelase i think we shoudl swap the microverions for that and rebuild | |
| 09:23:32 | Uggla | gibi, I did that change ^ then I want to modify act objects like aggregate that do not requires soft delete. Unfortunately it changes the API output. So I guess we need a new microversion at minimum. But do we need a "deprecation" cycle too ? | |
| 09:24:01 | sean-k-mooney | Uggla: waht are you chagining | |
| 09:24:30 | gibi | sean-k-mooney: we have "time" until friday to push an os-traits change. But if the rebuild series is ready then I have no objection to swap | |
| 09:25:02 | sean-k-mooney | i have not reviewed it so i cant say | |
| 09:25:25 | Uggla | sean-k-mooney, https://review.opendev.org/c/openstack/nova/+/854355 trying to make persistent objects without soft delete "by default" | |
| 09:25:35 | gibi | Uggla: let me look at it. For sean-k-mooney, the new ShareMapping object needs to be non-soft-deletable and that needs some new baseclass for Nova ovos as the current one adds the deleted_at field | |
| 09:26:06 | sean-k-mooney | right but we dont need to change all the others | |
| 09:26:11 | gibi | sean-k-mooney: re rebuild series: me neither so for me both userdata and rebuild is in the grey zone but if somebody says that rebuild is ready to land then I'm OK to swap | |
| 09:26:17 | sean-k-mooney | we could eventually | |
| 09:26:31 | gibi | sean-k-mooney: re ovo: yes, we only need to change the base class for the new ShareMapping | |
| 09:27:26 | sean-k-mooney | right so https://review.opendev.org/c/openstack/nova/+/854355/1/nova/objects/base.py#142 is wrong | |
| 09:27:43 | sean-k-mooney | we shoudl not modify the NovaPersistentObject | |
| 09:28:02 | sean-k-mooney | we shoudl leage that the same and add a seperate one that does not use soft delete | |
| 09:28:31 | gibi | ^^ agree | |
| 09:29:06 | sean-k-mooney | maybe call it NovaPersistentObjectHardDelete for now | |
| 09:30:04 | gibi | wondering that the problem is only that the base class change changes the object signature used for versioning | |
| 09:30:31 | sean-k-mooney | it will change the ovo shas | |
| 09:30:41 | Uggla | sean-k-mooney, gibi it means we will keep objects with the removal of delete deleted_at "tricks" forever ? | |
| 09:30:51 | sean-k-mooney | but if Uggla updated them all to point to NovaPersistentSoftDeleteObject it woudl be fine | |
| 09:31:13 | sean-k-mooney | Uggla: if we remove soft delete it will be a sperrate spec | |
| 09:31:14 | Uggla | sean-k-mooney, no the current changes does not change the shas | |
| 09:31:23 | sean-k-mooney | its not something you should do in your current one | |
| 09:33:46 | gibi | Uggla: then what is the exact API change you are worried about? | |
| 09:34:59 | gibi | Uggla: I don't see the reason why the aggregate API output would differ | |
| 09:35:06 | gibi | after your patch | |
| 09:35:23 | gibi | ohh | |
| 09:35:39 | Uggla | gibi, in another patch I wanted to clean the aggregate object | |
| 09:35:41 | gibi | so the aggregate is not soft deleted | |